✒️Los objetos de bloqueo en SAP

6.1. Concepto de transacción.

6.1.1. Transacción de Base de Datos ( DB LUW )

Una transacción de base de datos es introducida por un punto de sincronización el cual es puesto por la aplicación de la base de datos ( en el caso del sistema R/3).

En el curso de una transacción de base de datos, el sistema realiza actualizaciones de la tabla, en requerimientos hechos por el sistema R/3. Las entradas a la tabla modificada permanecen bloqueadas hasta que la transacción haya terminado.

Después de cada actualización de la base de datos, el sistema de base de datos informa al sistema R/3 que la actualización fue exitosa o no exitosa, en forma de un código de retorno.

Una transacción de base de datos es terminada por otro punto de sincronización puesto por el sistema R/3 el cual envía un COMMIT para confirmar las actualizaciones de las tablas, o un ROLLBACK al sistema de base de datos. En respuesta, el sistema de base de datos realiza un commit para confirmar las actualizaciones de la tabla, o realiza un rollback el cual cancela las actualizaciones realizadas por la transacción de base de datos. En este caso el estado 2 es idéntico al estado 1.

En ambos casos, los bloqueos hechos por la base de datos son liberados.

6.1.2. Transacción SAP.

Una transacción SAP consiste en procesos de dialogo. Un proceso de dialogo comienza cuando el usuario presiona Enter, cuando activa una función presionando alguna tecla función, hace un doble clic o escoge una función de un menú. Esto termina cuando la siguiente pantalla es desplegada.

En el curso de un proceso de dialogo, los módulos PAI pertenecen a la pantalla en ejecución y los módulos PBO pertenecen a la siguiente pantalla que es ejecutada.

Cada proceso de dialogo puede contener requerimientos de actualización (UPDATE, INSERT, DELETE).

6.1.3. Transacción SAP y Transacción DB.

Después de cada proceso de dialogo, el sistema R/3 automáticamente pasa un commit de base de datos al sistema de base de datos. El sistema de base de datos distribuye los requerimientos de actualización de un proceso de dialogo individual pasando por varias transacciones.

Un rollback en un proceso de dialogo no tiene efecto en actualizaciones previamente realizadas a la base de datos en procesos de dialogo previos.

6.1.4. Transacción SAP y Actualizaciones Asíncronas.

Una actualización asíncrona permite combinar un total de actualizaciones realizadas por procesos de dialogo consecutivos de una transacción SAP, en una unidad conocida como Logical Unit of Work (unidad lógica de Trabajo) o SAP LUW.

En el LUW, todas las actualizaciones son realizadas en una sola. Aquí los requerimientos de actualización no son pasados directamente a la base de datos, pero son almacenados en una tabla de registro (log table) para actualizarse.

El comando de ABAP/4 COMMIT WORK concluye el LUW. El sistema R/3 comienza un proceso de actualización especial el cual usa la tabla de registro (log table) para realizar la actualización en la base de datos dentro del contexto de una transacción de base de datos.

Si ocurre un error, el LUW es terminado por el comando ABAP/4 ROLLBACK WORK. Las entradas a la tabla de registro son descartadas y no comienza el proceso de actualización.

El COMMIT WORK termina la tarea del dialogo y continua en la tarea de actualización.

6.2. Concepto de Actualización Asíncrona.

En SAP, la actualización asíncrona para el manejo de requerimientos de bases de datos es dividida entre un programa de dialogo interactivo y un programa de actualización, el cual corre en background.

En SAP, la actualización asíncrona divide el proceso en actualizaciones de tiempos críticos (V1) y actualizaciones de tiempos menos críticos (V2).

6.2.1. Programa de dialogo y módulo de función para actualización.

Para la implementación del concepto de actualización, se requiere de un programa para el proceso de dialogo y uno o más módulos de función para el proceso de actualización.

Si en el comando CALL FUNCTION en el programa de dialogo tiene además IN UPDATE TASK, la llamada no es ejecutada inmediatamente, pero es agregada en la tabla de registro.

6.2.2. Modulo de Función de Actualización.

Se pueden asignar módulos de función usados en una transacción SAP a diferentes grupos de funciones.

En la sección de administración, se especifica el tipo de función: V1 (ejecución inmediata) o V2 (ejecución posteriormente).

En un módulo de función para actualización, solo los parámetros de entrada (import) y las tablas son tomadas en cuenta. Se especifica los campos de referencia o la estructura según corresponda.

Los parámetros de salida (export parameters) y las excepciones (exceptions), son ignorados en una función de actualización.

Si se desea reglamentar la opción para realizar después una actualización después de un error, con la transacción SM13 seleccione Immediate start, no restart.

6.2.3. Programa de diálogo y tabla de registro.

En el momento que cada CALL FUNCTION ... IN UPDATE TASK es ejecutada en un programa en diálogo, se agrega una entrada en la tabla registro (log table) con el nombre de la función y sus parámetros.

Todas los requerimientos de actualización en un SAP LUW tiene la misma llave (conocida como update key).

Un registro de encabezado (log header) para asociar los registros se genera solo cuando un COMMIT WORK es ejecutado.

6.2.4. Rollback en los programas de Dialogo: Borrando marcas de Actualización.

1. PROGRAM . . .
2. MODULE <read ok-code>.
3. . . .
4. CASE <ok-code>.
5. WHEN 'UPDA'.
6. .
7. COMMIT WORK.
8. WHEN 'BACK'.
9. .
10. ROLLBACK WORK.
11. .
12. ENDCASE.
13. . . .
14. ENDMODULE.

En el curso de un dialogo que involucra varios pasos, se puede juntar una serie de actualizaciones y ejecutar el requerimiento asociado con un COMMIT WORK explícito.

Sin embargo, se pueden tener para borrar todas las actualizaciones del SAP LUW en curso con ROLLBACK WORK. El comando ROLLBACK regresa todas las actualizaciones hechas por el LUW en ejecución.

.2.5. Rollback en el Programa de Actualización.

1. FUNCTION-POOL . . .
2. . . .
3. FUNCTION . . .
4. . . .
5. UPDATE . . .
6. IF SY-SUBRC NE 0.
7. MESSAGE Annn . . .
8. ENDIF.
10. INSERT . . .
11. IF SY-SUBRC NE 0.
12. MESSAGE Annn . . .
13. ENDIF.
14. . . .
15. ENDFUNCTION.

La función de actualización pasa el requerimiento de actualización a la base de datos y analiza el código de retorno. Si la base de datos no ejecuta correctamente la actualización, en el módulo de función se decide la forma de proceder en estos casos.

Si se desea realizar un Rollback de base de datos en el programa de actualización, es necesario desplegar un mensaje tipo abend.

Los comandos ABAP/4 COMMIT WORK Y ROLLBACK WORK no son permitidos en módulos de función de actualización. Solo pueden ser usados en programas de dialogo.

6.2.6. PERFORM <subrutina> ON COMMIT.

Si se ejecuta una subrutina con PERFORM <subrutina> ON COMMIT, no es ejecutado hasta el siguiente COMMIT WORK.

Con PERFORM ... ON COMMIT no se pueden pasar parámetros.

Con el ROLLBACK WORK, las elementos de la tabla interna son borrados. Las subrutinas que son ejecutadas con PERFORM ... ON COMMIT pueden ellas mismas contener llamadas a módulos de funciones de actualización.

1. MODULE PAI_100.
2. . . .
3. PERFORM F1 ON COMMIT.
4. . . .
5. ENDMODULE.
6. MODULE PAI_200.
7. . . .
8. PERFORM F2 ON COMMIT.
9. . . .
10. COMMIT WORK.
11. ENDMODULE.
12. . . .
14. FORM F1.
15. CALL FUNCTION 'UPDATE_LFA1'.
16. IN UPDATE TASK
17. EXPORTING . . . .
18. . . .
19. ENDFORM.
20. FORM F2.
21. CALL FUNCTION 'UPDATE_LFB1'.
22. IN UPDATE TASK
23. EXPORTING . . . .
24. . . .
25. ENDFORM.

7. Concepto de Bloqueo de SAP.

7.1. Utilización de bloqueos

Si varios usuarios quieren tener acceso a un mismo recurso, éstos deben estar sincronizados para garantizar la consistencia de los datos.

Los bloqueos, constituyen un conveniente método para coordinar los accesos de cada usuario a los recursos. Cada usuario requiere de un bloqueo antes de tener acceso a datos críticos.

7.1.1. Bloqueo de Base de Datos.

Si un programa de diálogo contiene estatutos de actualización, el sistema de base de datos pone los bloqueos apropiados.

Al final de una transacción de base de datos, el sistema de base de datos libera todos los bloqueos puestos durante la transacción.

No obstante, el sistema R/3 realiza un commit implícito a la base de datos en cada cambio de pantalla, el bloqueo de base de datos puesto durante un paso de dialogo, solo es retenido mientras no termine este paso e inicie el siguiente.

7.1.2. Introducción al Concepto de Bloqueo de SAP.

Los bloqueos de base de datos son insuficientes si se desea que el bloqueo tenga una duración de varios cambios de pantalla.

En el contexto de bloqueo de base de datos de SAP, hay una transacción SAP la cual coloca los bloqueos en una tabla (lock table) para que los registros de la tabla sean procesados.

La transacción SAP obtiene información sobre el suceso del bloqueo para retornar un código de retorno.

Al final del proceso, los bloqueos deben ser liberados explícitamente por el programa de diálogo.

Si el usuario termina el programa de dialogo ( tecleando en la línea de comandos /n, o dentro del programa se ejecuta un estatuto LEAVE PROGRAM o LEAVE TO TRANSACTION; o si es desplegado un mensaje tipo A), los bloqueos son liberados automáticamente.

7.1.3. Objetos de Bloqueo SAP.

Para realizar un bloqueo, primeramente se define un objeto de bloqueo en diccionario de ABAP/4. Estos objetos cubren las tablas que van a ser bloqueadas.

Consiste de una tabla primaria, pero también se pueden agregar otras tablas secundarias para usar llaves foráneas dependientes.

Los argumentos del bloqueo son los campos que forman la clave de las tablas.

Por cada tabla se puede definir el modo de bloqueo: Modo E para exclusivo, modo S para compartido.

7.1.4. Modulo de Función Enqueue / Dequeue.

Cuando un objeto bloqueado ha sido activado exitosamente, el sistema genera unos módulos de función ENQUEUE y DEQUEUE.

7.1.5. Llamando Módulos de Bloqueo.

Cuando se llama un módulo de función ENQUEUE, el programa de diálogo coloca un bloqueo.

Los parámetros de exportación que se refieren al bloqueo de argumentos, identifican las entradas de la tabla o las entradas a ser bloqueadas.

Si uno de estos parámetros no contienen un valor, el sistema lo trata como una especificación genérica.

Si se desea borrar todos los bloqueos de la tabla, los cuales han sido puestos en tu programa se puede usar el módulo de función DEQUEUE_ALL.

7.1.6. Tabla de Bloqueos

Los argumentos de los bloqueos, son almacenados en la lock table para casa tabla bloqueada.

| Client | User | Time | Shared | Table |Lock argument |

| 007 | Meyer | 11:00 | | SFLIGHT | LH470 |

| 007 | Miller | 11:01 | | SFLIGHT | UA250 |

| 007 | Miller | 11:01 | | LFB1 |0074712 0815 |

| 007 | Miller | 11:01 | | LFC1 |0074712 08151994|

| 007 | Smith | 11:02 | X | YLFA | LIEF1 |

| 007 | Schultz | 11:03 | X | YLFA | LIEF1 |

| 007 | Balfour | 11:04 | | YLFB1 | 00764715 |

Para desplegar la tabla de bloqueos, elija Tools -> Administration -> Lock entries (Transacción SM12).

7.1.7. Características Especiales con ENQUEUE.

El parámetro MODE_<table> maneja el modo de bloqueo definido por el bloqueo del objeto (‘S’ = shared / compartido, ‘E’ = Exclusivo).

El parámetro _SCOPE define la duración del bloqueo y los libera cuando no se necesitan más.

_SCOPE = 1 : El Bloqueo permanece en el programa de dialogo.

_SCOPE = 2 (default) : El bloque es retenido por el programa de actualización.

_SCOPE = 3 : El programa de dialogo y actualización son dueños de los bloqueos y hay dos entradas por objeto.

El parámetro _WAIT define donde un bloqueo deberá repetirse después de un error. Se pueden especificar la duración de las repeticiones con el parámetro ENQUEUE / DELAY.

Si un argumento de bloqueo no contiene valor o tiene un espacio, se establece un bloqueo genérico. Si se desea bloquear el valor inicial, se debe marcar el parámetro

X_<lock argument>.