Dialog Programming Tutorial: Module Pool in SAP ABAP

What is Dialog Programming?

SAP-ABAP supports two types of programs – Report Program and Dialog Program.

If your ABAP program demands user input , Dialog programming is used.

A user dialog is any form of interaction between the user and the program and could be any of the following

• Entering data
• Choosing a menu item
• Clicking a button
• Clicking or double clicking an entry

Dialog program is also used when we need to navigate back and forth between screens

Dialog programs are created with type as ‘M’ – Module Pool. They cannot be executed independently and must be attached to at least one transaction code in which you specify an initial screen.

Difference between Report and Dialog Programs

Report Program:

A report is a program that typically reads and analyzes data in database tables without changing the database.

Dialog Program:

A dialog program allows you to work interactively with the system and to change the contents of the database tables. Each dialog program has a certain sequence of screens that are processed by the system one after the other.

The screen sequence of a dialog transaction is easier to follow with an example.

A Sample transaction processing in Dialog Programming

The diagram follows one transaction from the first screen to the database update. The user enters data on screen 100, PAI validates the entry and decides the next screen, screen 200 collects the remaining data, and the update task finally writes the record. Each of those steps is produced by the components listed below.

Components of Dialog Program

Unlike report which generally entails the creation of one autonomous program which can be executed independently of other objects, dialog program development entails development of multiple objects none of which can be executed on it’s own. Instead all objects are linked hierarchically to the main program and and are executed in a sequence dictated by the Dialog Main Program.

The components of a dialog program are:

Transaction code

• The transaction code starts a screen sequence.
• You create transaction codes in the Repository Browser in the ABAP Workbench or using Transaction SE93.
• A transaction code is linked to an ABAP program and an initial screen.
• You can start a screen sequence from any ABAP program using the CALL SCREEN statement.

Screens

• Each dialog in an SAP system is controlled by one or more screens.
• You create screens using the Screen Painter in the ABAP Workbench through transaction SE51
• Each screen belongs to an ABAP program.
• These screens consist of a “screen mask” or “layout” and its flow logic. The screen has a layout that determines the positions of input/output fields and other graphical elements such as checkboxes and radio buttons. A flow logic determines the logical processing within screen.

GUI status

• Each screen has a GUI status(es) which are independent components of a program.
• This controls the menu bars, standard toolbar, application toolbar , with which the user can choose functions in the application.
• You create them in the ABAP Workbench using the Menu Painter.

ABAP Program

• Each screen and GUI status in the R/3 System belongs to one ABAP program.
• The ABAP program contains the dialog modules that are called by the screen flow logic, and also process the user input from the GUI status.
• ABAP programs that use screens are also known as dialog programs.
• In a module pool (type M program); the first processing block to be called is always a dialog module. However, you can also use screens in other ABAP programs, such as executable programs or function modules. The first processing block is then called differently; for example, by the runtime environment or a procedure call. The screen sequence is then started using the CALL SCREEN statement.

Screen Flow Logic

Screen Flow logic is primarily divided into four components.

• Process Before Output (PBO) event: which is processed before the screen is displayed
• Process After Input (PAI) event: which is processed after a user action on the screen
• Process on help request (POH): which is processed when F1 is pressed
• Process on value request (POV):which is processed when F4 is pressed

POH and POV are explained in detail on the page about process on value request and process on help request.

Dynpro

• A screen together with its Flow logic is called a Dynpro (“Dynamic Program” since the screen flow logic influences the program flow)
• Each dynpro controls exactly one step of your Dialog Program.
• The screens belonging to a program are numbered. The screen flow sequence can be either linear or cyclic. From within a screen chain, you can even call another screen chain and, after processing it, return to the original chain. You can also override the statically-defined next screen from within the dialog modules of the ABAP program.

ABAP Module Pool

• On a PBO or PAI event a Dynpro calls an ABAP dialog program. Collection of such programs is called the ABAP module pool.
• For example modules called at the PAI event are used to check the user input and to trigger appropriate dialog steps, such as the update task.
• All dynpros to be called from within one transaction refer to a common module pool.

Structure of a Dialog Program

The structure diagram shows how the transaction code, the screens, the GUI status, and the module pool are linked to the same main program.

Process Flow for a Dialog Program

The process flow diagram shows the alternation between the screen and the ABAP program: PBO fills the screen fields, the user acts, and PAI processes the input before the next screen is called.

How to Create a Module Pool Program

The components above are created in a fixed order. The steps below build a working transaction from an empty module pool.

1. Create the module pool: In SE80, or in SE38, create a program whose name begins with SAPMZ and set the program type to M – Module pool. The type cannot be changed later without deleting the object.
2. Declare the global data: Put the TABLES statement and the global variables in the TOP include, which every dialog module of the pool can read.
3. Design the screen: Create screen 100 with the Screen Painter (SE51), place the input fields on the layout, and enter the next screen number in the screen attributes.
4. Write the flow logic: On the Flow logic tab, call one module for PBO and one for PAI, as shown below.
5. Build the GUI status: Create a status with the Menu Painter (SE41) and set it in the PBO module with the SET PF-STATUS statement, so that Save, Back, and Exit reach the program as function codes.
6. Link a transaction code: In SE93 create a dialog transaction, name the module pool, and enter 100 as the initial screen.

* 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.

💡 Tip: LEAVE TO SCREEN 0 ends the current screen and returns to the calling point, which is the standard way to leave a dialog transaction cleanly.

FAQs