Sample Transaction 

Kontextmenü

This example illustrates the concept behind dialog-driven transactions.

Features

Transaction TZ10 (development class SDWA) is delivered with the system. This 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:

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

Structure

The structure of transaction TZ10 is described below.

All of its components belong to the program SAPMTZ10. You can display them in the Repository Browser. 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.

Screen

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 TZ10 contains only texts and input/output fields.

A screen consists of several components:

You create all of the components of a screen using the 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 is the sequence determined? 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.

Layout

To start the layout editor in the Screen Painter, choose Fullscreen. Here you can determine the layout of the screen. For Transaction TZ10, the desired fields can be copied from table SPFLI of the ABAP Dictionary. For further information, refer to the 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 to display the flight data only.

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. The flow logic is a component of the screen. You enter it in the flow logic editor of the Screen Painter.

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

PROCESS BEFORE OUTPUT.
  MODULE SET_STATUS_0100.
*
PROCESS AFTER INPUT
  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        SAPMTZ10                                     *
*&                                                               *
*&---------------------------------------------------------------*
*&                                                               *
*&     Display data from table SPFLI                          *
*&                                                               *
*&---------------------------------------------------------------*

* Global data

INCLUDE MTZ10TOP.

* PAI Modules
INCLUDE MTZ10I01.

* PBO Modules
INCLUDE MTZ10O01.

In the example program, the include programs look like this:

*&---------------------------------------------------------------*
*& Module pool SAPMTZ10 *
*& FUNCTION: Display data from Table SPFLI *
*& *
*&---------------------------------------------------------------*
*----------------------------------------------------------------*
* INCLUDE MTZ10TOP (This is the TOP include:                  *
* the TOP module contains global data declarations) *
*----------------------------------------------------------------*
PROGRAM SAPMTZ10.
  TABLES: SPFLI.

  DATA OK_CODE(4).

*----------------------------------------------------------------*
* INCLUDE MTZ10O01 (This is a PBO include.)                *
*----------------------------------------------------------------*
*&---------------------------------------------------------------*
*& Module STATUS_0100
*&---------------------------------------------------------------*
* Specify GUI status and title for screen 100 *
*----------------------------------------------------------------*
MODULE STATUS_0100.
SET PF-STATUS ‘TZ0100’.
  SET TITLEBAR ‘100’.
ENDMODULE.

*----------------------------------------------------------------*
* INCLUDE MTZ10I01 (This is a PAI include.)                *
*----------------------------------------------------------------*
*&---------------------------------------------------------------*
*& Module USER_COMMAND_0100 INPUT
*&---------------------------------------------------------------*
* Retrieve data from SPFLI or leave transaction *
*----------------------------------------------------------------*
MODULE USER_COMMAND_0100 INPUT.
  CASE OK_CODE.
    WHEN 'SHOW'.
      CLEAR OK_CODE.
      SELECT SINGLE * FROM SPFLI WHERE CARRID = SPFLI-CARRID
AND CONNID = SPFLI-CONNID.
    WHEN SPACE.
    WHEN OTHERS.
      CLEAR OK_CODE.
      SET SCREEN 0
LEAVE SCREEN.
ENDCASE.
ENDMODULE.

In the include program MTZ10TOP, the TABLES statement creates a table work area for the database table SPFLI. 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.

In the include program MTZ10O1, the PBO module for screen 100 sets the GUI status STATUS_0100 and the title 100. This GUI status and title apply to all subsequent screens until you set new ones. It is important that you set a GUI status, since the system otherwise uses an empty status that does not allow the user to leave the program.

In the include program MTZ10I01, 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 Menu Painter in the ABAP Workbench.

A GUI 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 GUI status to the screen. Typically, the GUI status for a screen of a transaction contains all possible functions. 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.

The GUI title is the screen title displayed in the title bar of the window. The GUI title does not belong to a GUI status - you must set it separately using the ABAP statement SET TITLEBAR.

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 TZ10, for example, looks like this:

  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.