![](/cvo_files/imgs_sap_abap/logos/logo_cvo_academy_it.png)
✒️SAP Los servicios de actualización
SAP Los servicios de actualización
![SAP Los servicios de actualización SAP Los servicios de actualización](https://www.cvosoft.com/cvo_files/imgs_sap_abap/og-images/21.jpg)
UNIDAD 2. TEMA 5 : INTRODUCCIÓN AL SERVICIO DE ACTUALIZACIÓN DE SAP R/3
El servicio de actualización de SAP R/3 es el 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 diálogo, batch o update.
ACTUALIZACIÓN SINCRÓNICA Y ASINCRÓNICA
La actualización en el sistema de datos 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. De esta manera, el usuario se desentiende totalmente del proceso de actualización, ya que no debe esperar a que el sistema acceda a actualizar la base de datos para seguir trabajando. Esto se traduce en una mejora del rendimiento, ya que el proceso de diálogo del usuario no espera a que se terminen las actualizaciones para seguir procesando las peticiones de ese usuario.
La actualización sincrónica, aunque es menos frecuente, también se produce en el sistema R/3. En este caso, 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 manera, el proceso de diálogo o batch (batch es un modo de procesamiento, también llamado procesamiento por lotes, en el que se planifica cuando va a realizarse la ejecución de un programa. Se utiliza cuando el tiempo de procesamiento es muy alto) 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 peor que en el caso de la actualización asincrónica.
Los usuarios no pueden elegir si los campos 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á el analista de la aplicación quien decida qué tipo de actualización realizar.
PROCESOS DE ACTUALIZACIÓN V1 Y V2
La actualización asincrónica presenta además una ventaja adicional: implementa las LUWs, que son 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 puedan surgir al grabar una LUW a medias.
La actualización asincrónica consiste de dos tipos de actualización: V1 Y V2. El sistema R/3 distingue entre componentes de actualización crítica primaria (V1) y secundaria 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ándoles diferentes LUWs.
Para asegurar la consistencia de los datos, las actualizaciones V1 se procesan con la supervisión del gestor de bloqueos de SAP R/3 que impide que se realicen concurrentemente varias modificaciones sobre el mismo objeto.
Existen dos tipos de LUWs: las LUWs de base de datos y las LUWs de SAP. En el caso de las LUWs de base de datos, una LUW es una secuencia de operaciones de datos que no pueden ser divididas; 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 de las cuales puede ser finalizada con un commit a la base de datos que se genera automáticamente. Por el contrario, una LUW del sistema SAP es un proceso de negocio que no puede dividirse. El proceso se ejecuta en su totalidad o no se ejecuta. Una LUW de SAP de una transacción contiene generalmente 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 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 han sido cancelados.
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 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, el sistema SAP R/3 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 a estar activa. Esta desactivación automática tiene lugar para preservar la integridad de la base de datos y su ejecución queda registrada en el log del sistema. Será tarea del administrador 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 R/3 es arrancado en el servidor, por lo que solo se deberá monitorizar su posible desactivación.
La transacción donde podemos gestionar centralmente la actualización es la SM13. Se utiliza para el control de las actualizaciones en el sistema SAP. En ella se muestra básicamante si la actualización del sistema está activa o ha sido desactivada por alguna causa. En este caso, el botón info nos proporciona qué proceso y usuario han causado su desactivación. El resto de campos son campos de selección para monitorizar las actualizaciones que han tenido lugar y han fallado o las que están en curso.
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 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 primer usuario lo tiene bloqueado, el sistema le muestra al segundo usuario un mensaje de error indicando que otro 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 del sistema SAP R/3 genera entradas de bloqueo. Es 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 un objeto.
La transacción que nos muestra los bloqueos actualmente activos en el sistema es la SM12. Se utiliza para actualizar y remover los bloqueos en el sistema SAP. En la pantalla que nos muestra esta transacción hay unos parámetros de selección para filtrar los bloqueos actualmente activos. Los parámetros son: tabla, argumento de bloqueo, mandante y usuario. En general no conoceremos el argumento del 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 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 de 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 MQ_NOMBRE que controla la petición de bloqueo sobre el objeto, y el otro es DQ_NOMBRE que 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 que por ejemplo dos usuarios no estén modificando los mismos datos a la vez. Para la creacción de un objeto de bloqueo utilizamos la transacción SE11
 
 
 
Agradecimiento:
Ha agradecido este aporte: Ximena Rojas Ortiz
Sobre el autor
Publicación académica de Ana Maria Benito Sanchez, en su ámbito de estudios para el Carrera Consultor Basis NetWeaver.
Ana Maria Benito Sanchez
España - Legajo: PA34H
✒️Autor de: 35 Publicaciones Académicas
🎓Egresado del módulo:
Disponibilidad Laboral: FullTime