Modulepool Programming Tutorials
Dialog Programming
This is a classical programming method that is based on dynpros and dialog transactions.
Classic Application Programming
Separating the application layer from the presentation layer means that when you run an ABAP application program requiring user interaction, control of the program is continually passed backwards and forwards between these layers. While a screen is ready for input, the corresponding SAP GUI of the presentation layer is active. During this time, the application layer is not active for the application program. Therefore, the ABAP application servers are free for other tasks. Once the user has entered data on the screen, program control passes back to the application layer. Now, the presentation layer is inactive. The SAP GUI is still visible to the user during this time, and it is still displaying the screen, but it cannot accept user input. The SAP GUI does not become active again until the application program has called a new screen and sent it to the presentation server.
Consequently, if you use this method, you need to divide dialog programs into single dialog steps, with each of these steps comprising the programming logic between two successive screens.
This graphic is explained in the accompanying text
Dispatching Dialog Steps
The number of users logged onto an ABAP application server is often many times greater than the number of available work processes. Furthermore, it is not restricted by the SAP NW AS ABAP architecture. Furthermore, each user can run several applications at once. The dispatcher has the important task of distributing all dialog steps among the work processes on the ABAP application server.
The following example shows how this might happen:
This graphic is explained in the accompanying text
1. The dispatcher receives the request to execute a dialog step from user 1 and directs it to work process 1, which happens to be free. The work process addresses the context of the application program (in shared memory) and executes the dialog step. It then becomes free again.
2. The dispatcher receives the request to execute a dialog step from user 2 and directs it to work process 1, which is now free again. The work process executes the dialog step as in step 1.
3. While work process 1 is still working, the dispatcher receives a further request from user 1 and directs it to work process 2, which is free.
4. After work processes 1 and 2 have finished processing their dialog steps, the dispatcher receives another request from user 1 and directs it to work process 1, which is free again.
5. While work process 1 is still working, the dispatcher receives a further request from user 2 and directs it to work process 2, which is free.
From this example, we can see that:
· A dialog step from a program is assigned to a single work process for execution.
· The individual dialog steps of a program can be executed on different work processes, and the program context must be addressed for each new work process.
· A work process can execute dialog steps of different programs from different users.
The example does not show that the dispatcher tries to distribute the requests to the work processes such that the same work process is used as often as possible for the successive dialog steps in an application. This is useful, since it saves the program context having to be addressed each time a dialog step is executed.
Dispatching and the Programming Model
As already mentioned (see Database Connection section), a work process can only make database changes within a single database logical unit of work (LUW). The contents of the database must be consistent at its beginning and end. The end of such an inseparable sequence of database operations is defined by a commit command to the database system (database commit). During a database LUW, that is, between two database commits, the database system itself ensures consistency within the database. In other words, it takes over tasks such as locking database entries while they are being edited, or restoring the old data (rollback) if a step terminates in an error.
A typical SAP application program extends over several screens and the corresponding dialog steps. The user requests database changes on the individual screens that should lead to the database being consistent once the screens have all been processed. However, the individual dialog steps run on different work processes, and a single work process can process dialog steps from other applications. It is clear that two or more independent applications whose dialog steps happen to be processed on the same work process cannot be allowed to work with the same database LUW.
Consequently, a work process must open a separate database LUW for each dialog step. The work process sends a commit command (database commit) to the database at the end of each dialog step in which it makes database changes. These commit commands are called implicit database commits, since they are not explicitly written into the application program.
These implicit database commits mean that a database LUW can be kept open for a maximum of one dialog step. This leads to a considerable reduction in database load, serialization, and deadlocks, and enables a large number of users to use the same system.
This graphic is explained in the accompanying text
However, the question now arises of how this method (1 dialog step = 1 database LUW) can be reconciled with the demand to make commits and rollbacks dependent on the logical flow of the application program instead of the technical distribution of dialog steps. Database update requests that depend on one another form logical units in the program that extend over more than one dialog step. The database changes associated with these logical units must be executed together and must also be able to be undone together.
The SAP programming model contains a series of bundling techniques that allow you to group database updates together in logical units. The section of an ABAP application program that bundles a set of logically-associated database operations is called an SAP LUW. Unlike a database LUW, a SAP LUW includes all of the dialog steps in a logical unit, including the database update.
Dialog programming deals with the development of multiple objects. All these objects are linked hierarchically to the main program and they are executed in a sequence. Dialog program development makes use of tools in the ABAP workbench. These are the same tools used in standard SAP application development.
Here are the main components of dialog programs −
Screens
Module pools
Subroutines
Menus
Transactions
The Toolset
Toolset
Dialog programs should be developed by the object browser (transaction: SE80) so that all objects become linked to the main program without having to explicitly point each object. Advanced navigation techniques enhance the process of moving from one object to the other.
Screens are made up of screen attributes, screen layout, fields and flow logic. The module pool consists of modularized syntax that is placed inside include programs of the dialog program. These modules can be invoked by the flow logic, which is processed by the dialog processor.
Creating a New Dialog Program
Step 1 − Within the transaction SE80, select ‘Program’ from the dropdown and enter a Z name for your custom SAP program as ‘ZSCREENEX’.
Step 2 − Press Enter, choose ‘With TOP INCL’ and click the ‘Yes’ button.
Creating a New Dialog Program
Step 3 − Enter a name for your top include as ‘ZSCRTOP’ and click the green tick mark.
Step 4 − Within the attributes screen, simply enter a title and click the save button.
Adding a Screen to the Dialog Program
Step 1 − To add a screen to the program, right-click on the program name and select the options Create → Screen.
Step 2 − Enter a screen number as '0211' and click the green tick mark.
Add Screen to Dialog
Step 3 − In the next screen, enter a short title, set to normal screen type and click the save button on the top application toolbar.
Screen Layout and Adding ‘Hello World’ Text
Step 1 − Click the layout button within the application toolbar and the Screen Painter window appears.
Step 2 − Add a Text Field and enter some text such as "Hello World".
Add Hello World
Step 3 − Save and activate the screen.
Creating Transaction
Step 1 − To create a transaction code for your program, simply right click on the program name and choose the option Create → Transaction and enter a transaction code as 'ZTRANEX'.
Creating Transaction
Step 2 − Enter the transaction text, program and screen you have just created (ZSCREENEX & 0211), and tick the ‘SAPGUI for Windows’ checkbox in the ‘GUI support’ section.
Executing the Program
Save and activate everything. You can execute the program. As the program executes, the text you entered is displayed on the screen as shown in the following screenshot.
Executing the Program
Screen Attributes
Like all objects in the Repository, screens have attributes that both describe them and determine how they behave at runtime. The following are Important screen attributes in ABAP programming:
· Program
The name of the ABAP program (executable program, module pool or function group) to which the screen belongs.
· Screen number
A four-digit number, unique within the ABAP program, that identifies the screen within the program. If your program contains selection screens, remember that the screen numbers of selection screens and Screen Painter screens both use the same namespace. For example, if you have a program with a standard selection screen, you may not create any further screens with the number 1000. Lists, on the other hand, have their own namespace.
· Screen type
- A normal screen occupies a whole GUI window.
- Modal dialog boxes only cover a part of a GUI window. Their interface elements are also arranged differently. - Selection screens are generated automatically from the definition in the ABAP program. They cannot be generated using the Screen Painter.
- A subscreen is a screen that you can display in a subscreen area on a different screen in the same program.
· Next screen
Statically-defined screen number, specifying the next screen in the sequence. By entering zero or leaving the field blank, you define the current screen as the last in the chain. If the next screen is the same as the current screen, the screen will keep on calling itself. You can override the statically-defined next screen in the ABAP program.
· Cursor position
Static definition of the screen element on which the cursor is positioned when the screen is displayed. By default, the cursor appears on the first input field. You can overwrite the static cursor position dynamically in your ABAP program.
· Screen group
Four-character ID, placed in the system field sy-dyngr while the screen is being processed. This allows you to assign several screens to a common screen group. You can use this, for example, to modify all of the screens in the group in a uniform way. Screen groups are stored in table TFAWT.
· Holding data
If the user calls the screen more than once during a terminal session, he or she can retain changed data as default values by choosing System → User Profile → Hold Data.
Screen Elements
A screen can contain a wide variety of elements, either for displaying field contents, or for allowing the user to interact with the program (for example, filling out input fields or choosing pushbutton functions). You use the Screen Painter to arrange elements on the screen.
You can use the following elements:
· Text fields
Display elements, which cannot be changed either by the user or by the ABAP program.
· Input/output fields and templates
Used to display data from the ABAP program or for entering data on the screen. Linked to screen fields.
· Dropdown list boxes
Special input/output fields that allow users to choose one entry from a fixed list of possible entries.
· Checkbox elements
Special input/output fields that the user can either select (value ‘X’) or deselect (value SPACE). Checkbox elements can be linked with function codes.
· Radio button elements
Special input/output fields that are combined into groups. Within a radio button group, only a single button can be selected at any one time. When the user selects one button, all of the others are automatically deselected. Radio button elements can be linked with function codes.
· Pushbuttons
Elements on the screen that trigger the PAI event of the screen flow logic when chosen by the user. There is a function code attached to each pushbutton, which is passed to the ABAP program when it is chosen.
· Frame
Pure display elements that group together elements on the screen, such as radio button groups.
· Subscreens
Area on the screen in which you can place another screen.
· Table controls
Tabular input/output fields.
· Tabstrip controls
Areas on the screen in which you can switch between various pages.
· Custom Controls
Areas on the screen in which you can display controls. Controls are software components of the presentation server.
· Status icons
Display elements, indicating the status of the application program.
· OK field
Every screen has a twenty-character OK_CODE field (also known as the function code field) that is not displayed directly on the screen. User actions that trigger the PAI event also place the corresponding function code into this field, from where it is passed to the ABAP program. You can also use the command field in the standard toolbar to enter the OK field. To be able to use the OK field, you need to assign a name to it.
All screen elements have a set of attributes, some of which are set automatically, others of which have to be specified in the Screen Painter. They determine things such as the layout of the screen elements on the screen. You can set the attributes of screen elements in the Screen Painter - either for a single element, or using the element list, which lists all of the elements belonging to the current screen. Some of the attributes that you set statically in the Screen Painter can be overwritten dynamically in the ABAP program. For a detailed list of all screen element attributes, see Working with Element Attributes in the Screen Painter documentation.
Screen Fields
Screen fields are fields in the working memory of a screen. Their contents are passed to identically-named fields in the ABAP program in the PAI event, and filled from the same identically-named fields in the program in the PBO event. The screen fields are linked with the input/output fields on the screen and with the OK field. Input and output fields must have a unique name (element attribute Name). This assigns them to a screen field with the same name, which allows you to work with their values in an ABAP program.
The technical attributes length and data type of a screen field are defined by the element attributes DefLg and Format. For the data type, you can select one of the predefined data types in the ABAP Dictionary. These are converted appropriately when data is passed between the screen and the ABAP program. When you use fields from the ABAP Dictionary or the ABAP program, the name, length, and data type of the screen fields are defined automatically (see Linking ABAP Strings to Screen Fields). Otherwise, you have to set these attributes in Screen Painter. Note that you need to specify the name of the OK field for each screen, so that a corresponding screen field can be defined. This makes it possible to use more than one OK field in an ABAP program.
Display elements such as text fields or boxes are not linked to screen fields, and do not necessarily need a unique field name. When you create input and output fields by using fields from the ABAP Dictionary, the system usually also creates field labels using texts from the Dictionary. The default name for these text fields is the same name as the screen fields of the input and output fields.
As well as the screen fields defined in Screen Painter, screens also recognize the same predefined system fields as the ABAP program. In contrast to the ABAP program, however, the system fields are administered in the structure SYST, and not in SY. You therefore need to address them using syst-name.
Example
Suppose we have the following program extract:
DATA: text(10) TYPE c,
number TYPE i.
CALL SCREEN 100.
Screen 100, created in Screen Painter, contains two fields SPFLI-CARRID and SPFLI-CONNID from the ABAP Dictionary and two fields, text and number, from the ABAP program. It also contains three text fields and a box. Overall, the screen looks like this:
This graphic is explained in the accompanying text
The columns of the element list that are relevant for the screen fields are as follows:
Name
Type
defLg
Format
Text/ I/O Template
Group boxes
Frame
62
Test frame
%#AUTOTEXT001
Text
14
Screen fields
SPFLI-CARRID
Text
16
Airline
SPFLI-CARRID
I/O
3
CHAR
___
SPFLI-CONNID
Text
15
Flight number
SPFLI-CONNID
I/O
4
NUMC
____
%#AUTOTEXT002
Text
10
ABAP field1
TEXT
I/O
10
CHAR
__________
%#AUTOTEXT003
Text
10
ABAP field2
NUMBER
I/O
11
INT4
___________
OK
20
OK
________________
The screen has four input/output fields. Each of these fields is linked to an identically-named screen field. The data types and lengths of the screen fields are copied from the ABAP Dictionary or the ABAP program. In our example, the OK_CODE field still needs a name - for example, OK_CODE - to assign it to a screen field.
You can either assign a name to display fields with the type frame and text, or the system can automatically create field names for them. The texts that come from the ABAP Dictionary have the same names as the input/output fields. The texts created in the Screen Painter have generated names.
The last column shows the contents of the screen elements on the screen. Input/output fields only contain the template for the field, since the contents will not be known until runtime. The content of the output fields, on the other hand, are statically defined in Screen Painter and cannot be affected by screen fields.
Screen Flow Logic
Screen flow logic contains the procedural part of a screen. You create it in the flow logic editor in the Screen Painter, which is very similar to the ABAP Editor. The language used to program screen flow logic has a similar syntax to ABAP, but is not part of ABAP itself. It is sometimes referred to as screen language.
Unlike ABAP programs, screen flow logic contains no explicit data declarations. You define screen fields by placing elements on the screen mask.
The screen flow logic is like an ABAP program in that it serves as a container for processing blocks. There are four event blocks, each of which is introduced with the screen keyword PROCESS:
PROCESS BEFORE OUTPUT.
...
PROCESS AFTER INPUT.
...
PROCESS ON HELP-REQUEST.
...
PROCESS ON VALUE-REQUEST.
...
As in ABAP, the event block is introduced by the corresponding keyword statement, and it concludes either when the next block is introduced, or at the end of the program. The first two statements are created automatically by the Screen Painter when you create a new screen. The corresponding events are triggered by the runtime environment:
· PROCESS BEFORE OUTPUT (PBO) is automatically triggered after the PAI processing of the previous screen and before the current screen is displayed. You can program the PBO processing of the screen in this block. At the end of the PBO processing, the screen is displayed.
· PROCESS AFTER INPUT (PAI) is triggered when the user chooses a function on the screen. You can program the PAI processing of the screen in this block. At the end of the PAI processing, the system either calls the next screen or carries on processing at the point from which the screen was called.
· PROCESS ON HELP-REQUEST (POH) and PROCESS ON VALUE-REQUEST (POV) are triggered when the user requests field help (F1) or possible values help (F4) respectively. You can program the appropriate coding in the corresponding event blocks. At the end of processing, the system carries on processing the current screen.
As is normal with events, you must only program event blocks for the events to which you want the flow logic to react. However, the screen flow logic must contain at least the two statements PROCESS BEFORE OUTPUT and PROCESS AFTER INPUT in the correct order.
Within the event blocks, you can use the following screen-keywords:
Keyword
Description
MODULE
Calls a dialog module in an ABAP program
FIELD
Specifies the point at which the contents of a screen field should be transported
ON
Used in conjunction with FIELD
VALUES
Used in conjunction with FIELD
CHAIN
Starts a processing chain.
ENDCHAIN
Ends a processing chain.
CALL
Calls a subscreen.
LOOP
Starts processing a screen table
ENDLOOP
Ends processing a screen table
The functions of the individual statements are described in the following sections.
