Entering content frame

Sample Transaction Locate the document in its SAP Library structure

The simple sample transaction DEMO_TRANSACTION from the SABAPDOCU package illustrates the concept behind dialog-driven transactions and their use.

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:

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

Structure

The structure of the sample transaction is described below.

All of its components belong to the program SAPDEMO_TRANSACTION. 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 DEMO_TRANSACTION contains only texts and input/output fields.

A screen consists of several components:

This graphic is explained in the accompanying text

        Screen attributes: Specify the screen number, the 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 the screen.

        Flow logic: Call of the ABAP modules for a screen.

You create all of the components of a screen using the Structure linkScreen 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 dynpros determine which screen to display 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 Structure linkScreen 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 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 screen.

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 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 SAPMname, the hierarchy tree in the 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 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 modules
INCLUDE mdemo_transactioni01.

* PBO modules
INCLUDE 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.

  DATA ok_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 screen and the ABAP program, since the input/output fields on the screen were created with the same ABAP Dictionary reference. The ok_codefield is used to receive function codes from the identically-named screen field.

In the include program mdemo_transactiono01, the PBO module for screen 100 sets the dialog status STATUS_0100 and the GUI title 100. This GUI status and title apply to all subsequent screens 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 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 linkMenu Painter in the ABAP Workbench. On screens, GUI statuses of type dialog status are used.

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 typically contains all elements it supports: menu bar, standard toolbar, application toolbar, and key assignment. 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 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 combine with the other UI elements under a GUI status. Every GUI title must be set explicitly 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 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 USER_COMMAND_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