http://sap.mis.cmich.

edu/sap-abap/

Dialog Programs: Overview 

GUI-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 with database 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:
 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 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:
 o Process Before Output (PBO). This defines the processing that takes place before the
screen is displayed.
o 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 even 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 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, youcannot 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

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).
Error Dialogs

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 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 Programming Database Updates.

   Programming Dialog Applications 

Use

SAP provides various help functions in the form of service BAPIs to support the programming of dialog
applications.

Features

In dialog applications you can use the following help functions: The service BAPIs can be found in the
BOR component hierarchy under Basis Components   Middleware.

Transaction Control

Each dialog transaction that uses BAPIs to change data in one or more objects must directly execute the
COMMIT WORK command to save the data. The BAPIBapiService.TransactionCommit() is used for this
and it writes the changes to the database.

If data is not to be written to the database, the BAPI BapiService.TransactionRollback() can reset the

changes, provided that the changes have not already been passed to the database with the
BAPIBapiService.TransactionCommit(). This works provided that the
BAPI BapiService.TransactionCommit has not already passed the changes to the database.

Input Help (F4 Help)

To display the possible entries (F4 help) for an input field transferred when a BAPI is called, you should
include the service BAPI HelpValues.GetList() in your program. This BAPI supplies the input values
allowed for the field in a BAPI parameter.

The method HelpValues.GetList() method uses the help view for the check table, matchcodes or domain
fixed values linked to the field in the ABAP Dictionary. For information about check tables, matchcodes
and domain fixed values see the ABAP Dictionary.
F1 Help (Field Help)

To provide F1 help (field help) for input fields in your application you can use the
BAPI BapiService.FieldHelpGetDocu(). This method reads the documentation (F1 help) on the fields in a
BAPI parameter.

Interpreting Return Messages

Each BAPI contains a parameter named Return. This parameter reports exception messages or success
messages back to the calling program.

Two service BAPIs can diagnose and process error messages from BAPI calls:

 BapiService.MessageGetDetail() displays the short and long texts of BAPI error messages.

 BapiService.ApplicationLogGetDetail(), displays the entries in application logs.

Further Information

For further information refer to the documentation on the appropriate BAPI in the Business Object
Repository.

A list of all the service BAPIs available can be found under Service BAPIs for Help Functions.