Dialog Programs: OverviewGUI-Status
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 withdatabase updates, it means a change in state in the database.
Programs with type M can only be started using a transaction code, in which an initial screen is defined. Programs with type 1 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. Type M programs serve principally as containers for dialog modules, and are therefore known as module pools. Type 1 programs, or function modules can also switch to dialog mode by calling screens using the CALL SCREEN statement. The program code of the corresponding executable program or function pool must then contain the corresponding dialog modules.
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:
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.
Each dialog in an SAP system is controlled by one or more
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:
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
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.
Each screen and GUI status in the R/3 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 (type M program); 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 then called differently; 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.
For all screen fields of a dialog screen, field attributes 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).
Another task of the screen processor is to conduct 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 alsoMessages on Screens.
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 alsoProgramming Database Updates.