Called by the User (Transactions Code) 

In a dialog-driven ABAP program, the program flow is controlled by a series of user dialogs. Dialog-driven programs are typically started using transaction codes, which specify the first screen of the program. This initial screen allows users to enter or request information. The screen flow logic then reacts to the user input by calling various modules of ABAP processing logic. It then moves on to the next screen. The corresponding ABAP processing logic might contain statements for displaying data or updating the database.

Suppose a travel agent wants to book a flight. The agent enters the corresponding data on the screen. The system either confirms the desired request, that is, the agent can book the flight and the customer travels on the desired day in the reserved seat to the chosen destination, or the system displays the information that the flight is already fully booked.

To fulfill such requirements, a dialog program must offer:

·        a user-friendly user interface

·        format and consistency checks for the data entered by the user

·        an easy way of correcting wrong entries

·        access to data by storing it in the database

ABAP offers a variety of tools and language elements to meet the requirements stated above in the dialog programs.

Dialog Programs: Overview

Dialog-driven programs, or any program started using a transaction code, are known as SAP transactions, or just transactions. The term “transaction” is used in several different contexts in the IT world. In OLTP (Online Transaction Processing), where several users are working in one system in dialog mode, the term “transaction” stands for a user request. In conjunction with database updates, it means a change in state in the database.

Module pools can only be started using a transaction code, in which an initial screen is defined. Executable programs can be started either using a transaction code, or by entering the program name in one of the transactions SE38 or SA38. Screens call dialog modules in the associated ABAP program from their flow logic. Modules pools are mainly used as containers for dialog modules. Executable programs, or function modules can also switch to dialog mode by calling screens using the CALL SCREEN statement. The program text of the executable program or function module must contain the relevant dialog module.

Programs that are partially or wholly dialog-driven cannot be executed in the background. They are therefore sometimes referred to as dialog programs.

Components of a Dialog Program

A dialog-driven program consists of the following basic components:

·        Transaction Code

The transaction code starts a screen sequence. You create transaction codes in the Repository Browser in the ABAP Workbench or using Transaction SE93. A transaction code is linked to an ABAP program and an initial screen. As well as using a transaction code, you can start a screen sequence from any ABAP program using the CALL SCREEN statement.

·        Screens

Each dialog in an SAP system is controlled by one or more dialog screens . These screens consist of a screen mask and its flow logic. Since the flow logic influences the program flow, screens are sometimes referred to as “dynamic programs”. You create screens using the Screen Painter in the ABAP Workbench. Each screen belongs to an ABAP program.

The screen has a layout that determines the positions of input/output fields and other graphical elements such as checkboxes and radio buttons. The flow logic consists of two parts:

–         Process Before Output (PBO). This defines the processing that takes place before the screen is displayed.

–         Process After Input (PAI). This defines the processing that takes place after the user has chosen a function on the screen.

All of the screens that you call within an ABAP program must belong to that program. The screens belonging to a program are numbered. For each screen, the system stores the number of the screen which is normally displayed next. This screen sequence can be either linear or cyclic. From within a screen chain, you can call another screen chain and, after processing it, return to the original chain. You can also override the statically-defined next screen from within the dialog modules of the ABAP program.

·        GUI Status

Each screen has a GUI-Status. This controls the menu bars, standard toolbar, and application toolbar, with which the user can choose functions in the application. Like screens, GUI statuses are independent components of an ABAP program. You create them in the ABAP Workbench using the Menu Painter.

·        ABAP Program

Each screen and GUI status in the SAP System belongs to one ABAP program. The ABAP program contains the dialog modules that are called by the screen flow logic, and also process the user input from the GUI status. ABAP programs that use screens are also known as dialog programs. In a module pool the first processing block to be called is always a dialog module. However, you can also use screens in other ABAP programs, such as executable programs or function modules. The first processing block is called differently in this case; for example, by the runtime environment or a procedure call. The screen sequence is then started using the CALL SCREEN statement.

Dialog modules are split into PBO modules and PAI modules. Dialog modules called in the PBO event are used to prepare the screen, for example by setting context-specific field contents or by suppressing fields from the display that are not needed. Dialog modules called in the PAI event are used to check the user input and to trigger appropriate dialog steps, such as the update task.

Passing Data Between ABAP Programs and Screens

How are fields from ABAP programs displayed on the screen? And how is user input on the screen passed back to the ABAP program? Unlike in list programming, you cannot write field data to the screen using the WRITE statement. Instead, the system transfers the data by comparing the names of screen fields with the names of the ABAP fields in the program. If it finds a pair of matching names, the data is transferred between the screen and the ABAP program. This happens immediately before and immediately after displaying the screen.

Field Attributes

The field attributes, for all screen fields of a dialog screen, are defined in the Screen Painter. If a field name in the screen corresponds to the name of an ABAP Dictionary field, the system automatically establishes a reference between these two fields. Thus, a large number of field attributes for the screen are automatically copied from the ABAP Dictionary. The field attributes together with data element and domain of the assigned Dictionary field form the basis for the standard functions the screen executes in a dialog (automatic format check for screen fields, automatic value range check, online help, and so on).

Error Dialogs

Another task of the screen processor is to produce error dialogs. Checking the input data is carried out either automatically using check tables of the ABAP Dictionary or by the ABAP program itself. The screen processor includes the error message into the received screen and returns the screen to the user. The message may be context-sensitive, that is, the system replaces placeholders in the message text with current field contents. In addition, only fields whose contents is related to the error and for which a correction may solve the error can accept input. See also Messages on Screens.

Data Consistency

To keep data consistent within complex applications, ABAP offers techniques for optimizing database updates that operate independent of the underlying database and correspond to the special requests of dialog programming.
See also: Data consistency.