✒️SAP BASIS El proceso de bloqueo
SAP BASIS El proceso de bloqueo
Unidad 2 – Lección 6: Proceso de Bloqueo
Para asegurar la consistencia de datos dentro de SAP, debemos asegurarnos que los registros de datos no pueden ser accedidos y cambiados por más de un usuario al mismo tiempo. Para lograr esto, el sistema SAP tiene su propio concepto de administración de bloqueos (lock management).
Transacciones de base de datos
Desde la perspectiva de la BD, cada paso de diálogo forma una unidad física y lógica: la transacción de BD.
El sistema de BD sobre el que corre SAP coordina éstas transacciones.
Transacciones SAP
Para SAP esto no es suficiente para asegurar la consistencia, por ello administra su propio concepto de bloqueo. Esto se logra utilizando el work process de enqueue (encolado). Esto asegura la independencia de plataforma utilizada para el sistema.
Sistema de bloqueo en SAP
El concepto de bloqueo en SAP funciona sobre el principio de que los programas SAP realizan entradas de registros en la tabla de bloqueo (lock table). Solo pueden generarse nuevas entradas en esta tabla si no existen otras ya para el objeto que intenta bloquearse.
Enqueue Work Process
El enqueue block process maneja los bloqueos lógicos de las transacciones de SAP en la tabla de bloqueo. Esta tabla se sitúa en la memoria principal de la instancia donde el proceso corre.
Un WP de diálogo que corre en la misma instancia que el enqueue WP puede acceder directamente a la tala de bloqueo en la memoria principal para checar si un nuevo bloqueo puede generarse, esto es, si no ocurrirá un conflicto con un bloqueo ya establecido.
Si el bloqueo puede crearse, entonces el WP de diálogo crea la entrada en la tabla y se le entrega una key al usuario la cual se mantiene en memoria de contexto de usuario.
Si el WP de diálogo y el enqueue process corren en diferentes instancias se comunican a través del message server. En este caso la solicitud de bloqueo se reenvía desde el WP de diálogo al enqueue work process a través de los respectivos dispatchers y el messsage server.
El enqueue work process es quien se encarga de checar si puede crearse un bloqueo en la tabla. Si esto es posible, el bloqueo se realiza y la key generada se envía a través del dispatcher y el messsage server.
Modos de bloqueos
Cuando se solicita el bloqueo, el sistema verifica si el bloqueo generará un conflicto con alguna de las entradas que ya pudiese existir en la tabla. Si esto ocurre, la solicitud de bloqueo es rechazada. La aplicación informa al usuario que la operación solicitada no puede realizarse en este momento.
Los desarrolladores son quienes deciden el modo de bloqueo para la aplicación:
i. Bloqueo de escritura exclusivo (Exclusive write lock): denominado con la letra E en la tabla de bloqueos. Los datos bloqueados solo pueden ser editados por un usuario. El modo EXCLUSIVO (E) rechaza cualquier otro tipo de bloqueo por la transacción. Solo puede acumular otros bloqueos E por el mismo usuario.
ii. Bloqueo de Lectura compartido (Shared Lock Mode): Estos bloqueos se identifican con la letra S en la tabla de bloqueo. Se aceptan solicitudes adicionales de lectura. Una solicitud de escritura es rechazada.
iii. Bloqueo de escritura mejorado (Exclusive Noncumulative Write – Lock): Identificados con la letra X en la tabla de bloqueos, solo puede ser solicitado una sola vez, todas las demás solicitudes se rechazan.
iv. Bloqueo Otpimístico (Optimistic Lock): denominados con la letra O en la tabla de bloqueo. Al comienzo se establecen como bloqueos de lecturay luego pueden transoformarse en bloqueos de escritura. Permite bloqueos adicionales del mismo tipo sobre un objeto.
Cuando un usuario pasa al modo de modificación en una transacción el bloqueo pasa al tipo E. Si otros bloqueos de tipo O existen sobre el objeto estos son eliminados de la tabla.
La transacción SM12 muestra los bloqueos que actualmente hay en el sistema.
Transacción SM12
La transacción estándar SM12 se utiliza para la revisión de los bloqueos, si bien es un hecho que se pueden liberar desde ésta transacción, se debe utilizar con mucha cautela pues los bloqueos generalmente SAP los realiza cuando un dato se encuentra dentro de un evento transaccional, es decir que se ejecuta todo o nada y si lo liberamos podríamos generar inconsistencia de datos.
Sobre el autor
Publicación académica de Israel Fajardo Rivera, en su ámbito de estudios para la Carrera Consultor Basis NetWeaver.
SAP Junior
Israel Fajardo Rivera
Profesión: Ingeniero en Sistemas - Administración de Ti - Mexico - Legajo: LO19O
✒️Autor de: 18 Publicaciones Académicas
🎓Cursando Actualmente: Consultor Funcional Módulo FI Nivel Inicial
🎓Egresado del módulo:
Disponibilidad Laboral: FullTime
Presentación:
Eight years’ experience developing, implementing and managing sap complex projects within time, budgetary, scope and quality cons. strong analytical skills and a broad range of computer expertise.
Certificación Académica de Israel Fajardo
