Entering content frameSample Transaction Locate the document in its SAP Library structure

To illustrate the concept of dialog-controlled execution and the use of transactions, the simple sample transaction DEMO_TRANSACTION in package SABAPDOCU is shown below.


The sample transaction consists of a single dialog screen. The user can enter the ID of an airline company and a flight number to request flight information:

This graphic is explained in the accompanying text

If the user chooses Display, the system retrieves the requested data from the database and displays it:

This graphic is explained in the accompanying text


The structure of the sample transaction is described below.

You can find all of its components in the Repository Browser under program name SAPMDEMO_TRANSACTION. You can also choose System ® Status from within the transaction, and then double-click one of the listed components to switch to the appropriate tool in the ABAP Workbench.


Each screen contains fields used to display or request information. Fields can be text strings, input or output fields, radio buttons, checkboxes, or pushbuttons. The screen of Transaction DEMO_TRANSACTION contains only texts and input/output fields.

A screen consists of several components:

This graphic is explained in the accompanying text

You create all of the components of a screen using the Structure link Screen Painter. To start the Screen Painter, create a screen in the Repository Browser or double-click an existing one. The Repository Browser calls the Screen Painter, in which you can enter the flow logic of the screen you want to create or change. The flow logic editor also contains pushbuttons that you can use to switch to the layout editor, the field list, or the screen attributes screen.

Screen Attributes

From the user's point of view, a transaction is a sequence of screens, displayed one after another. How do I determine this sequence? The transactions's attributes determine the first screen to be displayed. The attributes of the individual screens determine which screen is displayed after the current screen. You can also set the number of the subsequent screen dynamically from within the ABAP program.

For our example, the screen attributes need not be changed, since no subsequent screen is called.


To start the layout editor in the Screen Painter, choose Fullscreen. Here you can determine the layout of the screen. For Transaction DEMO_TRANSACTION, the desired fields can be copied from table SPFLI of the ABAP Dictionary. For further information, refer to the Structure link Screen Painter documentation.

Field Attributes

In the element list, you can display or change the attributes of each field on the screen. (Input/output fields, required fields, whether the possible entries button is displayed, whether the field is invisible, and so on.)
The fields Airline (SPFLI-CARRID) and Flight number (SPFLI-CONNID) are defined as input/output fields. All other fields are used only for outputting the flight data.

Flow logic

The flow logic code of a dialog screen consists of a few statements that syntactically resemble ABAP statements. You cannot use flow logic keywords in ABAP programs, or ABAP statements in screen flow logic. You enter the flow control code in the Screen Painter as one component of the screen.

The flow control for the screen in Transaction DEMO_TRANSACTION looks like this:

  MODULE set_status_0100.
  MODULE user_command_0100.

The PROCESS statement introduces the flow logic for the two events PBO and PAI. The MODULE statements each call one dialog module in the associated ABAP program. In this example, there is only one MODULE for each event PBO and PAI. However, the flow logic can, of course, contain more statements, calling more than one dialog module in each event. You can also call the same dialog module from more than one screen.

The flow logic syntax contains only a few statements. The most important are MODULE, FIELD, CHAIN, LOOP, and CALL SUBSCREEN. For information about flow logic syntax, choose Utilities Help on... from the flow logic editor. A dialog box appears, in which you select Flow logic keyword and then enter the keyword for which you want more information.

ABAP Program

In our example, the ABAP program has type M, that is, it is a module pool. When you create a type M program in the Repository Browser, the ABAP Workbench automatically organizes the program code into a series of include programs. If your ABAP program observes the naming convention SAPM<name>, the hierarchy tree in the Repository Browser allows you to create the following include programs:

Include programs can contain several processing blocks. These normally all have the same type (for example, only PBO modules or only PAI modules). However, you could create a separate include program for each processing block, or combine various types of processing block in a single include program.

If you follow the working method suggested by the ABAP Workbench, the source code of your main program is empty apart from a series of INCLUDE statements that incorporate the individual includes into your program:

*& Module pool        SAPMDEMO_TRANSACTION                      *
*&                                                               *
*&                                                               *
*&     Display data of table SPFLI                               *
*&                                                               *

* Global data
INCLUDE mdemo_transactiontop.

* PAI-Module
INCLUDE mdemo_transactioni01.

* PBO-Module
INCLUDE mdemo_transactiono01.

In this sample program the include programs look like this:

*& Module pool        SAPMDEMO_TRANSACTION                       *
*&            FUNCTION: Display data of table SPFLI              *
*&                                                               *
*   INCLUDE MDEMO_TRANSACTIONTOP (This is the TOP include:        *
*           The TOP module contains global data declarations)    *
PROGRAM  sapmdemo_transaction.
  TABLES: spfli.

  DATA ok_code(4).

*   INCLUDE MDEMO_TRANSACTIONO01  (This is a PBO include.)       *
*&      Module STATUS_0100
*    Define GUI status and title for screen 100                  *
MODULE status_0100.
TZ0100 .
100 .

*   INCLUDE MDEMO_TRANSACTIONI01  (This is a PAI include.)       *
*&      Module   USER_COMMAND_0100  INPUT
*       Get data from SPFLI or leave transaction                 *
  CASE ok_code.
  CLEAR ok_code.
      SELECT SINGLE * FROM spfli WHERE carrid = spfli-carrid
                                  AND  connid = spfli-connid.
    WHEN space.
  CLEAR ok_code.

A table work area for database table SPFLI is created in include program MDEMO_TRANSACTIONTOP with the TABLES statement. The table work area serves as an interface for passing data between the screen and the ABAP program, since the input/output fields on the screen were created with the same ABAP Dictionary reference. The OK_CODE field is used to receive function codes from the identically-named screen field.

The PBO module for screen 100 sets dialog status STATUS_0100 and GUI title 100 in the include program MDEMO_TRANSACTIONO1. This GUI status and this GUI title remain valid for all subsequent screens until a new dialog status or GUI title is set. It is important that you set a dialog status, since the system otherwise uses an empty status that does not allow the user to leave the program.

In the include program MDEMO_TRANSACTIONI01, the PAI module USER_COMMAND_0100 checks which pushbutton the user chose (CASE OK_CODE.). The Display pushbutton has the function code ‘SHOW’. If the user chooses this function, the program reads the entries from database table SPFLI that correspond to the details entered by the user. In the WHERE condition of the SELECT statement, the system compares the fields SPFLI-CARRID and SPFLI-CONNID (filled in on the screen by the user) with the key fields CARRID and CONNID of database table SPFLI.

Before the screen is next displayed, the data from the table work area is passed to the corresponding screen fields, and therefore appears on the screen.

GUI Status and GUI Title

The GUI status and GUI title are interface elements of screens. You create both of them using the Structure link Menu Painter in the ABAP Workbench. A GUI status of type dialog status is used in screens.

This graphic is explained in the accompanying text

A dialog status is a collection of interactive interface elements for a screen. To apply such a set of elements to a screen, you use the ABAP statement SET PF-STATUS to link the dialog status to the screen. The dialog status for a screen of a transaction normally contains all the possible elements, that is the menu bar, standard toolbar, application toolbar and key assignments. Each of these functions send a function code to the PAI modules of the current screen when the user chooses them by choosing a menu entry, pushbutton, or function key. There are also special GUI statuses called the status for the dialog box and context menus. These contain fewer elements for this special purpose. A status for a dialog box does not have a menu bar or a standard toolbar. A context menu is a single context-specific menu that can be activated with the right mouse key ( SHIFT F10 ).

The GUI title is the screen title displayed in the title bar of the window. The GUI title is not combined in a GUI status with the other interface elements. Each GUI title must be set separately with the SET TITLEBAR statement.

Interaction between Screens and ABAP Programs

In its most simple form, a transaction is a collection of screens and ABAP routines, controlled and executed by the runtime environment. The runtime environment processes the screens in sequence, and calls the corresponding ABAP processing modules.

The runtime environment comprises the screen processor and ABAP processor (see Work Processes). For each screen, the screen processor executes the flow logic, from which the corresponding ABAP processing is called. The control alternates between the screen processor and ABAP processor, and the flow of the application program changes accordingly between screen flow logic and ABAP processing logic. In the same way that we talk about events in ABAP programs, we can also distinguish two events in screen processing - PBO and PAI. The runtime environment (screen processor in this case), triggers the events (for example, PAI after a user action on the screen).

The sequence of events for Transaction DEMO_TRANSACTION, for example, looks like this:

This graphic is explained in the accompanying text

  1. In the screen event PBO, the statement MODULE STATUS_0100 calls the corresponding dialog module and passes control to the ABAP processor.
  2. After processing the module STATUS_0100, control returns to the flow logic. The screen processor displays the screen.
  3. The PAI event is triggered by a user action on the screen. The statement MODULE USER_COMMAND_0100 calls the corresponding dialog module and passes control to the ABAP processor.
  4. After processing the module STATUS_0100, control returns to the screen processor. Since the screen has the static next screen 100 (defined in the screen attributes), the program flow begins again at step 1.

Each time control passes between the two processors, the system transfers data between identically-named fields in the program and screen. When control passes from the flow logic to the processing logic, the global ABAP variables are filled with the contents of any identically-named screen fields. Data is transferred in the opposite direction when control passes from the processing logic back to the flow logic. Each screen has a field with type OK that contains the function code of the action that the user chose. To read this value in your ABAP programs, you need a global field with the same name in your ABAP program.



Leaving content frame