Tutorial de programación de diálogos: grupo de módulos en SAP ABAP

Por: sofia mitchell sofia mitchell
Hours Actualizado

⚡ Resumen inteligente

Programación de diálogos en SAP ABAP crea programas de módulos que interactúan con el usuario mediante pantallas y modifican el contenido de la base de datos. Esta página explica los códigos de transacción, las pantallas, el estado de la interfaz gráfica de usuario (GUI), la lógica de flujo de pantallas, las dynpros y la estructura de los módulos.

  • ???? Definición básica: Un programa de diálogo gestiona cualquier interacción del usuario, como introducir datos, elegir una opción de menú o hacer clic en un botón, y puede actualizar la base de datos.
  • 🅼 Tipo de programa: Los programas de diálogo son módulos de tipo M, no pueden ejecutarse de forma independiente y deben estar asociados al menos a un código de transacción con una pantalla inicial.
  • 🧩 Componentes: Un código de transacción, pantallas, un estado de la interfaz gráfica de usuario (GUI), el conjunto de módulos ABAP y la lógica de flujo, en conjunto, forman una aplicación de diálogo.
  • 🔄 Lógica de flujo: PBO se ejecuta antes de que aparezca la pantalla, PAI se ejecuta después de una acción del usuario, POH responde a F1 y POV responde a F4.
  • 🖥️ Dynpro: Una pantalla, junto con su lógica de flujo, constituye una dynpro, y cada dynpro controla exactamente un paso del diálogo.
  • 📦 Conjunto de módulos: Todas las pantallas dinámicas (dynpros) que se llaman dentro de una misma transacción hacen referencia a un grupo de módulos común que contiene los módulos de diálogo.
  • 🛠️ Ruta de creación: SE80 crea el grupo de módulos, SE51 diseña la pantalla, SE41 construye el estado de la interfaz gráfica de usuario y SE93 vincula el código de transacción.
Descubre más

SAP Programación de diálogos ABAP

¿Qué es la programación de diálogos?

SAP-ABAP admite dos tipos de programas: programa de informes y programa de diálogo.

Si su programa ABAP exige la entrada del usuario, se utiliza la programación de diálogo.

Un diálogo de usuario es cualquier forma de interacción entre el usuario y el programa y podría ser cualquiera de los siguientes:

  • Ingresando datos
  • Elegir un elemento del menú
  • Al hacer clic en un botón
  • Hacer clic o doble clic en una entrada

El programa de diálogo también se utiliza cuando necesitamos navegar hacia adelante y hacia atrás entre pantallas.

Los programas de diálogo se crean con el tipo "M" - Grupo de módulos. No se pueden ejecutar de forma independiente y deben adjuntarse al menos a un código de transacción en el que especifique una pantalla inicial.

Diferencia entre programas de informes y diálogos

Diferencia entre programas de informes y diálogos

Programa de informes:

Un informe es un programa que normalmente lee y analiza datos en tablas de bases de datos sin cambiar el base de datos de CRISPR Medicine News.

Programa de diálogo:

Un programa de diálogo le permite trabajar interactivamente con el sistema y cambiar el contenido de las tablas de la base de datos. Cada programa de diálogo tiene una secuencia determinada de imágenes que el sistema procesa una tras otra.

Criterios Programa de informes Programa de diálogo
Tipo de programa Tipo 1, ejecutable Tipo M, grupo de módulos
Acceso a la base de datos Lee y analiza datos Lee y modifica datos
Ejecución Funciona por sí solo Se ejecuta únicamente a través de un código de transacción.
Control Acontecimientos del informe Lógica de flujo de pantalla de cada dynpro

La secuencia de pantallas de una transacción de diálogo es más fácil de seguir con un ejemplo.

Un ejemplo de procesamiento de transacciones en programación de diálogos

Un procesamiento de transacciones de muestra

El diagrama muestra una transacción desde la primera pantalla hasta la actualización de la base de datos. El usuario introduce datos en la pantalla 100, PAI valida la entrada y decide la siguiente pantalla, la pantalla 200 recopila los datos restantes y, finalmente, la tarea de actualización escribe el registro. Cada uno de estos pasos se realiza mediante los componentes que se enumeran a continuación.

ARTÍCULOS RELACIONADOS

Componentes del programa de diálogo

Quitar 'Me gusta' (reporte) lo que generalmente implica la creación de un programa autónomo que puede ejecutarse independientemente de otros objetos, el desarrollo de un programa de diálogo implica el desarrollo de múltiples objetos, ninguno de los cuales puede ejecutarse por sí solo. En cambio, todos los objetos están vinculados jerárquicamente al programa principal y se ejecutan en una secuencia dictada por el programa principal de diálogo..

Los componentes de un programa de diálogo son:

Código de transacción

  • El código de transacción inicia una secuencia de pantalla.
  • Los códigos de transacción se crean en el Navegador de repositorio en ABAP Workbench o mediante Transaction SE93.
  • Un código de transacción está vinculado a un programa ABAP y una pantalla inicial.
  • Puede iniciar una secuencia de pantalla desde cualquier programa ABAP utilizando la instrucción CALL SCREEN.

Pantallas

  • Cada diálogo en un SAP El sistema está controlado por una o más pantallas.
  • Creas pantallas usando la pantalla Painter en el Workbench ABAP a través de la transacción SE51
  • Cada pantalla pertenece a una programa ABAP.
  • Estas pantallas constan de una “máscara de pantalla” o “diseño” y su lógica de flujo. La pantalla tiene un diseño que determina las posiciones de los campos de entrada/salida y otros elementos gráficos como casillas de verificación y botones de opción. Una lógica de flujo determina el procesamiento lógico dentro de la pantalla.

Estado de la interfaz gráfica de usuario

  • Cada pantalla tiene estados de GUI que son componentes independientes de un programa.
  • Esto controla las barras de menú, la barra de herramientas estándar, la barra de herramientas de la aplicación, con las que el usuario puede elegir funciones en la aplicación.
  • Los creas en ABAP Workbench usando el Menú Painter.

Programa ABAP

  • Cada pantalla y estado de GUI en el Sistema R/3 pertenece a un programa ABAP.
  • El programa ABAP contiene los módulos de diálogo que son llamados por la lógica de flujo de pantalla y también procesa la entrada del usuario desde el estado de la GUI.
  • Los programas ABAP que utilizan pantallas también se conocen como programas de diálogo.
  • En un grupo de módulos (programa tipo M); El primer bloque de procesamiento que se llama es siempre un módulo de diálogo. Sin embargo, también puede utilizar imágenes de otros programas ABAP, como programas ejecutables o módulos de funciones. El primer bloque de procesamiento se llama entonces de forma diferente; por ejemplo, por el entorno de ejecución o una llamada a procedimiento. Luego se inicia la secuencia de pantalla utilizando la instrucción CALL SCREEN.

Lógica de flujo de pantalla

La lógica de flujo de pantalla se divide principalmente en cuatro componentes.

  • Procesar antes de la salida (PBO) evento: que se procesa antes de que se muestre la pantalla
  • Proceso después de la entrada (PAI) evento: que se procesa después de una acción del usuario en la pantalla
  • Procesar en solicitud de ayuda (P.O.H.): que se procesa cuando se presiona F1
  • Procesar en solicitud de valor (Punto de vista):que se procesa cuando se presiona F4

POH y POV se explican en detalle en la página sobre proceso de solicitud de valor y proceso de solicitud de ayuda.

Dynpro

  • Una pantalla, junto con su lógica de flujo, se denomina Dynpro ("Programa dinámico" ya que la lógica de flujo de la pantalla influye en el flujo del programa).
  • Cada dynpro controla exactamente un paso de su programa de diálogo.
  • Las pantallas pertenecientes a un programa son numeradoLa secuencia de flujo de pantallas puede ser lineal o cíclica. Desde una cadena de pantallas, incluso se puede llamar a otra cadena y, tras procesarla, volver a la cadena original. También se puede modificar la siguiente pantalla definida estáticamente desde los módulos de diálogo del programa ABAP.

Grupo de módulos ABAP

  • En un evento PBO o PAI, una Dynpro llama a un programa de diálogo ABAP. El conjunto de dichos programas se denomina grupo de módulos ABAP.
  • Por ejemplo, los módulos llamados en el evento PAI se utilizan para verificar la entrada del usuario y activar los pasos de diálogo apropiados, como la tarea de actualización.
  • Todos los dynpros serán llamados desde dentro. uno La transacción se refiere a un grupo de módulos común.

Estructura de un programa de diálogo

Estructura de un programa de diálogo

El diagrama de estructura muestra cómo el código de transacción, las pantallas, el estado de la interfaz gráfica de usuario y el conjunto de módulos están vinculados al mismo programa principal.

Flujo de proceso para un programa de diálogo

Flujo de proceso para un programa de diálogo

El diagrama de flujo del proceso muestra la alternancia entre la pantalla y el programa ABAP: PBO rellena los campos de la pantalla, el usuario realiza la acción y PAI procesa la entrada antes de que se llame a la siguiente pantalla.

Cómo crear un programa de grupo de módulos

Los componentes anteriores se crean en un orden fijo. Los pasos que se describen a continuación construyen una transacción funcional a partir de un conjunto de módulos vacío.

  1. Crear el grupo de módulos: En SE80 o en SE38, cree un programa cuyo nombre comience con SAPMZ y establecer el tipo de programa en M – Conjunto de módulosEl tipo no se puede cambiar posteriormente sin eliminar el objeto.
  2. Declarar los datos globales: Coloca la instrucción TABLES y las variables globales en el archivo de inclusión TOP, que todos los módulos de diálogo del pool pueden leer.
  3. Diseña la pantalla: Crear pantalla 100 con la pantalla Painter (SE51), coloque los campos de entrada en el diseño e introduzca el siguiente número de pantalla en los atributos de pantalla.
  4. Escribe la lógica de flujo: En la pestaña Lógica de flujo, llame a un módulo para PBO y a otro para PAI, como se muestra a continuación.
  5. Generar el estado de la interfaz gráfica de usuario: Crea un estado con el menú Painter (SE41) y configúrelo en el módulo PBO con la instrucción SET PF-STATUS, de modo que Guardar, Atrás y Salir lleguen al programa como códigos de función.
  6. Vincular un código de transacción: En SE93, cree una transacción de diálogo, asigne un nombre al grupo de módulos e introduzca 100 como pantalla inicial.
* Screen 100, flow logic
PROCESS BEFORE OUTPUT.
  MODULE status_0100.

PROCESS AFTER INPUT.
  MODULE user_command_0100.

* Module pool SAPMZDEMO
MODULE status_0100 OUTPUT.
  SET PF-STATUS 'STATUS_100'.
  SET TITLEBAR 'TITLE_100'.
ENDMODULE.

MODULE user_command_0100 INPUT.
  CASE sy-ucomm.
    WHEN 'SAVE'.
      PERFORM save_data.
    WHEN 'BACK' OR 'EXIT'.
      LEAVE TO SCREEN 0.
  ENDCASE.
ENDMODULE.

💡 Consejo: LEAVE TO SCREEN 0 finaliza la pantalla actual y regresa al punto de llamada, que es la forma estándar de salir de una transacción de diálogo de manera limpia.

Preguntas Frecuentes

CALL SCREEN abre una nueva pantalla y mantiene la pantalla que la llamó en la pila, por lo que el procesamiento regresa a ella. LEAVE TO SCREEN reemplaza la pantalla actual y nada regresa a la que la llamó.

Un grupo de módulos llamado SAPMZDEMO se divide en MZDEMOTOP para datos globales, MZDEMOO01 para módulos PBO, MZDEMOI01 para módulos PAI y MZDEMOF01 para subrutinas. El entorno de desarrollo las genera automáticamente.

En el estado de la interfaz gráfica, asigne al botón la función de tipo E y llame a su módulo con MODULE exit AT EXIT-COMMAND. El módulo se ejecuta antes de la validación de campos, lo que permite al usuario salir de la pantalla con datos no válidos.

Sí. Los asistentes de IA dentro de las herramientas de desarrollo ABAP elaboran los módulos PBO y PAI, la instrucción CASE en SY-UCOMM y las validaciones de campo a partir de una descripción de la pantalla. El diseño en sí todavía se dibuja en la pantalla. Painter.

Dynpros sigue funcionando en todos los sistemas clásicos. SAP Transacción de interfaz gráfica de usuario (GUI). Las nuevas interfaces de usuario suelen crearse con Fiori, y las herramientas de IA ayudan leyendo la lógica de flujo existente y proponiendo un diseño de servicio y aplicación equivalente.

Resumir este post con: