Example Transaction

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:

The structure of the example transaction is described below.

All of its components belong to the program SAPDEMO_TRANSACTION. You can display them in 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 ABAP Workbench.

Dynpro

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 dynpro consists of several components:

• Dynpro attributes: 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: Attributes of the individual fields on a screen..
• Flow logic: Calls the ABAP modules for a screen.

You create all of the components of a dynpro using Screen Painter . To start Screen Painter, create a dynpro in Repository Browser or double-click an existing one. Repository Browser calls Screen Painter, where you can enter the flow logic of the dynpro 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 dynpro attributes screen.

Dynpro 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 transaction's attributes determine the first screen to be displayed. The attributes of the individual screens determine which screen to display after the current screen. You can also set the number of the next screen dynamically from within the ABAP program.

For our example, the dynpro attributes do not need to be changed, since no next screen is called.

Layout

To start the layout editor in Screen Painter, choose Fullscreen. Here you can determine the layout of the dynpro. For transaction DEMO_TRANSACTION, the desired fields can be copied from table SPFLI of the ABAP Dictionary. For more information, see the Screen Painter documentation.

Field Attributes

In the Field 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 Screen Painter.

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 statements introduce the flow logic for the two events PBO and PAI. The MODULEstatements 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 dynpro.

The flow logic syntax contains only a few statements. The most important are MODULE, FIELD, CHAIN, LOOP, 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

The ABAP program is a module pool. When you create a module pool in Repository Browser, ABAP Workbench automatically organizes the program code into a series of include programs. If your ABAP program observes the naming convention SAPMname, the hierarchy tree in Repository Browser allows you to create the following include programs:

• Global fields: Global data declarations in the include MnameTOP. This data is visible in all modules within the program.
• PBO modules: Dialog modules in the includes MnameOnn, which are called before a screen is displayed.
• PAI modules: Dialog modules in the includes MnameInn, which are called after user actions on screens.
• Subroutines: Subroutines within the program, stored in the includes MnameFnn. These can be called from anywhere in the program.
• List events: Event blocks for list processor events, stored in the includes MnameEnn. These occur during list processing.

Include programs can contain multiple 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 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 dataINCLUDE mdemo_transactiontop.* PAI-ModuleINCLUDE mdemo_transactioni01.* PBO modulesINCLUDE mdemo_transactiono01.

In the current example program, the resolved 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.  DATAok_code(4).

*----------------------------------------------------------------**   INCLUDE MDEMO_TRANSACTIONO01  (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 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.

In the include program mdemo_transactiontop, the TABLESstatement creates a table work area for the database table SPFLI. The table work area serves as an interface for passing data between the dynpro and the ABAP program, since the input/output fields on the dynpro were created with the same ABAP Dictionary reference. The ok_codefield is used to apply function codes from the identically named dynpro field.

In the include program mdemo_transactiono01, the PBO module for dynpro 100 sets the dialog status STATUS_0100 and the GUI title 100. This GUI status and title apply to all next dynpros until you set new ones. It is important that you set a dialog status, since the system otherwise uses an empty dialog 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 WHEREcondition 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 dynpro.

GUI Status and GUI Title

The GUI status and GUI title are interface elements of screens. You create both of them using Menu Painter in ABAP Workbench. On dynpros, GUI statuses of type dialog status are used.

A dialog status is a collection of interactive interface elements for a screen. To apply a set of these 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 dynpro of a transaction typically contains all elements it supports: menu bar, standard toolbar, application toolbar, and key setting. Each of these functions send a function code to the PAI modules of the current dynpro when the user chooses them by choosing a menu entry, pushbutton, or function key. There are also more special GUI statuses called (status for) dialog windows and context menus. They contain, adapted to the special purpose, fewer elements. A status for a dialog window has no menu bar and no standard toolbar. A context menu is an individual context-dependent menu, which can be activated by using 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 with the other UI elements under a GUI status. Every GUI title must be set explicitly using the ABAP statement SET TITLEBAR.

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 dynpros in sequence, and calls the corresponding ABAP processing modules.

The runtime environment comprises the dynpro processor and ABAP processor (see Work Processes ). For each screen, the dynpro processor executes the flow logic, from which the corresponding ABAP processing is called. The control alternates between the dynpro 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 dynpro processing - PBO and PAI. The runtime environment (the dynpro processor in this case), triggers the events (for example, PAI after a user action on the screen).

The order of events for transaction DEMO_TRANSACTION, for example, looks like this:

1. In the dynpro 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 dynpro 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 USER_COMMAND_0100, control returns to the dynpro processor. Since the dynpro has the static next screen 100 (defined in the dynpro attributes), the program flow begins again at step 1.

Each time control passes between the two processors, the system passes 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 dynpro fields. Data is passed in the opposite direction when control passes from the processing logic back to the flow logic. Each dynpro 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.