✒️SAP Los servicios de actualización

LECCIÓN 5: SERVICIOS DE ACTUALIZACIÓN.

1) INTRODUCCIÓN AL SERVICIO DE ACTUALIZACIÓN DE SAP R/3.

Es importante porque está encargado de gestionar las modificaciones solicitadas por los usuarios en la base de datos. Dichas actualizaciones se pueden generar a través de procesos de trabajo tipo dialogo, batch o update.

2) ACTUALIZACIÓN SINCRÓNICA Y ASINCRÓNA.

Asincrónica: La actualización en la base de datos de un sistema R/3 es mayoritariamente asincrónica, es decir el sistema gestiona el proceso aparte del proceso de diálogo del usuario.

Se logra que el usuario se desentienda del proceso de actualización, ya que no debe esperar a que el sistema acceda a actualizar a las base de datos para poder seguir trabajando. Esto se traduce en una mejora de rendimiento; el proceso de diálogo del usuario no espera a que se termine las actualizaciones para seguir procesando las peticiones de ese usuario.

En el gráfico se muestra en forma esquemática cómo las actualizaciones asíncronas pertenecientes a un proceso de trabajo de un usuario son lanzadas en paralelo.

Sincrónica: es menos frecuente, también se produce en el sistema R/3, y se diferencia de asincrónica en que la petición de actualización de datos se genera en el mismo proceso de trabajo que gestiona el resto de peticiones de usuario.

De esta forma el proceso de diálogo o batch debe esperar que se realicen las actualizaciones en la base de datos antes de seguir procesando el resto de las peticiones del usuario. El rendimiento será peor.

En el gráfico se muestra de forma esquemática cómo las actualizaciones sincrónicas pertenecientes a un proceso de trabajo asociado a un usuario son lanzadas en el mismo proceso, obligando al proceso a esperar a que la actualización termine para poder continuar.

Los usuarios no pueden elegir si los cambios en la base de datos se realizan en forma sincrónica o asincrónica, ya que esto depende d la programación de la aplicación en curso.

NOTA: Si se tratara de actualizaciones dentro de alguna aplicación hecha a medida será tarea del analista de la aplicación el decidir qué tipo de actualización realizar.

3) PROCESOS DE ACTUALIZACIÓN V1 Y V2.

La actualización asincrónica presenta una ventaja adicional: implementa las LUW.

LUWs: Consiste en bloques auto consistentes de datos, de tal forma que se actualización en la base de datos es llevada completamente.

Si surgiera algún problema en la base de datos, la grabación de cada LUW no se realizará, de esta manera se evitan las inconsistencias que pudieran surgir al grabar una LUW a medias.

La actualización asincrónica consiste en dos tipos de actualización: V1 y V2.

El sistema R/3 distingue entre componentes de actualización crítica primaria (V1) y secundaría no crítica (V2). La diferenciación entre estos dos tipos de actualización permite que el sistema procese los cambios críticos en la base de datos por delante de los cambios menos críticos asignándole diferentes LUWs.

Para asegurar la consistencia de los datos, las actualizaciones V1 se procesan con la supervisión del gestor de bloqueos se SAP R/3 que impide que varias modificaciones sobre el mismo objeto se realicen concurrentemente.

Existen dos tipos de LUW:

· LUW de base de datos: una LUW es una secuencia de operaciones de datos que no pueden ser divididas. Las operaciones que realizan o bien en su totalidad o no se realizan. Una transacción de SAP puede incluir muchas LUW de base de datos cada una de las cuales pueden ser finalizadas con un commic a la base de datos el cual se genera automáticamente.

· LUW de SAP: es un proceso de negocio el cual no puede dividirse. El proceso se ejecuta en su totalidad o no se ejecuta. Una LUW de SAP de una transacción usualmente contiene varias LUWs de base de datos, una LUW comienza cada vez que ejecutamos una transacción, cuando los cambios a la base de datos de la LUW previa se confirman mediante un commic o cuando los cambios a la base de datos de la LUW previa se cancelan y una LUW finaliza si los cambios a la base de datos han sido confirmados o cuando los cambios a la base de datos han sido cancelados.

4) MONITORIZACIÓN DEL ESTADO DE LAS ACTUALIZACIONES DEL SISTEMA.

El sistema SAP R/3 dispone de una herramienta para la activación y desactivación genérica de los servicios de actualización, así como la monitorización de las actualizaciones en curso y de las posibles actualizaciones interrumpidas que puedan haber ocurrido.

Ante un problema grave en la base de datos SAP reacciona desactivando la actualización con lo cual todas las modificaciones a realizar en la base de datos se quedan en un estado de espera hasta que la actualización vuelva estar activa con la finalidad de preservar la integridad de los datos y queda registrada en el log.

Será tarea del administrador el subsanar el error que produjo la desactivación de la actualización del sistema y su posterior activación.

NOTA: la actualización es activada automáticamente cada vez que el sistema SAP R/3 es arrancado en el servidor, por lo que sólo se deberá monitorizar su posible desactivación.

La transacción desde donde podremos gestionar centralmente la actualización es la SM13.

Transacción SM13: Se utiliza para el control de las actualizaciones en el sistema SAP.

En ella se visualiza si la actualización del sistema está activa o ha sido desactivada por alguna causa. Si la actualización está desactivada, el botón Info nos proporciona qué proceso y usuario has causado su desactivación.

5) OBJETOS DE BLOQUEO

SAP dispone de un sistema de gestión de bloqueos de objetos para evitar la modificación concurrente de un objeto. Con esto, se asegura la consistencia de los objetos en SAP R/3.

Cuando un usuario accede a modificar un objeto, el sistema genera un registro de bloqueo con la información necesaria. Si un segundo usuario intenta modificar ese mismo objeto mientras el 1er usuario lo tiene bloqueado, el sistema le muestra al segundo usuario un mensaje de error indicándole que un usuario ya está tratando el objeto solicitado.

Los bloqueos se establecen al iniciar las transacciones de modificación y no son liberados hasta que el usuario pulsa “Grabar”, la información es actualizada en la base de datos y la transacción es finalizada.

Toda modificación de un objeto desde cualquier aplicación estándar dentro de SAP R/3 genera entradas de bloqueo.

NOTA: Será tarea del departamento de desarrollo asegurar que las nuevas aplicaciones hechas a medida dentro de SAP R/3 generen tales bloqueos cuando desde estas nuevas aplicaciones se acceda a modificar algún objeto.

La transacción que nos muestra los bloqueos actualmente activos en el sistema es la SM12.

Transacción SM12: Se utiliza para visualizar y remover los bloqueos en el sistema SAP.

En esta pantalla disponemos de unos parámetros de selección para filtrar los bloqueos actualmente activos. Los parámetros son:

· Nombre de tabla.

· Argumento de bloqueo.

· Mandante.

· Usuario.

En general no conoceremos el argumento de bloqueo, ya que esa información depende del objeto que se esté modificando. Es más común conocer la tabla o usuario que está produciendo un bloqueo.

Una vez rellenos los parámetros de selección con los valores deseados pulsamos el botón “Enter” en la barra de aplicaciones y nos aparecerá un listado con las entradas de bloqueo que cumplen la selección realizada.

Un objeto de bloqueo es una unión virtual de varias tablas SAP que sincroniza el acceso simultáneo de dos usuarios al mismo set de datos. Sirven para controlar la concurrencia de procesos sobre un mismo objeto. Siempre están asociados a tablas del diccionario. Un objeto de bloqueo es un semáforo sobre una tabla. Cuando se define un objeto de bloqueo se generan automáticamente dos módulos de funciones que controlan dicho semáforo, uno de ellos es ENQUEUE_* (nombre) que controla la petición de bloqueo sobre el objeto y el otro es DEQUEUE_* (nombre) que controla la liberación del bloqueo sobre el objeto. Para la creación de un objeto de bloqueo se utiliza la Transacción SE11.