use of module pool programming in Sample Transaction

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.

Features

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:

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

Structure

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.

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

A screen consists of several components:

• Screen attributes: Specification of the screen number, number of the next screen and other attributes.

• Layout: Positions of the texts, fields, pushbuttons, and so on for a screen.

• Field attributes: Definition of the properties of the individual fields on a screen.

• Flow control: Call of the ABAP module for a screen.

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

Layout

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 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:

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, the hierarchy tree in the Repository Browser allows you to create the following include programs:

• Global fields: Global data declarations in the include MTOP. This data is visible in all modules within the program.

• PBO module: Dialog modules in the includes MO, which are called before a screen is displayed.

• PAI module: Dialog modules in the includes MI, which are called after user actions on screens.

• Subroutines: Subroutines within the program, stored in the includes MF. These can be called from anywhere in the program.

• List events: Event blocks for list processor events, stored in the includes ME. These occur during list processing.

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.
SET PF-STATUS ‘ TZ0100 ’ .
SET TITLEBAR ‘ 100 ’ .
ENDMODULE.

*----------------------------------------------------------------*
* INCLUDE MDEMO_TRANSACTIONI01 (This is a PAI include.) *
*----------------------------------------------------------------*
*&---------------------------------------------------------------*
*& Module USER_COMMAND_0100 INPUT
*&---------------------------------------------------------------*
* Get 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.

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 Menu Painter in the ABAP Workbench. A GUI status of type dialog status is used in screens.

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:

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.