✒️SAP BASIS El proceso de bloqueo
SAP BASIS El proceso de bloqueo
Lección 6
Para asegurar la consistencia de datos dentro de nuestro sistema SAP, debemos asegurarnos que los registros de datos no puedan se accedidos y cambiados por más de una usuario al mismos 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 base de datos, vimos en la lección anterior que cada paso de dialogo forma una unidad física y lógica: la transacción de base de datos. El sistema de base de datos sobre el que corre nuestro sistema SAP puede coordinar este tipo de transacciones de base de datos.
Transacciones SAP
Desde el punto de vista SAP, de todas formas, esto no es suficiente para asegurar la consistencia porque las transacciones SAP, las cuales se forman por una secuencia lógica de pasos de trabajo relacionados que son consistentes en término de negocio, los cuales se forman generalmente de varios pasos de dialogo.
El sistema SAP necesita administrar su propio concepto de bloqueo. Esto se logra utilizando el work Process de enqueue (encolado). Esto también asegura la independencia de plataforma utilizada para el sistema.
Sistema de bloqueo SAP
El concepto de bloqueo de 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 work 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.
En la figura 261 se muestra un escenario con 2 instancias, podemos deducir que la instanciacentral es aquella donde el enqueue work process se encuentra corriendo.
Un work process de dialogo que corre en la misma instancia que el enqueue work process puede acceder directamente a la taba de bloqueo en la memoria principal para chequear si un nuevo bloqueo puede generarse, esto es, si no ocurrirá un conflicto con un bloqueo ya establecido.
Si el bloqueo puede crearse, entonces work process de dialogo crea la entrada en la tabla y se le entrega una key (llave) al usuario la cual se mantiene en la memoria de contexto de usuario.
Si el work process de dialogo y el enqueue work process corren en diferentes instancias se comunicaran a través del message server. En este caso la solicitud de bloqueo se reenvía desde el work process de dialogo al enqueue work process a través de los respectivos dispatchers y el message server.
5 Modos de bloqueos.
Cuando se solicita el bloqueo, el sistema verifica si el bloqueo generará un conflicto con alguna de las entradas que ya pudiesen 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:
Bloqueo de escritura exclusivo (Exclusive write lock) denominado con la letra E en la tabla de bloqueos, Losa datos bloqueados solos pueden ser editados por un usuario. El modo exclusivo (E) rechaza cualquier otro tipo de bloqueo por otra transacción. Solo puede acumular otros bloqueos E por el mismo usuario.
Bloqueo de lectura compartido (shared lock mode) estos bloqueo se identifican con la letra S en la tabla de bloqueo. Se aceptan solicitudes adicionales de lectura. Una solicitud de escrita es rechazada.
Bloqueo de escritura mejorado (Exclusive noncumulative Write Lock) identificados con la letra X en la tabla, solo puede ser solicitado una vez, todas las demás solicitudes se rechazan
Bloqueo optimistico (optimistic Lock) denominados con la letra O en la tabla de bloqueo. Al comienzo se establecen como bloqueos de lectura y luego pueden transformarse 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.
SM12: Esta transacción estándar se utiliza para la revisión de bloqueos, si bien es un hecho que se pueden liberar desde esta 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.
Nunca debemos eliminar bloqueos de la tabla de bloqueos a menos que estemos seguros de que el usuario que lo generó no está trabajando en el sistema, de otra forma podemos provocar inconsistencias en los datos.
 
 
 
Sobre el autor
Publicación académica de Lina Marcela Zapata Suarez, en su ámbito de estudios para la Carrera Consultor Basis NetWeaver.
Lina Marcela Zapata Suarez
Profesión: Ingeniera Informática. - Colombia - Legajo: AB47Z
✒️Autor de: 109 Publicaciones Académicas
🎓Egresado de los módulos:
Presentación:
Ingeniera informática.
Certificación Académica de Lina Zapata