✒️ABAP La lógica de procesamiento en el PAI y la ejecución de las acciones
ABAP La lógica de procesamiento en el PAI y la ejecución de las acciones
2.6. - Lógica de procesamiento en PAI: Ejecución de las acciones
2.6.1. - Ejecución condicionada de módulos
Si se especifica la cláusula “ON INPUT” después de MODULE, en una instrucción FIELD, el módulo es ejecutado solamente si el campo en cuestión contiene un valor diferente al inicial.
En la sentencia “CHAIN-ENDCHAIN” se debe usar la instrucción “ON CHAIN-INPUT”. En este caso, el módulo es procesado solamente si al menos uno de los campos de la pantalla en la sentencia “CHAIN-ENDCHAIN” contiene un valor diferente al valor inicial. Se puede usar la adición “ON INPUT” solamente si la instrucción MODULE es especificada dentro de una instrucción FIELD.
Si se especifica la cláusula “ON REQUEST” después de MODULE en una instrucción “FIELD”, el modulo es ejecutado únicamente si el campo tiene una nueva entrada.
En la sentencia “CHAIN-ENDCHAIN”, se debe usar la instrucción “ON CHAIN-REQUEST”. El módulo concerniente es procesado solamente si al menos uno de los campos de pantalla de la sentencia “CHAIN-ENDCHAIN” tiene una nueva entrada.
Se puede usar la adición “ON REQUEST” solamente si la instrucción MODULE es especificada dentro de una instrucción FIELD.
Es posible que los usuarios quieran salir de la pantalla sin necesidad de pasar por las validaciones automáticas, utilizando salir, cancelar. En este caso, hay que utilizarla clausula “AT EXIT-COMMAND” de la instrucción MODULE.
Para poder utilizar el comando “AT EXIT-COMMAND”, en un botón de campo, será necesario asignar el valor “E” en el atributo de campo tipo de función del editor de pantallas.
En el módulo de la llamada, se incluirán las instrucciones necesarias para poder salir de la transacción o de la pantalla en proceso, por ejemplo “LEAVE TO SCREEN 0”.
2.6.2. - Tratamiento de los códigos de función
Cuando el usuario de una transacción de diálogo pulsa una tecla de función, un punto de menú, un pushbutton, un icono o simplemente la tecla enter, los datos introducidos en la pantalla se pasan a los módulos definidos en el PAI para ser procesados junto a un código de función que indicará qué función ha solicitado el usuario.
Hay que recordar, que cuando se define una dynpro, se crea el campo de tipo código de función denominado “OK_CODE”. En la lógica de procesamiento de cada dynpro, habrá que realizar el tratamiento del OK_CODE. Para ello, se utilizará el modulo “USER_COMMAND”, que deberá ser el último del evento PAI, es decir, que se ejecutará una vez que todos los datos de entrada han sido validados correctamente.
Una vez procesado el módulo de función, se borrará el contenido del OK_CODE, iniciándolo para la próxima dynpro. Se puede guardar el contenido del OK_CODE en una variable intermedia e iniciarlo inmediatamente. El tipo de variable V_UCOMM es del tipo SY-UCOMM.
Diferencia entre OK_CODE y SY-UCOMM
SY-UCOMM es una variable del sistema, que se utiliza principalmente en los menús y que contiene la última acción ejecutada por el usuario.
OK_CODE es una variable que se declara en los programas ABAP, del tipo SY-UCOMM y que se utiliza principalmente en las pantallas. Actúa como una variable temporal, que almacena el valor del SY-UCOMM.
Se debe trabajar con OK_CODE, existen dos razones:
1. El programa tiene el control total sobre los campos declarados.
2. Nunca se debe cambiar el valor de una variable de sistema.
Siempre se debe inicializar la variable OK_CODE debido a que:
1. OK_CODE y SY-UCOMM reciben el contenido de los datos de la pantalla en el PAI
2. El contenido de OK_CODE y SY-UCOMM se asigna en el PBO.
3. Se debe limpiar OK_CODE para que el código de función de una pantalla no esté lleno con un valor no deseado en el PBO.
a. Esto es importante cuando el código del PAI se pueda activar con un código de función vacío (Enter).
2.6.3. - Secuencia dinámica de las pantallas
En un programa de diálogo o también llamado transacción de diálogo, se puede controlar la secuencia de ejecución de cada una de las dynpros que componen a la transacción.
Existen dos instrucciones que permitirán pasar a otra dynpro existente dentro del mismo programa. La primera es la instrucción “SET SCREEN” %uF0E0 SET SCREEN <nro_pantalla>.
La instrucción SET SCREEN reescribe temporalmente la siguiente pantalla a procesar. La pantalla siguiente debe ser una pantalla del mismo MODULE POOL.
La pantalla siguiente es procesada después de procesar la pantalla actual, a menos que se termine la ejecución de la pantalla actual con la instrucción “LEAVE SCREEN”. Al encontrar esta instrucción, se ejecuta la pantalla siguiente de forma inmediata.
Si se desea terminar el procesamiento de la pantalla actual e ir directamente a la pantalla siguiente en una sola instrucción, se puede usar la sentencia “LEAVE TO SCREEN” %uF0E0 “LEAVE TO SCREEN <nro_pantalla>”.
La instrucción “CALL SCREEN” interrumpe el procesamiento de la pantalla actual para procesar la pantalla X y las pantallas subsecuentes.
La pantalla llamada con esta instrucción deberá ser una pantalla del mismo MODULE POOL. Cualquiera de las instrucciones “SET SCREEN 0”, “LEAVE SCREEN”, “LEAVE TO SCREEN 0”, regresa el control al lugar donde fue ejecutada la instrucción CALL SCREEN.
Si se usa cualquiera de las instrucciones anteriores cuando no se está en el modo de llamada, es decir, cuando no se cedió el control a otra dynpro del programa, el programa terminará.
Usando las clausulas “STARTING AT” y “ENDING AT” en la instrucción “CALL SCREEN”, se puede especificar la posición y el tamaño de la pantalla a llamar.
Si la pantalla aparece incompleta, se incluye en la misma una barra de desplazamiento
Sobre el autor
Publicación académica de Adrian Fernandez Marcos, en su ámbito de estudios para la Carrera Consultor ABAP.
SAP Master
Adrian Fernandez Marcos
Profesión: Técnico de Sistemas - España - Legajo: FQ91J
✒️Autor de: 116 Publicaciones Académicas
🎓Cursando Actualmente: Consultor ABAP Nivel Avanzado
🎓Egresado de los módulos:
Certificación Académica de Adrian Fernandez
