✒️SAP Los servicios de actualización

Curso: Introducción a SAP

Unidad 2. SAP GUI y los servicios del sistema SAP.

Lección 5. Servicios de actualización.

1. Introducción al servicio de actualización de SAP R/3

El servicio de actualización en SAP R/3, es muy importante por ser el responsable de las modificaciones, solicitadas por los usuarios, en la base de datos.

Tales actualizaciones pueden desarrollarse a través de procesos de trabajo tipo diálogo, batch o update.

2. Actualización sincrónica y asincrónica.

La actualización, en la BD, de un sistema SAP R/3 es mayoritariamente asincrónica, es decir el sistema gestiona el requerimiento de actualización del usuario, en un proceso aparte, del proceso de diálogo del usuario y éste se desentiende de tal actualización, responsabilidad del propio sistema SAP.

De esta manera, se logra un mejor rendimiento. El proceso de diálogo de usuario no debe esperar a que terminen las actualizaciones, para continuar procesando nuevas peticiones, el usuario.

A modo de ejemplo, sea un proceso de trabajo de un usuario, entonces las actualizaciones asíncronas, se realizan paralelamente. Ver gráfico actualización asincrónica.

La actualización sincrónica, menos frecuente, se produce, también, en sistema SAP R/3 y la diferencia con la asincrónica es que la petición de actualización, en la BD, se realiza en el mismo proceso de trabajo de usuario, conjuntamente con otras peticiones de usuario.

De esta manera, el proceso de diálogo o batch, deberá esperar a que se realicen las actualizaciones, en la BD, antes de procesar las nuevas peticiones; lo cual se traduce en una perdida de rendimiento. Ver gráfico de actualizaciones sincrónicas.

Los usuario no pueden saber si las actualizaciones son asincrónicas o sincrónicas, pues ello, lo decidió el programador del soft de la aplicación en curso.

Tal programador fijará oportunamente cual de las dos actualizaciones aplicará.

3. Procesos de actualización V1 y V2.

La actualización asincrónica, presenta otra ventaja, implementa las LUW (bloques de datos, autoconsistentes, que en cada actualización lo hacen completamente), que ante un problema en la BD, no se grabarían y quedaría la información previa, garantizándose que no se produzcan inconsistencia , al guardar a medias, tales LUW, en la BD.

La actualización asincrónica, cuenta con tipos de componentes de actualización:

1. Actualización crítica primaria. V1. El sistema genera los LUW y los procesa de inmediato, conforme la prioridad de los datos.
2. Actualización no crítica, secundaria. V2. Sistema genera LUW distintos a los de V1 y actualiza, luego de los anteriores.

La consistencia de datos, en las actualizaciones V1, se realizan bajo la supervisión del gestor de bloqueos de SAP, impidiendo que usuarios puedan modificar el mismo dato, al mismo tiempo.

En SAP, existen dos tipos de LUW, a saber:

>> LUW de base de dato. Se trata de una secuencia de operaciones de datos, indivisible, de modo que la secuencia se realiza totalmente o no se realiza.

Una transacción de SAP, puede incluir varias LUW de base de datos, c/u de las cuales puede ser finalizada, con un commit a la BD, este commit se genera automáticamente.

>> LUW de SAP. En este caso es un proceso de negocio, indivisible, también, el cual se ejecuta totalmente o no se ejecuta.

Una LUW de SAP, de una transacción, contiene usualmente varias LUW de base de dato. Una LUW comienza toda vez que ejecutamos una transacción, cuando los cambios a la BD, de la LUW previa, se confirma con un commit, o cuando los cambios a la BD, de la LUW previa, se cancelan y una LUW finaliza, cuando los cambios a la BD han sido confirmado o cuando los cambios a la BD, han sido cancelados.

4. Monitorización del estado de las actualizaciones del sistema.

El sistema SAP R/3 cuenta con una herramienta para la activación y desactivación genérica de los servicios de actualización, como también, para monitorear las actualizaciones en curso, o aquellas que fueron interrumpidas.

Ante un problema en la BD, SAP R/3 reacciona desactivando el servicio de actualización, con lo que las modificaciones en curso quedan en un estados de espera (stand by), hasta que el servicio de actualización es nuevamente habilitado.

Esta desactivación automática, preserva la integridad de datos y su ejecución queda registrada en el log del sistema.

El administrador del sistema, deberá encontrar la causa de la desactivación automática y habitarla, posteriormente.

El sistema de actualización es activado, al iniciarse el sistema SAP R/3, por lo que hay que monitorear solamente la desactivación del sistema de actualización, que hayan ocurrido.

SM13, es la transacción que permite gestionar centralmente y controlar las actualizaciones, del sistema SAP.

Colocando en el campo de comando, SM13, aparecerá una pantalla en la que introduciremos una serie de datos, como mandante, usuario, el status de las actualizaciones que deseamos ver(cancelado-a actualizar-V1 ejecutado-V2 ejecutado-tod.). También, casilla de selección para el rango de días y el rango de horas. También, un campo para colocar el máximo de eventos a realizar o contabilizar. El servidor de la actualización, y una casilla de verificación(para informar si el servicio de actualización está activo o no. Y por supuesto el comando de ejecución(gestión).

La SM13 nos suministra información sobre si el servicio de actualización está activo o ha sido desactivado por alguna causa.

Y si el sistema de actualización, ha sido desactivado, nos informa qué proceso y usuario ha causado la desactivación.

Los demás campos, son de selección para monitorear actualizaciones que se han interrumpido y también, de las que están en curso.

5. Objetos de bloqueo.

SAP, cuenta con un sistema de gestión de bloqueo, para garantizar la preservación de los objetos del sistema SAP R/3, en el caso que haya simultaneidad en la manipulación de los mismos, evitándose la inconsistencia de los mismos.

En esa situación, el sistema emite un mensaje de error para el segundo usuario, advirtiéndole que ese objeto está siendo manipulado por otro usuario.

Los bloqueos se establecen al iniciar transacciones de modificación y no son liberados, hasta que el usuario en curso pulse grabar, la información es actualizada en la BD y la transacción finalizada.

Toda modificación realizada, en cualquier aplicación de SAP, genera entradas de bloqueo.

Es importante que el departamento de desarrollo asegure que todas las aplicaciones nuevas, hechas a medida dentro de SAP R/3, generen tales bloqueos, toda vez que desde cualquiera de estas aplicaciones se intente modificar un objeto.

SM12, es la transacción que nos permite visualizar los bloqueos activos y también, removerlos, en el sistema SAP R/3. Ver la imagen de la transacción SM12.

En la pantalla correspondiente, se muestran unas casillas de selección(Nombre de tabla, argumento de bloqueo, Mandante y usuario) que permiten filtrar la información que buscamos.

El argumento de bloqueo, en general no es conocido, atento a que depende del objeto que se esté modificando. Los demás parámetros, son más conocibles.

Rellenas las casillas de selección, se presiona enter, apareciendo otra pantalla modo SAP, con el listado de bloqueos, surgido de la selección realizada.

Objeto de bloqueo. En una unión virtual de varias tablas SAP, asociadas a tablas de diccionario, que sincronizan el acceso simultáneo de usuarios, al mismo set de datos, cuando se les ocurra modificar el mismo objeto.

Un objeto de bloqueo, es un semáforo sobre una tabla, que al ser definido genera dos módulos de funciones, (MQ_nombre) que controla la petición de bloqueo sobre el objeto y una segunda, (DQ_nombre), que controla el desbloqueo sobre el objeto. Ambas funciones controlan el semáforo. Mientras estemos trabajando sobre el objeto(tabla, por ejemplo), estará bloqueado el acceso de otros usuarios. Al finalizar, la DQ_nombre, permitirá el desbloqueo, al finalizar nuestro trabajo.

SE11, es la transacción para genera un objeto de bloqueo.