1. Concepto del Evento PAI
El PAI es el evento que se desencadena inmediatamente después de que el usuario interactúa con la pantalla (dynpro) y realiza una acción, como presionar la tecla ENTER o hacer clic en un botón. Su objetivo primordial es validar los datos ingresados y determinar la acción a seguir en el flujo del programa, ya sea emitir un mensaje de error o navegar hacia otra dynpro,.
Técnicamente, los módulos de este evento se declaran en la lógica de flujo de la dynpro bajo la sección PROCESS AFTER INPUT. Estos módulos se identifican en el código ABAP por llevar la palabra reservada INPUT al final de su nombre (ej. MODULE user_command_0100 INPUT).
2. Validaciones de Datos: Automáticas y Manuales
En el PAI, el sistema distingue entre dos tipos de verificaciones para asegurar que la información sea correcta antes de ser procesada por la lógica de negocio:
A. Validaciones Automáticas
El sistema las realiza por defecto antes de procesar cualquier módulo del evento PAI:
• Verificación de formato: Valida las entradas según los atributos del campo (ej. detectar una fecha inválida o letras en campos numéricos),.
• Campos obligatorios: Si un campo tiene el atributo "required" en el Screen Painter, el sistema detiene el proceso con un mensaje en la barra de status hasta que se ingrese un valor,.
• Ámbito de valores (Dominios): Si el campo referencia a un dominio con valores fijos o tabla de valores en el Diccionario de Datos, el sistema verifica automáticamente que la entrada coincida con dicho ámbito,,.
B. Validaciones Manuales (Sentencia FIELD)
Para chequeos más complejos (como validar la existencia de un registro en una tabla Z), utilizamos la sentencia FIELD,:
• Sentencia FIELD individual: Al usar FIELD campo MODULE modulo, si el módulo emite un mensaje de error, la pantalla se redispone bloqueando todos los campos excepto aquel que causó el error,.
• Sentencia CHAIN-ENDCHAIN: Se utiliza para agrupar varios campos. Si ocurre un error en la validación dentro de la cadena, todos los campos incluidos en el CHAIN quedan habilitados para que el usuario pueda corregirlos, manteniendo bloqueados los que están fuera de la sentencia,.
3. Ejecución Condicionada de Módulos
Es posible controlar cuándo debe ejecutarse un módulo de validación para optimizar la performance mediante cláusulas específicas en el PAI:
• ON INPUT: El módulo se ejecuta solo si el campo contiene un valor distinto al inicial (no está vacío),.
• ON REQUEST: El módulo se dispara únicamente si el usuario ha modificado el valor del campo manualmente,.
4. Tratamiento del Código de Función (OK_CODE)
El tratamiento de las acciones del usuario (botones, menús) se realiza generalmente en el último módulo del PAI, denominado comúnmente USER_COMMAND.
• Se captura el código de función en una variable de tipo sy-ucomm (tradicionalmente llamada OK_CODE),.
• Mejor práctica: Una vez procesado el código de función, es fundamental borrar o inicializar el contenido del OK_CODE para que no afecte a la ejecución de la siguiente dynpro.
5. Salto de Validaciones (AT EXIT-COMMAND)
Si el usuario desea salir de la pantalla (botones BACK, EXIT o CANCEL) sin pasar por las validaciones de campos obligatorios o formatos, se utiliza la cláusula AT EXIT-COMMAND en un módulo de PAI. Para que esto funcione, el botón en el Status GUI debe tener asignado el tipo de función "E" (Exit Command) en el Screen Painter,.
6. Secuencia Dinámica de Pantallas
Dentro del procesamiento del PAI, podemos controlar hacia dónde se dirige el usuario mediante sentencias de control de flujo:
• SET SCREEN <nro>: Define la pantalla que se ejecutará a continuación al finalizar el procesamiento de la actual.
• CALL SCREEN <nro>: Interrumpe la dynpro actual para procesar una nueva pantalla. Al finalizar la pantalla llamada (mediante SET SCREEN 0), el control regresa al punto exacto donde se hizo la llamada,,.
• LEAVE TO SCREEN <nro>: Finaliza el procesamiento de la dynpro actual y salta inmediatamente a la siguiente.