✒️SAP Los servicios de actualización

El Servicio de Actualización de SAP:

Este servicio gestiona las modificaciones solicitadas por usuarios en la base de datos. Las actualizaciones se pueden generar mediante procesos de trabajo.

Miles de solicitudes son recibidas por el sistema SAP, para hacerle frente SAP usa un Sub-sistema de despacho conocido como Dispatcher a modo de realizar el procesamiento de las solicitudes e ir asignando las mismas a procesos de trabajo.

En SAP existen 7 tipos de procesos de trabajo:

• Dialogo: Se utilizan para cumplir todas las solicitudes de ejecución de pasos de diálogo activados por un usuario activo o ejecutar un programa de dialogo.
• Update: Ejecutan solicitudes de actualización o cambios de base de datos asincrónicos que son controlados por una declaración COMMIT WORK en un proceso de trabajo de diálogo.
• Enqueue: Administran la tabla e bloqueo en la memoria compartida o, si las transacciones de SAP tienen que sincronizarse, ejecuta las operaciones de bloqueo.
• Background: Ejecutan aquellos programas que lo hacen sin la interacción el usuario o ejecutan trabajos en segundo plano dependientes del tiempo o controlados por eventos.
• Message: Son responsables de enrutar mensajes entre los servidores de aplicaciones SAP.
• Gateway: Son los responsables de la transferencia de mensajes entre sistemas SAP.
• Spool: Pasan Flujos de datos secuenciales a impresoras o formato de impresión a impresora, archivo o base de datos.

La Transacción estandar para visualizar los procesos de trabajo que se ejecutan en el servidor en un momento dado es la SM50. De cada proceso de Datos se visualiza información variada, siendo las mas relevante El tipo de proceso de Trabajo, El Status, El programa que se ejecuta, El mandante, El usuario de SAP y la tabla de base de datos que modifica.

La Actualización Asincrónica y Sincrónica:

Asincrónica: En este tipo de actualización en la base de datos, SAP gestiona el requerimiento de actualización del usuario en un proceso aparte del dialogo del usuario.

En este tipo de actualización el usuario se desentiende del proceso de actualización traduciéndose en una mejora en el rendimiento ya que el proceso de dialogo no espera a que se terminen las actualizaciones para seguir procesando las peticiones de ese usuario.

Sincrónica: Menos frecuente se diferencia de la Asincrónica en que la petición de actualización en la base de datos se genera en el mismo proceso de trabajo que gestiona el resto de las peticiones del usuario. El proceso de dialogo debe esperar a que se realicen las actualizaciones en la base de datos antes de seguir procesando el resto de las peticiones del usuario, por lo que el rendimiento es menor que en la Asincrónica.

Los usuarios no pueden elegir si los cambios en la base de datos se realizan de forma Sincronica o Asincronica, eso depende de la programación de la aplicación en curso. Si se trata de una aplicación hecha a medida será tarea del analista de la aplicación el decidir que tipo de actualización realizar.

Los Procesos de Actualización V1 y V2

La actualización Asincrónica presenta ademas una ventaja adicional. Implementa las LUW que consisten en bloques auto consistentes de datos, de tal forma que su actualización en la base de datos es llevada a cabo completamente.

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

La actualización asincrónica, consiste de 2 tipos de actualización V1 y V2

SAP distingue 2 tipos de actualización, Primaria Critica V1 y Secundaria No Critica V2, esto permite dar prioridad de procesamiento a la V1 asignando diferentes LUWs para así realizar dicho procesamiento lo mas pronto posible. Las V1 se procesan con la supervisión del gestor de bloqueos de SAP que impide que varias modificaciones sobre el mismo objeto se realicen concurrentemente.

Existen 2 tipos de LUWs, las LUW de Base de Datos y las LUW de SAP.

En el caso de las LUW de Base de Datos, una LUW es una Secuencia de Operaciones de Datos que no puede ser dividida, las operaciones se realizan 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 puede ser finalizada con un COMMIT a la Base de Datos el cual se genera automáticamente...

Al contrario una LUW del Sistema 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 muchas 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 COMMIT o cuando los cambios a la Base de Datos de la LUW Previa se cancelan. Una LUW finaliza cuando los cambios a la base de datos han sido confirmados o cancelados.

La Motorización del Estado de las Actualizaciones del Sistema.

El Sistema SAP cuenta con una herramienta para la activación y desactivación genérica de los servicios de actualización, asi como para 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 quedan en un estado de espera hasta que la actualización vuelva a estar activa.

Esta desactivación automática tiene lugar en pos de preservar la integridad de la base de datos y su ejecución queda registrada en el Log del sistema.

Será tarea de los administradores del sistema SAP (SAP BASIS) el resolver el error que produjo la desactivación de la actualización del sistema y su posterior activación.

La actualización es Activada unicamente cada vez que el sistema SAP es arrancado en el servidor por lo que sólo se deberá monitorizar su posible desactivación

Mediante la transacción SM13 se puede gestionar centralmente la actualización. En ella se muestra básicamente si la actualización ha sido desactivada, nos muestra que proceso y usuario han causado su desactivación. El resto son campos de selección para monitorizar as actualizaciones que han tenido lugar y han fallado o las que están en curso.

Los Objetos de Bloqueo

SAP Dispone de un sistema de Gestión de Bloqueos para evitar la modificación concurrente de un objeto (Documento contable, Solicitud de Compra o una Entrada a una Base de Datos. Con esto, se asegura la consistencia de los Objetos SAP.

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

Los Bloqueos se establecen al iniciar las transacciones de modificación y no son liberados hasta que el usuario pulga el botón Grabar, la información es actualizada en la base de datos y la transacción es finalizada. Toda modificación de un objeto dese cualquier aplicación estándar dentro de SAP genera un bloqueo.

Será tarea del departamento de desarrollo asegurar que las nuevas aplicaciones hechas a medida dentro del SAP, 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 allí podemos visualizar y remover los bloqueos en el sistema SAP.

Los parámetros de selección para filtrar los bloqueos actualmente activos son:

• Tabla
• Argumento de Bloqueo
• Mandante
• Usuario

Por lo general se desconoce el Argumento de Bloqueo, ya que esa información depende del objeto que se esté modificando. Es mas común conocer la tabla o el usuario que está produciendo un bloqueo.