✒️SAP Los servicios de actualización

Los servicios de actualización

El servicio de actualización de SAP

Existen 7 tipos de proceso de trabajo:

° D - diálogo:

Se utilizan para cumplir todas las solicitudes de ejecución de pasos de dialogo activados por un usuario activo o ejecutar un programa de dialogo.

° V – 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.

° E – Enquenque:

Administra la tabla de bloqueo en la memoria compartida transacciones de SAP tienen que sincronizarse ejecuta las operaciones de bloqueo.

° B – Background:

Ejecutan aquellos programas que se ejecutan sin la interacción del usuario o ejecutan trabajos en segundo plano dependientes del tiempo o controlados por eventos.

° M – Message:

Son los responsables de rotar los mensajes entre los servidores de aplicaciones SAP.

° G – Gateway:
Son los responsables de la transferencia de mensajes entre sistemas SAP.

° S – Spool:

Pasan flujos de datos secuenciales a impresoras o formato de impresión a impresora, ejecutando en este momento en el servidor.

A través de la transacción estándar SM 50 podemos visualizar los procesos de trabajo que se están ejecutando en este momento en el servidor.

De cada proceso de trabajo visualizamos distinta información, la más relevante es: el tipo de proceso de trabajo, el estatus, el programa que se ejecuta, el mandante, el usuario de SAP, la acción y la tabla base de datos que modifica.

La actualización asincrónica y sincrónica

La actualización en la base de datos de un sistema SAP puede ser de 2 tipos:

° Asincrónica

en su mayoría la actualización en la base de datos es asincrónica, es decir, el sistema gestiona el requerimiento de actualización del usuario en un proceso aparte del proceso de dialogo del usuario.

El efecto de este tipo de actualizaciones es que el usuario se desentiende totalmente del proceso de actualización ya que no debe esperar a que el sistema acceda a actualizar a la base de datos para poder seguir trabajando. El proceso de diálogo del usuario no espera a que se terminen las actualizaciones para seguir procesando las peticiones de ese usuario.

° Sincrónica

aunque es menos frecuente también se produce en el sistema SAP y sí 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.

De esta forma el proceso de diálogo o batch 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 será peor en el caso de la actualización asincrónica.

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

Si se trata 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.

Los procesos de actualización V1 y V2

La actualización asincrónica presenta además una ventaja adicional: implementa las LUW. Las cuales 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 una LUW medias.

La actualización asincrónica consiste en 2 tipos de actualizaciones V1 y V2:

El sistema SAP distingue entre componentes de actualización crítica primaria (V1) y secundaria no crítica (V2). la diferenciación entre estos 2 tipos de actualización permite que el sistema, pero es los cambios críticos en la base de datos por delante de los cambios menos críticos, asignándoles diferentes LUWs; esto es necesario ya que los componentes V1 deben ser realizadas cuanto antes.

Para asegurar la consistencia de los datos coma las actualizaciones 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 de base de datos y las de SAP.

En las de base de datos es una secuencia de operaciones que no puede ser dividida, las operaciones se realizan en su totalidad o no se realizan.

Una transacción de SAP puede incluir muchas LUWs de base de datos, cada una puede ser finalizada con un commit a la base de datos en la cual se genera automáticamente y 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 es una transacción, usualmente contiene varias LUWs de base de datos. Una LUW comienza cada comienza cada vez que ejecutamos una transacción cuando los cambios a la base de datos de la LUW previa, se confirma 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 cuando los cambios en la base de datos han sido cancelados

La monitorización del estado de las actualizaciones del sistema

El sistema SAP dispone de una herramienta para la activación y desactivación genérica de los servicios de actualización, así 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 el trabajo 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, es decir los SAP BASIS, el subsanar el error que produjo la desactivación de la actualización del sistema y su posterior activación.

La actualización es activada automáticamente cada vez que el sistema SAP 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. La cual se utiliza para el control de las actualizaciones en el sistema SAP.

En ella básicamente se nos muestra si la actualización del sistema está activa o ha sido desactivada por alguna causa.

Si la actualización ha sido desactivada el botón “Info” nos proporciona que proceso y usuario han causado su desactivación.

Los 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.

Cuando hablamos de un objeto nos referimos por ejemplo a un documento contable coma una solicitud de compra o una entrada de una tabla base de datos.

Cuando un usuario accede a modificar un objeto el sistema genera un registro de bloqueo con la información necesaria. Sí un segundo usuario intenta modificar ese mismo objeto mientras el primer usuario lo tiene bloqueado el sistema le muestra el 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 está 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 genera entradas de bloqueo.

Será tarea del departamento de desarrollo asegurar que las nuevas aplicaciones hechas a medida dentro de 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 la cual se utiliza para visualizar y remover los bloqueos en el sistema SAP.

Disponemos de unos parámetros de selección para filtrar los bloqueos actualmente activos:

• 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.

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 tablas SAP que sincroniza el acceso simultáneo de 2 usuarios al mismo set de datos.

Sirven para controlar la concurrencia de procesos del 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 2 módulos de funciones que controlan dicho semáforo, uno de esos controla la petición de bloqueo sobre el objeto y el otro controla la liberación del bloqueo sobre el objeto.

Mediante las funciones que genera el objeto de bloqueo conseguimos bloquear la tabla mientras estamos accediendo a ella y desbloquearla al final, de esta forma nos aseguramos de que dos usuarios no modifiquen los mismos datos a la vez.

Para la creación de un objeto de bloqueo utilizamos la transacción SE11.