SAP ABAP Dialog Programming

SAP ABAP dialog programming can be a blurry term denoting one or another thing for different specialists. However, in this tutorial, we will stick to the general approach and will consider SAP ABAP dialog programming as programming involving dialog objects, such as classic SAP screens (Dynpros), selection screens, transactions, GUI statuses and all controls of SAP GUI Control Framework. This tutorial is part of our free SAP ABAP training.

SAP ABAP Dialog Objects

The main dialogs objects in SAP ABAP are screens (or Dynpros) and selection screens, along with the complimentary object alike GUI statuses, GUI titles, transaction codes and context menus. Let us consider two main dialog objects in ABAP: classic screen and selection screen.

Classic Screen

Classic screen or Dynpro is the thing you will meet most often in ABAP. It can comprise of multiple smaller objects and controls inside. Here is the schematic picture of a typical SAP ABAP screen.

The above screen is the standard screen from CR03 transaction. However, users can freely create custom screens too. Every screen, besides graphical representation, has its internal number and programmatic entity. It can be reviewed in ABAP Workbench transaction (SE80) by ticking target program hierarchy and expanding screens tree.

Each screen is a programmatic object which can be called by the ABAP statement CALL SCREEN like this:

CALL SCREEN dynnr.

where dynnr is a Dynpro number.

It is worth saying that not every screen can be called programmatically and not in every place it can be called. For example, it is not recommended to call the default selection screen 1000 from code. However, selection screens will be discussed further.

We already know that classical screens are both programmatic and visual objects, but how they are created? For this purpose, one can use the usual development transaction SE80 or a special transaction SE51, called Screen Painter.

Here, one can edit and create screens using different approaches: by specifying attributes, by direct graphical painting and by editing layout.

Basic screen elements that can be placed onto the screen are:

• Check Box
• Text Field
• Push Button
• Input Field
• Radio Button
• Tabstrip Control
• Table Control
• Custom Control

Here we do not dive into the GUI controls details and will review them in the future tutorials.

Selection Screen

The second type of dialog objects in ABAP is a selection screen. What is its main difference from classic selection screens? The thing is pretty self-explanatory and lies in the name: they are used for selection of data from database. Classic screens can carry this function too but selection screens do this significantly better and here is why: they do not need to be created in advance but are rather declared via a set of declarative statements. This makes development process more robust, rapid and allows to fulfill routine reporting tasks more easily. The main declarative screen for selection screen is created like this:

SELECTION-SCREEN BEGIN OF SCREEN ssn.
...
SELECTION-SCREEN END OF SCREEN ssn.

where ssn is the screen number.

Corresponding declarative statements for different selection controls are listed below.

Empty line for division of different controls on the screen is declared like this:

SELECTION-SCREEN SKIP 3.

where 3 is the number of lines to be skipped.

Split line for the same aims is declared like this:

SELECTION-SCREEN ULINE [[/][pos](len)] [MODIF ID modid].

where pos is the start column of the line, len is line length, and modid is the group modifier ID.

Comment in selection screen is created like this:

SELECTION-SCREEN COMMENT [/][pos](len)
{text|{[text] FOR FIELD sel}}
[VISIBLE LENGTH vlen]
[MODIF ID modid]

where pos is the start column of the line, len is line length, modid is the group modifier ID, text is comment text, sel is the selection field for which the comment is put, and vlen is the comment visible length.

Button on selection screen is declared like this:

SELECTION-SCREEN PUSHBUTTON [/][pos](len) button_text
USER-COMMAND ucom
[VISIBLE LENGTH vlen]
[MODIF ID modid]

where pos is the start column of the button, len is the button’s length, modid is the group modifier ID, button_text is the button label, ucom is the command which this button initiates, and vlen is the button visible length.

Block is a selection screen entity which groups some set of elements to process these elements in a batch during event handling. It is declared like this:

SELECTION-SCREEN BEGIN OF BLOCK block
[WITH FRAME [TITLE title]]
[NO INTERVALS]
...
SELECTION-SCREEN END OF BLOCK block

where block is the block ID, and title is the title of the block frame.

Events in SAP ABAP Dialog Programming

To have a good grasp of dialog events one should have a good understanding what is a dialog step in SAP.

The user interaction with SAP system is divided into dialog steps which forms screen sequences that users see on their screens. Dialog step is a functional unit that exposes some piece of functionality to the user, waits for their reaction and handles user actions. It can be divided into three logical steps:

1. PBO or Process Before Output
2. Screen showing
3. PAI or Process After Input

PBO – Process Before Output

PBO or Process Before Output is a Dynpro dialog event that is fired before the screen is showed to a user. After the processing of this event, ABAP Runtime Environment passes global variables to the corresponding screen fields. Passing is done based on their names: variable is passed to the screen field with the same name.

PAI – Process After Input

PAI is a Dynpro dialog event that is fired after showing the screen and after the user triggered some action on the screen by executing any screen control that is associated with function code. What is a function code? It is some code assigned to any element in screen painter which defines event ID by which ABAP Runtime Environment handles user actions. A function code can be assigned in GUI mode, like for classic screens, or declaratively, like for selection screens. In GUI, one can assign function code in element properties like shown below.

For a selection screen, one can declare function code via USER-COMMAND clause. For example, for a button it will be:

SELECTION-SCREEN PUSHBUTTON USER-COMMAND ucom.

POH – Process on Help Request

Other important dialog events one can meet in his ABAP practice include POH or Process on Help Request. It is a dialog event fired when a user presses F1 button, i.e. requests help from SAP GUI. The developer can build in some custom help window or embed some additional processing.

POV – Process on Value Request

POV or Process on Value Request is the most interesting and one of the most important events a developer uses in his practice. It is fired when a user requests search help by F4 button in any screen or GUI control within SAP environment. We have already reviewed search help in the previous tutorials, so nothing is new here.

With the help of this event a developer calls standard and custom events, handles user choice after the calls and makes additional processing of the results.

Screen Flow Statements

In the previous section, we reviewed main dialog events in ABAP screen processing but didn’t discuss how they are implemented and processed in practice. Let us dive into some details.

PBO and PAI events are implemented using the declarative keyword PROCESS which defines processing blocks for dialog events. The typical screen processing looks like this:

PROCESS BEFORE OUTPUT.
MODULE status_0500.
PROCESS AFTER INPUT.
MODULE user_command_0500.

Each processing block is started with the word PROCESS and ends with the next block declaration. These statements are formally not ABAP and are treated as a screen subset of ABAP language.

These statements are put into the Screen Flow Logic tab of the screen properties as shown below.

Event handling logic for dialog events is usually packed into dialog modules which are defined using keyword MODULE. In our example, we see status_0500 module which is executed on PBO event.

MODULE status_0500 OUTPUT.
SET PF-STATUS 'STATUS_0500'.
ENDMODULE.

Here, we see that in status_500 module GUI status STATUS_0500 is set.

Let’s have a look at another example. The user_command_0500 module is executed on PAI event. The latter module name is quite self-explanatory and defines actions which should be done for different function codes. Let us analyze a typical INPUT dialog module where user actions are handled:

DATA: ok_code TYPE sy-ucomm,
MODULE user_command_0500 INPUT.
CASE ok_code.
WHEN ‘BACK’
CALL SCREEN 0005.
WHEN ‘FORTH’
CALL SCREEN 0010.
...
ENDCASE.
ENDMODULE.

Firstly, ok_code variable is declared. It is a good practice to store function code from SY-UCOMM there, as SY-UCOMM often changes during runtime.

Then, CASE statement is called which allows handling of user commands and calling appropriate screen for each function code. This simplest sample module shows how one can handle events from user input using a CASE statement which allows to fulfill most of the routine tasks in SAP ABAP dialog programming.

—

Did you like this tutorial? Have any questions or comments? We would love to hear your feedback in the comments section below. It’d be a big help for us, and hopefully it’s something we can address for you in improvement of our free SAP ABAP tutorials.