
In a dialog-driven ABAP program, the program flow is driven 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 dynpro 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 day in question in the reserved seat to the chosen destination, or the system displays the information that the flight is already fully booked.
To meet these requirements, a dialog program must offer:
ABAP offers a variety of tools and language elements to meet the requirements stated above in the dialog programs.
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 multiple users work 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 dynpro 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. Dynpros 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 dynpros using the CALL SCREENstatement. The program text of the executable program or function module must contain the relevant dialog module.
Programs that are partially or fully dialog-driven cannot be executed in the background. They are therefore sometimes referred to as dialog programs.
A dialog-driven program consists of the following basic components:
The transaction code starts a dynpro sequence. You create transaction codes in Repository Browser in ABAP Workbench or using transaction SE93. A transaction code is associated with an ABAP program and an initial dynpro. As well as using a transaction code, you can start a dynpro sequence from any ABAP program using the CALL SCREEN statement.
Each dialog in an SAP system is controlled by one or more dynpros . These screens consist of a screen mask and its flow logic. Since the flow logic influences the program flow, screens are often referred to as "dynamic programs" ("dynpros"). You create dynpros using Screen Painter in ABAP Workbench. Each dynpro is associated with 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 dynpros called within an ABAP program must be associated with a program. The dynpros of a program are numbered. For each dynpro, the system stores the number of the dynpro which is normally displayed next. This means the dynpro sequence or chain can be linear as well as cyclic. From within a dynpro sequence, another dynpro sequence can be called and, after being processed, you return to the original sequence. You can also override the standard next dynpro from within the dialog modules of the ABAP program.
Each screen has a GUI status . This controls the menu bars, standard toolbar, and application toolbar, used by the user to choose functions in the application. Like dynpros, GUI statuses are independent components of an ABAP program. They are created in ABAP Workbench using Menu Painter.
Each dynpro and each GUI status in the SAP system are associated with one ABAP program. The ABAP program contains the dialog modules that are called by the dynpro flow logic, and also process the user input from the GUI status. ABAP programs that use dynpros 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 associate dynpros with 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 dynpro 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.
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 passes the data by comparing the names of dynpro fields with the names of the ABAP fields in the program. If it finds a pair of matching names, the data is passed between the dynpro and the ABAP program. This happens immediately before and immediately after displaying the dynpro.
Field Attributes
The field attributes for all screen fields of a dynpro are defined in 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. This means a large number of field attributes for the dynpro are applied automatically from ABAP Dictionary. The field attributes together with data element and domain of the assigned dictionary field form the basis for the standard functions the dynpro 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 dynpro processor is to produce error dialogs. The input data is checked either automatically using check tables from ABAP Dictionary or by the ABAP program itself. The dynpro processor shows the error message on 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 Dynpros .
Data Consistency
To keep data consistent within complex applications, ABAP offers techniques for optimizing database updates that operate independently of the underlying database and meet the special requirements of dialog programming. See also Data Consistency .