SERVICIOS DE ACTUALIZACIÓN
INTRODUCCIÓN AL SERVICIO DE ACTUALIZACIÓN DE SAP R/3
Este servicio es muy importante ya que se encarga 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 (job ) o update.
* Procesos de trabajo tipo diálogo: Se encargan de las tareas interactivas del sistema R/3.un proceso de trabajo de diálogo correspondientes a las sesiones interactivas de los usuarios.
*Proceso batch: Llamamos batch input a un tipo de proceso que se lanza en fondo y mediante el cual podemos simular la introducción de datos en una transacción tal y como lo haríamos si la estuviésemos procesando manualmente. La diferencia es que mediante batch input podemos hacer esto proceso de forma repetitiva, cosa que si tuviéramos que llevarlo a cabo manualmente se convertiría en un proceso muy tedioso.
ACTUALIZACIÓN SINCRÓNICA Y ASINCRÓNICA
La actualización en la bd de un sistema R/3 es en su mayoría asincrónica, es decir, el sistema gestiona el requerimento de actualización del usuario en un proceso aparte del proceso de diálogo del usuario. El proceso de diálogo del usuario no tiene que esperar a que terminen las actualizaciones para seguir procesando las peticiones de ese usuario. Hay una mejora del rendimiento.
*Actualización sincrónica: es menos frecuente y se realiza en el mismo proceso de trabajo que gestiona el resto de peticiones del usuario. Aquí 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, el rendimiento es peor.
Nota: los usuarios no pueden elegir que tipo de actualización se realizará, 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.
PROCESOS DE ACTUALIZACIÓN V1 Y V2
La actualización asincrónica implementa LUW, los LUWs consisten en bloques auto consistentes de datos, de tal forma que su actualización en la bd es llevada a cabo completamente.
LUW: Se define como un paso elemental de proceso que funciona como un mecanismo de bloqueo que protege la integridad de las transacciones. O como un conjunto de pasos dentro de una transacción, y todos esos pasos deben ejecutarse y acabar correctamente entes de continuar la lógica de la transacción.
*Actualización asincrónica V1 (crítica primaria): el sistema procesa los cambios críticos en la bd por delante de los cambios menos críticos asignándoles diferentes LUWs, los V1 deben ser realizados cuanto antes y se procesan bajo supervisión del gestor de bloqueos de SAP R/3 que impide que varias modificaciones sobre el mismo objeto se realicen concurrentemente.
Actualización V2: secundaria no crítica.
LUW de BD: secuencia de operaciones de datos que no pueden ser divididas, las operaciones se realizan o bien en su totalidad no se realizan. Una transacción de SAP puede incluir muchas LUW de BD, cada una puede ser finalizada con un commite a la bd, el cual se genera automáticamente.
LUW de SAP: es un proceso de negocio el cual no puede dividirse el cual se ejecuta en su totalidad o no se ejecuta, una LUW de SAP de una transacción usualmente contiene varias LUWs de BD, una LUW comienza cada vez que ejecutamos una transacción cuando los cambios a la bd previa se confirman mediante un commite o se cancelan. Y una LUW finaliza cuando los cambios en la bd han sido confirmados o cancelados.
MONITORIZACIÓN DEL ESTADO DE LAS ACTUALIZACIONES DEL SISTEMA
La transacción desde donde podemos gestionar centralmente y controlar las actualizaciones es la SM13.
Aquí se muestra si la actualización sigue activa o ha sido cancelada. Si ha sido desactivada desde el botón info nos proporciona que proceso y usuario han causado su desactivación, los demás campos son campos de selección para monitorizar las actualizaciones que han tenido lugar y han fallado o las que están en curso.
El sistema R/3, ante un problema grave en la bd reacciona desactivando automáticamente la actualización, y las modificaciones se quedan en espera hasta que vuelva a estar activa la actualización, esto es para preservar la integridad de la bd y su ejecución queda registrada en el log del sistema.
La actualización es activada automáticamente cada vez que el sistema R/3 es arrancado en el servidor, por lo que el administrador debe monitorizar su desactivación.
OBJETOS DE BLOQUEO
Para asegurar la consistencia de los objetos en SAP R/3, se dispone de la gestión de bloqueos de objetos para evitar la modificación concurrente de un objeto.
Si 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 muestra al segundo usuario un mensaje de error indicando que ya hay un usuario tratando ese objeto.
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 bd y la transacción finalizada.
Toda modificación de un objeto en R/3 genera entradas de bloqueo. La transacción que nos muestra los bloqueos activos es la SM12.
El departamento de desarrollo debe asegurar que las nuevas aplicaciones hechas generen tales bloqueos, cuando desde estás nuevas aplicaciones se acceda a modificar algún objeto.
Para visualizar las listas con entrada de bloqueo en la transacción SM12, se disponen de parámetros de selección para filtrar los bloqueos actualmente activos como son:argumento de bloqueo (esta información no se conoce ya que depende del objeto que se está modificando), mandante y usuario.
*Objeto de bloqueo: unión de varias tablas SAP que sincronizan el acceso simultaneo de dos usuarios al mismo grupo de datos. Controlan la concurrencia de procesos sobre un mismo objeto y siempre están asociados a tablas del diccionario, el objeto de bloqueo es un semáforo sobre una tabla ,cuando se definen se generan automáticamente dos módulos de funciones que controlan dicho semáforo.
*Bloqueo ENQUEUE _ nombre:controla la petición de bloqueos sobre el objeto.
*Bloqueo DEQUEUE _ nombre: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 dos usuarios no estén modificando los mismos datos a la vez, para la creación del objeto de bloqueo utilizamos la transacción SE11.