14.1. INTRODUCCIÓN:

• Un diálogo no es más que una pantalla (dynpro) más un programa Abap/4 subyacente que actúa según las elecciones del usuario (meter datos, elegir comandos, ...) sobre la pantalla presentada. Una transacción llama al proceso de programa asociado. Por tanto, en programación de diálogo se usan diversos objetos: transacciones, dynpros y programas Abap/4 tipo M (module pool).
  
• Para crear una transacción: por menú ir a Desarrollo – Más Herramientas – Transacciones, o directamente > SE93 Y pulsar el icono de crear (una hoja en blanco). Su nombre debe empezar por Z y son 4 caracteres. Indicar “transacción de diálogo”). Luego, en “programa”, indicar el nombre del module pool a ejecutar cuando se invoque a la transacción, así como el número de la primera dynpro a visualizar. Para cada dynpro a mostrar hay que especificarla cuál va a ser la siguiente, si existe. Si no, se debe poner 0 como dynpro siguiente.
  
• Las dynpro’s se crean y editan con el Screen Painter. Pueden tener botones, menús, iconos, marcos, flags, ... (eso es el “screen layout”: la disposición visual de los campos en la pantalla). Se crean y agrupan como se desee con el botón Elemento Gráfico. Yendo a Status (una vez dentro del Screen Painter) pueden verse todas las características del programa module pool. Con el botón Atributos se pueden ver los atributos del campo seleccionado. En los textos (labels) de una dynpro hay que escribir los blancos como subrayados para que se tome el texto como único. Una vez creada una pantalla o dynpro, debe activarse tras grabarla (como todo objeto SAP).
  
• Por detrás de la dynpro habrá eventos que se activarán si los usuarios los eligen. Hay 2 eventos que siempre existen: PBO (Process Before Output: Procesos que se ejecutan siempre antes de que se muestre la dynpro por pantalla) y PAI (Process After Input: Procesos que se ejecutan una vez que el usuario ha elegido la acción a realizar). En un diálogo, una variable o campo que cambie el usuario, queda cambiada en el programa, y viceversa.
  
• Un module pool es un programa Abap/4 tipo M. Los estándar de SAP se llaman SAPMXXXX, siendo XXXX la transacción asociada. Estos programas sólo contienen sentencias INCLUDE, como ocurre con los grupos de funciones. Al menos existirán estos 3 includes: un ‘TOP’ para las variables globales, tablas, ... un ‘O’ para los procesos PBO, y un ‘I’ para los procesos PAI. En el include ‘TOP’ hay que declarar siempre la sentencia: DATA OK_CODE(4), que se usa para recoger el código del comando seleccionado por el usuario. Los otros 2 includes obligatorios son, salvo por las sentencias MODULE y ENDMODULE, programas includes normales.
  
• Al llamar a una transacción, se ejecutan todos los módulos que hay en el PBO (se añade OUTPUT a la sentencia MODULE), en el orden en que estén escritos. A continuación se muestra la pantalla dynpro al usuario. Cuando éste elige un comando, se ejecutan los procesos PAI correspondiente y sus módulos asociados (puede pasarse a una nueva dynpro). En este include conviene codificar siempre un módulo para poder abandonar la ejecución del diálogo cuando se desee. Debería ser el primer proceso de los PAI. Pueden usarse los mismos includes PAI y PBO para todas las pantallas en las que se haga lo mismo (así, se comparten).
  
  

14.2. SENTENCIAS DE LÓGICA DE PROCESO DE DYNPROS:

• Para poder procesar un module AT USER-COMMAND, ir por menú a Pasar a – Lista de funciones – tipo E. Generar y activar. En Menu Painter – Lista campos renombrar como OK_CODE al campo llamado OK, para que quede ya esta variable declarada, directamente. Para el resto de campos, si se declaran LIKE campos del Diccionario de Datos no será necesario codificar nada, pues todo se ‘importa’ de éste.
  
• Hay que usar un status (‘para dynpros’, no ‘para listas’) para poder tener activos en la pantalla los iconos por defecto. En el editor de procesos dynpro sólo puede haber ciertas sentencias, como declaraciones de módulos; no es un editor Abap/4 completo. Sólo se pueden usar éstas:

• Sentencias PROCESS (4 tipos. Pueden existir ya procesos por defecto):
  • PROCESS BEFORE OUTPUT. EventoP.B.O.
  • PROCESS AFTER INPUT. EventoP.A.I.
  • PROCESS ON HELP-REQUEST. Sólo se ejecuta cuando el usuario pulsa ayuda (F1).
  • PROCESS ON VALUE-REQUEST. Se ejecuta al pulsarse el botón matchcode de valores posibles (F4).
  
  
• Sentencia FIELD:

FIELD campo[ VALUES ( lista_valores ) ] [ MODULE nombre_módulo] [ ON INPUT ][ ON REQUEST ].

Chequea que el valor del campo (de una dynpro) sea uno de los especificados en VALUES (van separados por comas. Los paréntesis son obligatorios). Con el parámetro MODULE se pueden enviar mensajes de error al usuario, y se procesa el módulo especificado.
Ejemplo:

FIELD sbook-carrid VALUES ('AA', 'LH', 'VS').

• Bloque de proceso:

CHAIN. … ENDCHAIN.

Puede usarse en combinación con los parámetros ON CHAIN-INPUT y ON CHAIN-REQUEST de la sentencia MODULE.
Ejemplo:

CHAIN. FIELD campo1. FIELD campo2. MODULE modulo1. MODULE modulo2. ENDCHAIN.

• Llamadas condicionales a un módulo:
  
  MODULE nombre_módulo[ AT EXIT-COMMAND ] [ ON INPUT ] [ ON * INPUT ][ ON REQUEST ] [ ON CHAIN-INPUT ] [ ON CHAIN-REQUEST ][ AT CURSOR-SELECTION ] [ INPUT ] [ OUTPUT ].

Un módulo se compone de las sentencias declarativas de un proceso.
Parámetros:

• AT EXIT-COMMAND: Necesita código tipo E.
  
• FIELD … MODULE … ON INPUT: Se ejecuta sólo cuando el usuario introduzca un valor. Con ello en un PAI se evitan ejecuciones innecesarias del módulo especificado.
  
• FIELD … MODULE … ON * INPUT: Se lanza cuando el usuario escribe un asterisco.
  
• FIELD … MODULE … ON REQUEST: Se ejecuta si el usuario pulsa el botón de valores posibles (matchcode) en el campo especificado en FIELD.
  
• OUTPUT: Indica que ése es el módulo que se lanza en el PBO.
  
• INPUT: Indica que ése es el módulo que se lanza en el PAI. No confundir con ON INPUT.

Ejemplo: Se ejecutará el módulo ‘nombre1’ sólo cuando cambia el valor de ‘a’, ‘b’ o ‘c’; mientras que el módulo ‘nombre2’ se ejecuta siempre.

CHAIN. FIELD: a,b,c MODULE nombre1 ON CHAIN-INPUT. MODULE nombre2. ENDCHAIN.

• Sentencias útiles de module pool (no son para procesos dynpros):
  
  • SET SCREEN n. Va a la pantalla número n.
    
  • LEAVE SCREEN. Abandona la pantalla y los procesos asociados.
    
  • LOOP AT SCREEN. … ENDLOOP. Bucle que recorre todos los elementos definidos en la pantalla, los cuales se almacenan en la tabla del sistema llamada SCREEN. Algunos de sus campos son: screen-name (usando un CHECK screen-name = ‘nombre’ se elige el campo a procesar), screen-input (si vale 1, el campo es de e/s; si vale cero, es de sólo entrada), screen-output (indica campo de sólo salida), screen-group1 (elige el grupo especificado de campos).
    
  • MODIFY SCREEN [ parámetros ]. Dentro de un LOOP AT SCREEN, modifica ciertas características de los campos de pantalla, como por ejemplo ocultarlos, hacerlos obligatorios, de sólo entrada, … (según los parámetros elegidos). Codificar esta sentencia en el PBO, para que tenga efecto antes de mostrar la pantalla.
    Ejemplo:

    LOOP AT SCREEN. " recorre todos los campos de la pantalla CHECK screen-name = 'campo1'. " elige este campo screen-input = 0. " El campo1 pasa a ser sólo de entrada MODIFY SCREEN. " modifica el campo ENDLOOP.