Introduction to ABAP

- Graphical User Interfaces -

Prof. Dr. Heimo H. Adelsberger

Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Table of contents
Table of contents ........................................................................................................................ 2
Table of figures .......................................................................................................................... 4
Copyright .................................................................................................................................... 7
11 Designing user interfaces ................................................................................................... 8
11.1 Screens ....................................................................................................................... 8
11.2 Program types ............................................................................................................. 9
11.2.1 Executable program (type 1) .............................................................................. 9
11.2.2 Module pool (type M) ........................................................................................ 9
11.2.3 Function group (type F) ...................................................................................... 9
11.2.4 Type group ......................................................................................................... 9
11.2.5 Include programs (type I) ................................................................................... 9
11.2.6 Subroutine pool (type S) .................................................................................. 10
11.2.7 Interface pool (type J) ...................................................................................... 10
11.2.8 Class pool (type K) ........................................................................................... 10
11.3 Structuring the program ........................................................................................... 10
11.4 Flow logic of dialog programs ................................................................................. 11
11.5 Structure and properties of screens .......................................................................... 12
11.6 Data exchange between screen and ABAP .............................................................. 13
11.7 Dynamic changes ..................................................................................................... 15
11.7.1 Changing screen elements ................................................................................ 15
11.7.2 Changing the screen flow ................................................................................. 17
11.8 GUI status and GUI title........................................................................................... 21
11.8.1 Functions .......................................................................................................... 23
11.8.2 Function key setting ......................................................................................... 24
11.8.3 Ergonomics ....................................................................................................... 26
11.8.4 Menu bar .......................................................................................................... 26
11.9 Simple design elements ............................................................................................ 27
11.9.1 Text fields ......................................................................................................... 28
11.9.2 Status icons ....................................................................................................... 29
11.9.3 Boxes ................................................................................................................ 30
11.9.4 Input / Output fields ......................................................................................... 31
11.9.5 Checkboxes / radiobuttons ............................................................................... 35
11.9.6 Pushbuttons ...................................................................................................... 38
11.10 Statements of the screen flow logic ...................................................................... 39
11.10.1 Event blocks ..................................................................................................... 39
11.10.2 The MODULE statement ................................................................................. 40
11.10.3 The FIELD statement ....................................................................................... 40
11.10.3.1 Comparison to a value list ........................................................................ 41
11.10.3.2 Comparison to a database query............................................................... 41
11.10.4 Connection FIELD and MODULE .................................................................. 42
11.10.5 Message types and corresponding screen behavior .......................................... 42
11.10.6 The CHAIN statement ...................................................................................... 44
11.10.7 Conditional calls of modules ............................................................................ 45
11.10.7.1 Execution if initial value changed ............................................................ 45
11.10.7.2 Execution on repeated input ..................................................................... 46
11.10.7.3 Conditional calls of modules in chains .................................................... 46
11.10.7.4 Execution on exit functions ...................................................................... 46
11.10.7.5 Switch dependent execution ..................................................................... 47
Page 2
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

11.11 Exercise: Designing user interfaces ..................................................................... 47

11.11.1 Creating the program ........................................................................................ 47
11.11.2 Creating the first screen .................................................................................... 49
11.11.3 Configuring GUI status and title bar ................................................................ 57
11.11.4 Implementing the PAI logic of the first screen ................................................ 61
11.11.5 Creating the connection editing screen ............................................................ 64
11.11.6 Configuring GUI status and titlebar for the second screen .............................. 65
11.11.7 Implementing the PAI logic of the second screen ............................................ 68
11.11.8 Adding messages .............................................................................................. 70
11.11.9 Keeping fields enabled and leaving despite wrong input ................................. 71
11.12 Complex design elements..................................................................................... 72
11.12.1 Subscreens ........................................................................................................ 72
11.12.2 Tabstrips ........................................................................................................... 76
11.12.2.1 Tabstrip scrolling without PAI ................................................................. 79
11.12.2.2 Tabstrip scrolling with PAI ...................................................................... 80
11.12.3 Exercise: Tabstrips and subscreens .................................................................. 82
11.13 Chapter Submission.............................................................................................. 89
12 Further concepts ............................................................................................................... 90
12.1 Number ranges ......................................................................................................... 90
12.2 Calling programs ...................................................................................................... 94
12.2.1 Calling executable programs ............................................................................ 94
12.2.1.1 Excursus: Variants.................................................................................... 95
12.2.1.2 Exercise: Variants .................................................................................... 95
12.2.2 Calling transactions .......................................................................................... 96
12.2.3 Calling function modules ................................................................................. 97
12.2.4 Data exchange between programs .................................................................... 97
12.2.4.1 Using the SAP memory ............................................................................ 97
12.2.4.2 Using the ABAP memory ........................................................................ 97
12.3 Locks ........................................................................................................................ 98
12.4 Exercise on locks .................................................................................................... 100
12.5 Remoting ................................................................................................................ 105
12.6 Predefined input checks ......................................................................................... 106
12.6.1 Input check by a domain ................................................................................ 106
12.6.2 Input checks based on foreign keys ................................................................ 107
12.6.3 Exercise on input checks ................................................................................ 110
12.7 Search helps ............................................................................................................ 113
12.7.1 Selection method ............................................................................................ 116
12.7.2 Dialog behavior .............................................................................................. 116
12.7.3 Interface .......................................................................................................... 118
12.7.4 Search help attachment ................................................................................... 120
12.7.5 Determination of the search help to be used .................................................. 121
12.7.6 Collective search helps ................................................................................... 121
12.7.7 Append search helps ....................................................................................... 123
12.7.8 Further adaptations of search helps ................................................................ 123
12.7.9 Exercise on search helps ................................................................................ 124
12.8 Chapter Submission................................................................................................ 126

Page 3
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Table of figures
Figure 1: Error message: SAP-System-Screenshot .................................................................... 9
Figure 2: Organization of a program: SAP-System-Screenshot .............................................. 10
Figure 3: Process flow of a chain of screens ............................................................................ 11
Figure 4: Modules .................................................................................................................... 11
Figure 5: Structure of a screen ................................................................................................. 12
Figure 6: Data exchange between screen and ABAP ............................................................... 14
Figure 7: The system table SCREEN (excerpt)....................................................................... 15
Figure 8: Element list of a screen: SAP-System-Screenshot ................................................... 16
Figure 9: Element list of the Screen Painter: SAP-System-Screenshot ................................... 16
Figure 10: Static screen sequence ............................................................................................ 17
Figure 11: Dynamic setting of the next screen number............................................................ 18
Figure 12: Inserted screen sequence ......................................................................................... 19
Figure 13: Dynamic positioning of called screens ................................................................... 20
Figure 14: Structure of a GUI status ........................................................................................ 22
Figure 15: Inner structure of a GUI status ................................................................................ 23
Figure 16: Function key setting: SAP-System-Screenshot ...................................................... 24
Figure 17: Assigning a function to a function key: SAP-System-Screenshot.......................... 25
Figure 18: Assigning the function to a pushbutton: SAP-System-Screenshot ......................... 25
Figure 19: Pushbutton in the application toolbar: SAP-System-Screenshot ............................ 25
Figure 20: A function in the standard toolbar: SAP-System-Screenshot ................................. 25
Figure 21: Example menu: SAP-System-Screenshot ............................................................... 27
Figure 22: Example of a sub menu........................................................................................... 27
Figure 23: Possible icons (selection): SAP-System-Screenshot .............................................. 29
Figure 24: Filling status icons .................................................................................................. 30
Figure 25: An empty box: SAP-System-Screenshot ................................................................ 30
Figure 26: Input/Output field (here with value help): SAP-System-Screenshot ...................... 31
Figure 27: The window Dict. / Program Fields: SAP-System-Screenshot .............................. 33
Figure 28: The attribute window: SAP-System-Screenshot .................................................... 34
Figure 29: SET/GET parameters .............................................................................................. 35
Figure 30: Creating checkboxes and radiobuttons ................................................................... 36
Figure 31: Processing function codes ....................................................................................... 37
Figure 32: PBO and PAI .......................................................................................................... 39
Figure 33: Input check using an error message ........................................................................ 42
Figure 34: Messages and screens ............................................................................................. 43
Figure 35: The CHAIN statement ............................................................................................ 44
Figure 36: Behavior after the input has been changed ............................................................. 45
Figure 37: Exit function in the Menu Painter: SAP-System-Screenshot ................................. 47
Figure 38: Program attributes: SAP-System-Screenshot ......................................................... 48
Figure 39: Top include: SAP-System-Screenshot .................................................................... 49
Figure 40: Graphical Screen Painter after changing the text field: SAP-System-Screenshot .. 50
Figure 41: Dict/Program Fields window: SAP-System-Screenshot ........................................ 51
Figure 42: Outline of the fields: SAP-System-Screenshot ....................................................... 51
Figure 43: Graphical Screen Painter with the input fields: SAP-System-Screenshot .............. 52
Figure 44: Element list: SAP-System-Screenshot .................................................................... 53
Figure 45: Creating a transaction: SAP-System-Screenshot .................................................... 54
Figure 46: Attributes of the transaction: SAP-System-Screenshot .......................................... 55
Figure 47: Screen flow logic: SAP-System-Screenshot ........................................................... 56
Figure 48: Creating the include: SAP-System-Screenshot....................................................... 56
Page 4
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 49: Program with value help: SAP-System-Screenshot ............................................... 57

Figure 50: Creating a module: SAP-System-Screenshot ......................................................... 58
Figure 51: Changed code of the include: SAP-System-Screenshot ......................................... 58
Figure 52: Defining function codes: SAP-System-Screenshot ................................................ 59
Figure 53: Function Attributes: SAP-System-Screenshot ........................................................ 60
Figure 54: Create title: SAP-System-Screenshot ..................................................................... 60
Figure 55: Changed user interface: SAP-System-Screenshot .................................................. 61
Figure 56: Creating the module: SAP-System-Screenshot ...................................................... 62
Figure 57: Code of the module: SAP-System-Screenshot ....................................................... 63
Figure 58: Field conversion: SAP-System-Screenshot ............................................................ 64
Figure 59: Disabling input: SAP-System-Screenshot .............................................................. 65
Figure 60: Screen layout: SAP-System-Screenshot ................................................................. 65
Figure 61: Setting the include name: SAP-System-Screenshot ............................................... 66
Figure 62: Setting function codes (OK codes): SAP-System-Screenshot................................ 66
Figure 63: Source code with the assignment: SAP-System-Screenshot .................................. 67
Figure 64: Data on the second screen: SAP-System-Screenshot ............................................. 68
Figure 65: Selecting the include name: SAP-System-Screenshot ............................................ 68
Figure 66: Completed source code: SAP-System-Screenshot ................................................. 69
Figure 67: Error message for wrong connections: SAP-System-Screenshot ........................... 70
Figure 68: Loading a subscreen into a subscreen area ............................................................. 73
Figure 69: Subscreen call including PBO / PAI ....................................................................... 74
Figure 70: Subscreens and data transport ................................................................................. 75
Figure 71: Data transport to subscreens in function groups ..................................................... 76
Figure 72: Technical structure of a tab ..................................................................................... 78
Figure 73: Tabstrip Control Wizard: SAP-System-Screenshot ................................................ 79
Figure 74: Tabstrips without PAI ............................................................................................. 80
Figure 75: Tabstrips with PAI .................................................................................................. 81
Figure 76: Implementation of PAI scrolling ............................................................................ 82
Figure 77: Creating screen 100: SAP-System-Screenshot ....................................................... 83
Figure 78: Selecting the line: SAP-System-Screenshot ........................................................... 83
Figure 79: Positioning the ID: SAP-System-Screenshot.......................................................... 83
Figure 80: Screen 100: SAP-System-Screenshot ..................................................................... 84
Figure 81: Screen type: SAP-System-Screenshot .................................................................... 84
Figure 82: Fields on screen 101: SAP-System-Screenshot ...................................................... 85
Figure 83: Question about field conversion: SAP-System-Screenshot .................................... 85
Figure 84: Screen 102: SAP-System-Screenshot ..................................................................... 85
Figure 85: Include selection: SAP-System-Screenshot ............................................................ 86
Figure 86: Add a function code: SAP-System-Screenshot ...................................................... 87
Figure 87: Testing the program: SAP-System-Screenshot....................................................... 88
Figure 88: Maintain domain: SAP-System-Screenshot ........................................................... 91
Figure 89: Testing the function module: SAP-System-Screenshot .......................................... 92
Figure 90: Result of the test: SAP-System-Screenshot ............................................................ 93
Figure 91: Output: SAP-System-Screenshot ............................................................................ 93
Figure 92: New variants button: SAP-System-Screenshot....................................................... 96
Figure 93: Interaction with the ABAP Memory....................................................................... 98
Figure 94: Lock object in the Dictionary: SAP-System-Screenshot ...................................... 100
Figure 95: Function module call: SAP-System-Screenshot ................................................... 101
Figure 96: Call of the function module to release the read lock: SAP-System-Screenshot ... 101
Figure 97: Extended CASE structure: SAP-System-Screenshot ............................................ 102
Figure 98: Currently set locks for table SPFLI: SAP-System-Screenshot ............................. 103
Figure 99: Breakpoint: SAP-System-Screenshot ................................................................... 103
Page 5
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 100: Value range of a domain: SAP-System-Screenshot ........................................... 106

Figure 101: Definition of a value table: SAP-System-Screenshot ......................................... 106
Figure 102: Input checks based on foreign keys (1) .............................................................. 107
Figure 103: Input checks based on foreign keys (2) .............................................................. 107
Figure 104: Domain equivalence of check field and key field............................................... 108
Figure 105: Cardinality 1:CN in an example ......................................................................... 109
Figure 106: Text table ............................................................................................................ 110
Figure 107: Values of the domain: SAP-System-Screenshot ................................................. 111
Figure 108: Fields of the chair table: SAP-System-Screenshot ............................................. 111
Figure 109: Fields of the professor table: SAP-System-Screenshot ...................................... 112
Figure 110: Check table: SAP-System-Screenshot ................................................................ 112
Figure 111: Error message after input check: SAP-System-Screenshot ................................ 112
Figure 112: Search help in the ZZ_####_FLEDIT program: SAP-System-Screenshot ........ 113
Figure 113: Context sensitivity: SAP-System-Screenshot ..................................................... 114
Figure 114: Search helps and their interfaces ........................................................................ 115
Figure 115: Pop-Up for value search: SAP-System-Screenshot ............................................ 116
Figure 116: Selection of a search help display: SAP-System-Screenshot ............................. 117
Figure 117: Interface of a search help .................................................................................... 118
Figure 118: Collective search help ......................................................................................... 122
Figure 119: Append search helps ........................................................................................... 123
Figure 120: Search help of the chair field: SAP-System-Screenshot ..................................... 124
Figure 121: Search help parameters: SAP-System-Screenshot .............................................. 124
Figure 122: Using a self-defined search help: SAP-System-Screenshot ............................... 125

Page 6
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Copyright
 All screenshots used within this document, even if displayed in extracts, are subject to
the copyright of SAP AG.
 Theoretical explanations are based on the literature listed in the first script.
 Distribution and reproduction of this document or parts of this document in any form
is prohibited without the written permission of Prof. Dr. Heimo H. Adelsberger, Dipl.-
Wirt.-Inf. Pouyan Khatami and Dipl.-Wirt.-Inf. Taymaz Khatami.

Page 7
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

11 Designing user interfaces

Graphical user interfaces are called screens in ABAP (in German: Dynpro, "dynamisches
Programm" – this name may appear in some system messages, so keep it in mind). You have
already used screens: Selection screens are a special case of automatically generated screens.
However, creating user interfaces based on selection screens only is not very convenient. For
example, often people use positioning values which lead to overlapping elements, as a
consequence generation errors occur when the program shall be activated. Regular screens are
designed in a graphical editor instead. This is a modern approach compared to the selection
screen code and more convenient for the developer: The positioning is done graphically and it
is immediately visible how the user interface will look like for the user.

In this chapter you will learn how to design your own screens and how to connect them to
your ABAP program code.

Attention: The Graphical Screen Painter used in this chapter is only available on Windows
systems, it is not part of the Java-based SAP GUI for Linux or Mac OS systems!

11.1 Screens
Screens are the most important way for ABAP to have programs with flexible graphical user
interfaces. Screens are always components of ABAP programs.

Screens consist of screen elements, which are input fields, buttons etc., and a flow logic.
Within a program, they are uniquely identified by their four-digit number. Selection screens
are also screens, but they are generated automatically by the system. The screen number of the
default selection screen for parameter fields is 1000; hence, this value should not be used by
your programs for manually defined screens. Using screens, it is possible to create modern
graphical user interfaces. The design is supported by a graphical editor in which you can
select the positions of the elements using your mouse. This editor is called the Graphical
Screen Painter.

Screens are executed as a part of dialog transactions. This type of transaction is used the most.

Page 8
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

11.2 Program types

Until now, you were used to choose the program type executable program. During the
creation of programs with screens, you will use the type module pool instead.

In the following sections, the different program types available in the SAP system 1 are
presented and contrasted.

11.2.1 Executable program (type 1)

Executable programs can be executed on their own. They can be called directly from the
ABAP Editor or by choosing System -> Services -> Reporting from the menu. In earlier
days, they were only intended to be used for report processing, which explains the name of
the menu entry and the name of the first statement of the program.

11.2.2 Module pool (type M)

Using module pools, dialog programs with screens can be realized. The module pool is a
container for the dialog modules called from the screen flow logic.

The module pool is not executable on its own. Instead, a dialog transaction must be defined,
in which the first screen to call is specified. The further screen sequence can be defined
statically in the attributes of the screen, or it can be determined dynamically at runtime in the
source code.

Trying to execute a module pool directly instead of calling the corresponding transaction
leads to an error message:

Figure 1: Error message: SAP-System-Screenshot

11.2.3 Function group (type F)

You already know function groups from earlier chapters of the course. They contain function
modules, local data declarations, and screens.

11.2.4 Type group

A Type group contains types and constants, which are used across multiple programs.

11.2.5 Include programs (type I)

An include program contains arbitrary code and is included into another program using the
INCLUDE statement.

1
Cf. Keller (2012, p. 1617)
Page 9
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

11.2.6 Subroutine pool (type S)

A subroutine pool contains forms that can be called using the PERFORM statement.

11.2.7 Interface pool (type J)

An interface pool can contain global interfaces for the use in classes of class pools and local
data declarations.

11.2.8 Class pool (type K)

A class pool contains exactly one global class. More on classes will be discussed in the very
last chapter.

11.3 Structuring the program

Simple programs only contain one source code in which all processing blocks are contained,
like in the examples on selection screens above. Complex programs can be structured. This is
mostly realized by includes.

Figure 2: Organization of a program: SAP-System-Screenshot

During the creation of a program, the option With TOP INCL (with TOP include) can be
chosen. This shall help the user to define a comprehensive structure of the program. In the top
include, global data declarations can be made. In your programs you have not used this option
so far, but you know about includes already.

When further processing blocks are created, for example, during the creation of a PAI
(process after input) module of a screen, the system automatically asks for the include in
which the block should be stored. The include can be created directly from this screen if it
does not exist yet. It is then automatically included into the program by adding the
corresponding include statement to the source code.

Page 10
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

11.4 Flow logic of dialog programs

The processing of a single screen begins with the event PROCESS BEFORE OUTPUT.
Within the processing block of this event, data can be read from the database or prepared in a
different way that is required for the presentation of the screen. Afterwards, the screen
elements (text fields, descriptions, checkboxes etc.) are displayed. They may contain data
already. The user can now interact with the screen, enter data etc. until he or she is finished
and causes an event, for example, by clicking a button. This causes the system to go to
another event block, the PROCESS AFTER INPUT (PAI). In this block the input of the user
is processed usually.

Figure 3: Process flow of a chain of screens

In both event blocks, PROCESS BEFORE OUTPUT and PROCESS AFTER INPUT, dialog
modules are called. These modules contain the actual ABAP code that shall be executed. The
Screens themselves are written with specific screen flow logic statements, which are different
from regular ABAP statements. Each module of the module pool has to be assigned to one of
the phases PAI or PBO. A module may be called by different screens, but it can only be a PAI
module or a PBO module, not both. This is reflected by the initial statement MODULE …
INPUT or MODULE … OUTPUT respectively.

Figure 4: Modules

Page 11
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

The code of the screen flow logic itself is written in a specific language, which is not ABAP.
Nevertheless, it looks like ABAP. Keep this in mind and try to understand if you are currently
writing screen flow logic or an ABAP module.

11.5 Structure and properties of screens

A screen consists of a screen layout and corresponding list of elements, screen properties and
the flow logic discussed above, which itself consists of a PBO (process before output) and a
PAI (process after input).

Figure 5: Structure of a screen

The right of the figure above displays a selection of possible screen elements that can be
placed on the screen layout. All screen elements have attributes. For text fields, input/output
fields, status icons, group boxes, radiobuttons, checkboxes, and buttons, these are general
Dictionary attributes, program attributes and display attributes. For subscreen areas, tabstrips,
and table controls, these are general and specific attributes.

A complete listing of all attributes of each single element would go beyond the scope of this
document. If you are interested in them, you can read about them in the online handbook. You
can call it from the ABAP Workbench using the -button or by choosing the menu path
Goto -> Application Help. In the online handbook you find the attributes under ABAP
Workbench: Tools -> Screen Painter -> Defining the Element Attributes.

Page 12
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Most of the Attributes are statically defined and cannot be changed dynamically, but there are
also attributes that can be changed at runtime. Some attributes, such as the actual position and
size of a screen, can be set at runtime only.

Screens themselves also have attributes. Those attributes that can be set statically can be
found on the attributes tab of the properties of the screen. They comprise:

 General properties
o Screen number
o Short description
o Original language
 Screen type (normal, subscreen, modal dialog box, or selection screen)
 Settings
o Hold data (Enables the user to store his input into the fields for the next call of
the screen)
o Switch off runtime compression
o Template – non-executable (used internally by SAP)
o Hold scroll position
o Without application toolbar
 Other attributes
o Next screen (This attribute can be changed dynamically using the SET
SCREEN statement)
o Cursor position (Can be changed dynamically using the SET CURSOR
FIELD fieldname OFFSET position. Statement. Here, fieldname
is the name of the field where the cursor should be placed, and position the
position of the cursor inside the field.)
o Screen group
o Lines/columns (Occupied and for maintenance, additionally the position and
size at runtime are dynamic attributes)
o Context menu

Also in this case, there is a more complete and detailed list in the online handbook. It can be
found in ABAP Workbench: Tools -> Screen Painter -> Creating Screens.

11.6 Data exchange between screen and ABAP

The statements of the screen flow logic are processed using a special screen processor
(dynpro processor), as opposed to the ABAP statements in the modules that are processed by
the ABAP processor.

TO have a connection between the screen layout and the application logic written in ABAP at
all, it is necessary to transport the content of the fields on the screen to variables of the
application logic and vice versa to transport values of ABAP variables to screen fields. This is
done automatically by the SAP system if the fields on the screen and the variables of the
ABAP program have the same name.

Page 13
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

After all modules of the PBO processing block have been processed, the system copies the
field content from ABAP to the corresponding screen fields. Before the first module of the
processing block PAI is executed, the system copies the field content of the screen fields to
the variables of the ABAP program. The following figure illustrates this process:

Figure 6: Data exchange between screen and ABAP

In the figure, simple field definitions with the DATA statement are used. However, if
Dictionary structures shall be used, it is more convenient to use the statement TABLES. This
statement creates an interface work area, which contains all components of the specified
structure and can also be used for the data transport from/ to corresponding screen fields for

Page 14
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

all its components. These fields can be created in the screen painter by referencing a type of
the ABAP Dictionary. The reference of ABAP Dictionary types is recommended for the
creation of screens, because the settings defined in the Dictionary can be inherited, most
importantly the field label (not displayed here). To make sure the required data is exchanged
between screen and ABAP, it is recommended to define specific structures in the dictionary,
but this is not necessarily required.

Please note that the time of data transport can be influenced by the FIELD statement. This
will be explained in more detail later.

11.7 Dynamic changes

As mentioned in sub chapter 11.5, screens and screen elements have attributes that can be set
statically and/or changed/overwritten dynamically, depending on the kind of attribute.
Dynamic changes are changes at runtime and not permanent changes. In this section, you will
get to know the possibilities to change screen elements at runtime and ways to use them to
improve the screens.

11.7.1 Changing screen elements

Using dynamic changes of screen elements, the need to define lots of screens can be avoided.
If input/output fields are not ready for input, there is no need to define and load a second
screen that is ready for input. Instead, the attributes of input fields can be changed at runtime
using a button, for example.

Figure 7: The system table SCREEN (excerpt)

The system table with the line type SCREEN (system table SCREEN) contains the attribute
values of all elements that have been placed on the screen by the Screen Painter at runtime.
At the PBO, the static attribute values, which were defined in the Screen Painter or in the
element list, are loaded into this table.

Page 15
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

The following screen shot shows the list of these static attribute values in the element list of
the screen. However, these attributes can also be opened in the Screen Painter.

Figure 8: Element list of a screen: SAP-System-Screenshot

The following screen shot sows the same element list as displayed by the Graphical Screen
Painter:

Figure 9: Element list of the Screen Painter: SAP-System-Screenshot

In the ABAP code of a PBO module, a LOOP AT SCREEN loop can be used to iterate the
system table SCREEN and adapt the attributes. The approach is the same as before for the
selection screens, so it will not be discussed another time here.

However, please do not forget that the SCREEN table is an internal table with header line
when you define the loop. Changes made with the header line must be written to the table
using MODIFY SCREEN to make them effective. This behavior is the same as for selection
screens.

The component ACTIVE is a special case among the components. It has no direct
correspondence in the attribute list. Instead, it affects the values of the fields INPUT,
OUTPUT, and INVISIBLE. Statically visible fields become invisible by SCREEN-ACTIVE
= 0, i.e., INPUT and OUTPUT get the value 0, and INVISIBLE gets the value 1. If these
values are set directly, ACTIVE becomes 0. However, Elements that were defined as
statically invisible in the Screen Painter cannot be made visible dynamically using SCREEN-
ACTIVE = 1. Instead, SCREEN-INVISIBLE = 0 is used2.

2
Keller (2012, S. 869)
Page 16
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

11.7.2 Changing the screen flow

Many complex transactions consist of multiple screens, which are presented to the user one
after the other. In most cases the order of screens is known in advance. For this purpose, each
screen has an attribute that specifies the next screen.

Figure 10: Static screen sequence

The figure shows such a static screen sequence. After each PAI, the PBO of the statically
defined next screen is called. This is the default behavior.

Using the statement SET SCREEN dynnr. The screen sequence is overwritten
temporarily, i.e., for the current call. The statement LEAVE SCREEN. can be used to jump to
the next screen immediately without waiting for the application logic of the screen to be
finished. Both steps can be combined into one using the statement LEAVE TO SCREEN
dynnr.
The next figure displays an example for a dynamically changed screen flow:

Page 17
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 11: Dynamic setting of the next screen number

Here, in the PAI of screen 300, the program explicitly requests to go to screen 300 instead of
the statically defined next screen 200. Screen 200 is hence not called at all. The processing of
the PAI of screen 100 is stopped at the point of the statement. If further statements shall be
executed before going to screen 300, SET SCREEN 300 must be used instead.

Page 18
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

The CALL SCREEN statement can be used to insert screens or screen sequences into the
current screen sequence. The following figure displays an example for this:

Figure 12: Inserted screen sequence

At the end of the inserted screen sequence, when the next dynpro number is 0 (statically or
dynamically set), the system jumps back to the position where the call occurred. If the next
screen property is set to 0 or no value is entered at all, the system generally jumps to the
position where the screen was initiated when the current screen is left.
In the figure above, this happens because screen 800 has the static next screen number 0.

It is possible to build even more complex screen sequences, if the inserted screen sequence
itself inserts another screen sequence. Leaving and jumping to the calling position can also be
achieved using SET SCREEN 0. and LEAVE SCREEN. and by LEAVE TO SCREEN
0.. Leaving to a screen 0 outside a screen sequence causes the program to be closed. This is
similar to the statement LEAVE PROGRAM..

Page 19
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

By the addition STARTING AT / ENDING AT of the CALL SCREEN statement, the called
screen can be placed using the coordinates of the left upper or right bottom corner,
respectively:

Figure 13: Dynamic positioning of called screens

When the positioning is used, the called screen must be defined as a modal dialog box in its
properties according to the ergonomic rules of SAP. The positioning information is given in
rows and columns counted from the top left corner.

The ENDING AT addition can cause scroll bars.

Page 20
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

11.8 GUI status and GUI title

A GUI status is the configuration of a menu bar, a standard toolbar, an application toolbar,
and function key settings. A screen can have multiple GUI status, which are chosen according
to the current situation dynamically. To load a GUI status, the following statement is used in
the PBO of a screen3:

SET PF-STATUS status [OF PROGRAM program] [EXCLUDING fcode].

The status is specified by its name as a character-type data object in uppercase letters. If you
create a new screen, the line to set the GUI status is already available but commented out, so
you can insert it quickly. By forward navigation (double click) on the status name, the status
can be created easily.

The menu bar always contains the elements System and Help at least. These elements cannot
be changed.
The application toolbar contains buttons for functions that are called often.
The standard toolbar contains the same symbols, which always have predefined functions.
The Function key settings are used to assign certain functions to the function keys, e.g.,
searching, replacing, or cutting.

The set of all GUI titles and status comprise its user interface. If titles or status are added, the
user interface must be regenerated.

To create a GUI title, there are three possible ways:

 Creating it using forward navigation from the ABAP Editor, as explained above
 Creating it from the object list (the navigation tree) of the Object Navigator
 Creating it from the Menu Painter (transaction code SE41)

For each screen an individual title should be set. This is done independently of the GUI status.
This title may have up to 20 characters. At runtime, placeholders that are indicated by a &
(ampersand) can be filled with certain values. A title with placeholders is set as follows and
stays active until a different title is set4:

SET TITLEBAR title [OF PROGRAM prog] [WITH text1 … text9].

The current title can be retrieved from the system variable sy-title.

3
Keller (2012, p. 860)
4
Keller (2012, p. 863)
Page 21
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 14: Structure of a GUI status

From a technical point of view, a GUI status is a reference to a menu bar, an application
toolbar and a function key setting. These components can be used by different status, as
shown in the figure.

For the status, the same as for the title applies: It should be set for each screen.

Page 22
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 15: Inner structure of a GUI status

The status references a menu bar, which contains a list of menus that refer to certain
functions. Functions are also reachable by buttons of the application toolbar and function
keys. Key setting and application toolbars are sub objects of a function key setting. To be able
to assign a function to a pushbutton, it must be assigned to a function key. This dependency is
illustrated by the additional arrows between the two objects.

The function list contains the set of all user interface functions. All menus and key settings are
related to this list. To see this list, you can use the value help (the F4 help) inside the Menu
Painter.

11.8.1 Functions

The most important property of a function is its function code. Based on this code the function
is identified.

There are 6 types of functions:

 “_“ (Space): Normal function

 E: Exit function
 P: Tabstrip function
 T: Transaction code: Leaving the current program and calling the new program
 S: System (internal by SAP)
 H: Help Request (internal by SAP)

In the GUI status it is possible to change the function type by double-clicking on the function
code, which opens a settings window.

Page 23
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

The functions with static text have the following attributes:

 Function code (see above)

 Function type (see above)
 Function text: Text that is displayed for this function in a menu entry
 Switch / Reaction: Related to the Switch-Framework
 Icon name: Assignment of an icon that is displayed instead of the text if the function is
assigned to a pushbutton. The text is shown as a tooltip if the cursor is hovering the
pushbutton.
 Icon text: Text which is displayed alongside the icon
 Info text: Text which is displayed in the status bar if the function is selected
 Fast path: Assigning characters for the choice of a function from the menu bar without
using the mouse.

11.8.2 Function key setting

The function key setting assigns functions to function keys or pushbuttons. A function key is
the F5 key or the keyboard shortcut Ctrl-F12, for example.

Figure 16: Function key setting: SAP-System-Screenshot

There is a differentiation between reserved function key settings, recommended function

key settings, and freely assigned function keys. Reserved function keys are keys that are
predefined by the SAP system and cannot be changed. These function keys are displayed as
icons in the standard toolbar. There is only the possibility to inactivate them. Recommended
function key settings are keys whose setting SAP recommends to achieve a good usability of
a program.

Functions that are assigned to function keys can also be assigned to pushbuttons in the
application toolbar. The application toolbar can contain up to 35 pushbuttons. For a better
overview, separators can be inserted between groups of pushbuttons here.

Page 24
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Example: First, a function is defined as a function key:

Figure 17: Assigning a function to a function key: SAP-System-Screenshot

Afterwards, this function can be inserted into the application toolbar:

Figure 18: Assigning the function to a pushbutton: SAP-System-Screenshot

The function then appears in the application toolbar with the text defined before:

Figure 19: Pushbutton in the application toolbar: SAP-System-Screenshot

This bottom-up method works also further up to the definition of the menu bar: functions
defined below can be used further above. To select a function for a position in the application
toolbar, you can also use the F4 help and choose the function there.
As already described above, the standard toolbar contains the reserved function keys. A
function that is assigned to the standard toolbar gets assigned to the corresponding reserved
function key automatically:

Figure 20: A function in the standard toolbar: SAP-System-Screenshot

In this example, the function BACK has been assigned. It is thereby automatically connected
to the function key F3.
To insert a separator in the application toolbar, right click into a free field and choose
separator line.

Page 25
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

11.8.3 Ergonomics

When you develop ABAP applications, you should always think about the ergonomics for the
users of your application. Some hints on ergonomics can be found directly inside the SAP
system. To see them, open the Menu Painter and choose the menu path Environment ->
Examples -> Ergonomics Examples -> Screens.

For the navigation with Back, Exit, and Cancel there are some ergonomic rules:

Back and Cancel should lead one logical level up in the program. On single screen
transactions (i.e., transactions which consist of only one screen), Cancel should reinitialize
the screen, however. From the initial screen level they should lead to the calling program. The
function Cancel should issue a warning/ question if changes might be lost. The Exit function
leads back to the calling position of a program unit.

If the user entered data into the screen fields, predefined safety questions can be used to
prevent a loss of data. Such a loss can also appear if the user switches from the changing
mode to the display mode. Hence, the behavior should be similar to that of back in this case.
The proposed function modules to realize these safety questions (prompts) are:

 POPUP_TO_CONFIRM_STEP

 POPUP_TO_CONFIRM_WITH_VALUE

 POPUP_TO_CONFIRM_LOSS_OF_DATA

11.8.4 Menu bar

A menu contains at most 15 entries. These entries can be further menus (cascading menus),
functions or separator lines. Menus may have 3 levels at most. A menu bar may contain 8
menus at most. It is important to remember that two of them are already reserved for the
System and Help menus.

Menus can be created with static or dynamic text. The dynamic text is set at runtime by
reading a field that is assigned to the menu.

Menus can be loaded as include menus from other programs. This is done from the Menu
Painter using a context menu call. The program name and the corresponding status of that
program must be specified.

You can automatically generate the default menu structure in a menu using the button Display
Standards. This pattern can then be adapted to the individual requirements. Using the
standard is recommended to ensure the consistency of the user interface.

To create a menu, enter a text into an empty field and double-click on it.

Page 26
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 21: Example menu: SAP-System-Screenshot

After that, function codes and corresponding texts can be entered. If the function code is
already part of the function list with a corresponding text defined there, this text is loaded
automatically.
For a separator line, the context menu can be used, or the function field can be filled with
minus symbols. To create a sub menu, enter a text but no function code and double-click on
the text:

Figure 22: Example of a sub menu

11.9 Simple design elements

The screen layout is created using the Graphical Screen Painter. This is an additional tool of
SAP GUI for Windows. Non-windows-users have to use a simple Screen Painter that is not
supported by this document.

The screen layout consists of the menu bar, the standard toolbar, which may contain the disc
symbol to save or the arrow to go back, for example, the title bar and the application toolbar.
The bars (menu bar, etc.) are self-contained components of an ABAP program that are
assigned to a screen using a GUI status. They are edited in the menu painter.

In the main area of the Graphical Screen Painter, different elements can be positioned:
Checkboxes, radiobuttons, buttons, input fields, text fields (descriptions), as well as tabbed
areas, tables, and custom controls. At the bottom is a status bar in which messages appear,
which you already know from the discussion of the MESSAGE statement.

All screen elements have properties that can be set statically in the Graphical Screen Painter,
but some of them can also be changed at runtime. An example for this is the property of an
input field to be editable or not. This can be switched at runtime. In earlier sections it has been
explained how to do those dynamic changes using the SCREEN system table already.

By the definition of the screen elements of a screen, the fields of the flow logic of the dynpro
are also determined. They are automatically assigned to the screen elements. There is no
explicit data declaration required inside the dynpro source code. Besides the fields created by

Page 27
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

the user, there is always an additional OK-code field that is created by the system and is used
to handle the function code selected by the user. However, you may not forget to assign a
name to this field. Otherwise you will not receive a value in the OK code field on the ABAP
side, which is a very common error.

The data types of dynpro fields are defined by a reference to a flat data type of the ABAP
Dictionary or by using global fields of the ABAP Program.

In the following sections, some of the available screen elements are presented.

11.9.1 Text fields

Text fields are rectangular areas of the screen layout in which text (but also lines and icons)
can be displayed. They are used to describe other elements, for example, radiobuttons. Their
text cannot be changed at runtime. For this purpose, Inout/Output fields are used, which will
be presented later. However, internationalization is supported. Using the menu path Goto ->
Translation texts in other languages can be defined.

Multiple words in a text field are separated by underscore characters. Because of this, the
system recognizes that the words belong together to one text field. On the interface they are
displayed as space characters.

The attributes of text fields are

 General:
o Name
o Text
o Tooltip
o Position and length
o Modification groups
o Switch
o Context menu
 Dictionary
o From Dict.
 Program
o Right-justified
 Display
o Fixed font
o Bright (dynamically changeable)
o Invisible (dynamically changeable)
o As label on left
o As label on right
o Responds on double-click

The text of a text field can be determined manually in the Screen Painter, or it can be taken
over from the texts of a data element from the Dictionary. If structures are inserted from the
dictionary, usually, an input field and a text field are generated automatically.

Page 28
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

11.9.2 Status icons

For the visual display, icons can be used to indicate certain states, for example, a green or red
symbol for positive or negative states. For this purpose, status icons are placed on the screen
layout and have the role of a placeholder, which is filled with a suitable icon at runtime. Icons
require between 2 and 4 characters. If an icon shall have a tooltip, the field must be defined
with a greater length (the maximum length is 132), but a visible length of 2.

Have a look at the attributes of status icons in the Screen Painter. The attributes visible length,
bright, and invisible can be changed at runtime.

An overview of possible icons is provided by the program SHOWICON: (start it using

transaction code SA38)

Figure 23: Possible icons (selection): SAP-System-Screenshot

To load an icon into the screen field, a field with the same name must be defined in the ABAP
program. Type it as follows:

DATA: iconfield LIKE ICONS-TEXT.

This field is used to load the desired icon on the screen. For this purpose, the function
ICON_CREATE has to be used. It determines the technical name of the icon. The following
figure displays an example. Further information on the function module can be found in its
documentation.

Page 29
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 24: Filling status icons

11.9.3 Boxes

To give a structure to the set of elements on the screen, boxes can be used. The contained
screen elements can be identified based on the box in which they are placed.

Figure 25: An empty box: SAP-System-Screenshot

If a box does not contain any elements at runtime and the runtime compression attribute of the
screen is set, the box will not be displayed. However, usually a box on a screen should contain
elements.

Attributes of boxes are:

 General:
o Name
o Text
o Position and size
o Modification groups
o Switch
o Context menu
 Dictionary
o From dict.
 Program
o Output field
 Display
o Invisible
Page 30
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

The visible length and the visibility can be changed dynamically using the system table
SCREEN. To change the text of a box, the attribute output field must be set and an ABAP
field with the same name must be defined. The text is assigned to this field and the system
transports this text to the screen.

11.9.4 Input / Output fields

Input / output fields are rectangular areas of the screen, in which the user can enter data or
which are used by the system for the output of text or other data. A field can be an input and
output field. Using the attributes of the field, the editability can be controlled.

Figure 26: Input/Output field (here with value help): SAP-System-Screenshot

During input, multiple support functions can be offered to the user, e.g., consistency checks
(based on foreign keys or values of domains) for fields that have been defined by a reference
to a Dictionary field, automatic input checks based on the type (e.g., date fields can only be
filled with valid dates) or value helps.

Input / output fields are sometimes called templates.

The online help contains further information on input/ output fields. The corresponding path
is ABAP Workbench: Tools -> Screen Painter -> Graphical Layout Editor -> Overview
of Screen Layout -> Screen Elements.

Attributes of Input/Output fields are:

 General:
o Name
o Text (For numerical fields, a comma can be used as a thousands separator, a
dot as a decimal separator and a V for the sign.)
o Dropdown
o Position and size
o Modification groups
o Switch
o Context menu
 Dictionary:
o Format
o From dict.
o Conversion exit
o Search help (integration on screen level; however the integration in the
Dictionary itself is more common)
o Parameter ID
o SET / GET parameter
o Upper/Lower case
 Program:
o Input field
o Input possible/not possible/recommended/required
o Output field
o Output only

Page 31
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

o Poss. entries key (input help button)

o Right-justified
o Leading zeroes
o * Entry
o Without reset
o Without template
 Display:
o Fixed font
o Bright
o Invisible
o 2D display
o Responds to double-click
o BasicDirectionLTR (left-to-right)
o No BIDI filtering

The input/output field properties, dynamic size, mandatory field information, bright, invisible,
and 2D display can be changed dynamically at runtime.

The list above displays the variety of attributes that can be set for input/ output fields. The
availability of some of the attributes depends on the data type, for example, the specification
of leading zeroes would not make sense for a CHAR field. The attributes marked as being
dynamic can be changed at runtime using the system table SCREEN.

The access to the field content is performed by the definition of a global field in the ABAP
program using the DATA or the TABLES statement.

For input/ output fields, there are two ways to create them:

 By manually adding them to the screen layout in the Screen Painter

 By taking over elements of the ABAP Dictionary using the Dict / Program Fields
window, which can be made visible using the -button of the Graphical Screen
Painter.

Page 32
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 27: The window Dict. / Program Fields: SAP-System-Screenshot

During the process of taking over a dictionary element, the properties defined in the
dictionary are used for the configuration of the screen element if possible. If an element is
created manually, the length is determined by the number of underscore characters given in
the text attribute. For numerical fields, you can enter a dot as decimal separator, a comma as a
thousands separator or a V as the last character for the sign.

The window for the attribute maintenance is made visible using the -button.

Page 33
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 28: The attribute window: SAP-System-Screenshot

By setting the checkmarks in the displayed attribute window, input fields can be connected to
the SAP memory using GET/SET parameters. This is used to make earlier input available on
other screens for the same user and session, which saves time because the input does not have
to be typed twice (see next figure).

The parameter ID is received from the ABAP Dictionary for Dictionary elements.

Page 34
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 29: SET/GET parameters

11.9.5 Checkboxes / radiobuttons

Checkboxes enable the user to set a check mark. They are often used in groups. From one
group, usually arbitrarily many checkboxes may be activated by the user.

Attributes of checkboxes/ radiobuttons are:

 General:
o Name
o Text
o Icon Name
o Position and length
o Modification groups
o Switch
o Function code (for direct PAI processing after selection)
 Dictionary
o From Dict.
o Parameter ID
o GET / SET parameter
 Program
o Input field
o Right-justified
 Display
o Invisible
o As label on left

Page 35
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

The editability and visibility can be changed dynamically at runtime using the system table
SCREEN.

Checkboxes are created in the Screen Painter. In the ABAP code, a field with the same name
of type C with length 1 is required to access the value (activated = “X”).

Figure 30: Creating checkboxes and radiobuttons

If the event PAI should be released by choosing the field, the checkbox or radiobutton must
be assigned a function code in its attributes. This code can then be retrieved from the OK code
field. In a radiobutton group, the code needs to be assigned to only one button, and the system
automatically assigns it to the other radiobuttons of the group, too.

Radiobuttons also require a C field of length 1 on the ABAP side. They are also created in the
Screen Painter. As opposed to checkboxes, from a group of radiobuttons there is always
exactly one activated button. To define such a group, also use the Screen Painter: Select the
fields that should be grouped and choose the menu path Edit -> Grouping -> Radiobutton
Group -> Define

Page 36
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 31: Processing function codes

The figure above explains the processing using an example. Because of the assignment of a
function code, the selection of a field causes the PAI to be reached. There, in the example, the
OK code is checked to find out which event occurred. If the checkbox has been clicked, a
comparison with the initial value is performed, which is successful if the field is not checked.
For the radiobuttons, it would also be possible to use a CASE statement, especially if there are
many radiobuttons in the group. In this case, the CASE part would contain a constant literal
(‘X’) and the WHEN parts are variables. This might look a bit unfamiliar, because in many
other programming languages the order must be the other way around (a variable in the CASE
part and constants in the WHEN parts). ABAP is more flexible here and allows both.

Page 37
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

11.9.6 Pushbuttons

Pushbuttons are used to execute certain functions by the user. Hence, they always release the
PAI event, where the function code of the button can be retrieved from the OK code field. It is
recommended to choose the position of a pushbutton wisely, so the meaning of the pushbutton
is clearly visible to the user, and he can go to the pushbutton easily using the tab key after
filling the corresponding input fields. If, for example, a pushbutton is used to save only
certain fields on a larger screen, it is useful to insert the button it into the same box as these
corresponding elements. Pushbuttons are also used for dynamic changes of the screen, in a
similar way as you know from selection screens already.

The attributes of pushbuttons are:

 General:
o Name
o Text
o Icon name
o Tooltip
o Position and size
o Modification groups
o Switch
o Function code (mandatory here)
o Function type
 Dictionary
o From Dict.
 Program
o Output field
 Display
o Invisible

The dynamic attributes size (visible length), output, and invisible can be changed
dynamically at runtime using the system table SCREEN. To change the text on the button,
however, an ABAP field with the same name must be created. Furthermore, in the Screen
Painter the attribute output field must be activated. The text is then changed by modifying the
contents of the data object with the same name.

The attribute function type influences the behavior of the pushbutton: For function type ' '
(Space) the PAI is entered, for function type 'E', the module with the addition AT EXIT-
COMMAND is called (This addition is part of the module call in the screen flow logic, it does
not belong into the code of the module itself. It will be explained later).

Page 38
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

11.10 Statements of the screen flow logic

For input fields, it is recommended to implement value checks and to inform the user if
incorrect values have been entered using an error or warning message. For this purpose, the
screen flow logic has to be considered.

As explained before, the screen flow logic is not ABAP. It is a special set of statements,
which looks a bit like ABAP, but is something completely different. The flow logic is defined
in the Flow logic tab of a screen in the SAP GUI. Hence, you cannot use regular ABAP
statements at this place. However, it is possible – and a very common use case for screen flow
logic – to call ABAP modules from the screen flow logic. These ABAP modules themselves
are not part of the code on the flow logic tab, instead they are implemented separately in their
respective include files. Hence, do not try to use regular ABAP statements on the screen flow
logic tab.

The flow logic of screens has a limited set of statements. Some of the most important
statements are presented in this chapter.

11.10.1 Event blocks

Generally the flow logic of a screen is also divided into event blocks. There are four different
event blocks available in total for the screen flow logic5.

Figure 32: PBO and PAI

Two of them, the PBO and PAI, have been mentioned already:
PROCESS BEFORE OUTPUT.

The block initiated by this statement is executed by the system before the screen layout is
sent. After processing this block, the values of global fields of the ABAP program are
transported to fields of the screen that have identical names, and the screen is shown to the
user.

5
Cf. Keller and Krüger (2011, p. 517)
Page 39
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

PROCESS AFTER INPUT.

The PROCESS AFTER INPUT block is executed when the user performs an action that is
assigned to a function code. The contents of the dynpro fields are transported back to ABAP
fields with identical names. The screen layout stays visible as long as the PROCESS AFTER
INPUT block is being processed and next dynpro is not executed yet, but no further input is
possible. After this block, the PROCESS BEFORE OUTPUT event of the next dynpro is
reached (see figure above).
PROCESS ON HELP-REQUEST
PROCESS ON VALUE-REQUEST

These events are executed if the user calls the field help using the F1 key or the value help
using the F4 key.

11.10.2 The MODULE statement

The MODULE statement of the screen flow logic has the following syntax:

MODULE modulename additions.

Using this statement you can call a module that is implemented in ABAP. Here, in the PBO
only output modules and in the other event blocks only input modules can be called.
However, in practice you will most likely create modules using forward navigation, which
means that the module definition is created automatically and you will only insert the ABAP
code inside the module. Hence, the addition of input or output on the ABAP side is done
automatically.

The two most important additions are:

AT EXIT-COMMAND

ON {CHAIN-INPUT|CHAIN-REQUEST}

Both additions will be explained later in the context of the FIELD statement.

11.10.3 The FIELD statement

The FIELD statement has different purposes. Firstly, it can be used to control the data
transport between screen fields and global fields of the ABAP program in the PROCESS
AFTER INPUT. If the statement FIELD fieldname is used inside the PROCESS
AFTER INPUT, the data transport between dynpro and ABAP program is not carried out
before the PAI block; instead, it is performed at the time of processing this statement (hence
possibly after the processing of previously called ABAP modules!). Note that this is a
potential error source, which results in some empty fields even though the user entered data in
these fields.

However, the FIELD statement can also be used to create a simple value check for input/
output fields.

Page 40
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Important note: The syntax described here (and in the two sub sections below) is
obsolete. We only use it for didactic simplification, because the topic of proper value
help definitions has not yet been discussed. Do not use this syntax for exercises in later
chapters.

The syntax is6:

FIELD field { vlaue_list | db_query }.

The statement can be used in the PROCESS AFTER INPUT block and compares the field
field with a list of values or the result of a database query.

11.10.3.1 Comparison to a value list

The value list value_list has this syntax:

VALUES ([NOT] val1], [[NOT] val2], ...
[[NOT] BETWEEN vali AND valj], ...).

The comparison is possible either using a list of values or using value intervals. The NOT
negates the corresponding value. If a forbidden value is entered, an error message is displayed
and the corresponding field is made editable again.

11.10.3.2 Comparison to a database query

The syntax for db_query is:

SELECT *
FROM dbtab
WHERE col1 = f1 AND col2 = f2 ...
[WHENEVER [NOT] FOUND SEND {ERRORMESSAGE|WARNING} [num [WITH p1 ... p4]]
].

The SELECT-, FROM-, and WHERE part is similar to the syntax of the ABAP SELECT
statement you already know.

Depending whether the WHENEVER part is containing the NOT option or not, an error or
warning message is sent if (no) result has been found.

The screen field to which the FIELD statement is related is made editable again, so the input
mistake can be corrected.

Remember that this syntax is old-fashioned. Later you will learn how to define your own
search helps. The following sub chapters will teach you how to realize value checks in ABAP
modules, which is a modern approach for the same problem.

6
Keller (2012, p. 1502)
Page 41
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

11.10.4 Connection FIELD and MODULE

The MODULE statement of the screen flow logic can be used to call modules of the ABAP
program. The statement can be combined with the FIELD statement. In the simplest case, this
is done as follows:

FIELD fieldname MODULE check_input.

Here, an input check is implemented in an ABAP module called check_input. The

information about the field fieldname has the purpose to make the field fieldname
editable again if there is a problem with the input detected in the module, while the other
fields stay disabled. To indicate an error from the called ABAP module, it is sufficient to call
a suitable error message (a message of type E) from the ABAP module using the MESSAGE
statement that you already know from earlier sections.

Figure 33: Input check using an error message

11.10.5 Message types and corresponding screen behavior

You already know the message types (S, E, W, I, A, X). The following figure illustrates the
behavior of a program using screens, if one of the ABAP modules called in the PAI of the
screen releases a message of the respective type.

Page 42
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 34: Messages and screens

The behavior can be described as follows7:

 S Messages (Success / Status): The message is displayed in the status bar on the next
screen.
 E Messages (Error): The user must change his input to be able to leave the screen
 W Messages (Warning): The user can correct his input
 I Messages (Information): The processing is interrupted but can be continued using the
Enter key.
 A Messages (Termination): The message appears in a Pop-Up, processing stops; the
user has to start the transaction again.
 X Messages (Exit): A short dump (MESSAGE_TYPE_X) is displayed; the user has to
start the transaction again.

7
Cf. Keller and Krüger (2011, pp. 668 ff.)
Page 43
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Please note the semantics of the message types: It is, for example, not useful to send an S
message in case of a program error, even if the dialog behavior seems appropriate. S messages
are displayed with a green symbol, which indicates success, so the user of your program
would be confused probably.

11.10.6 The CHAIN statement

If an error message is released from an ABAP module assigned to a certain field on the screen
(i.e., the ABAP module is called in a FIELD…MODULE statement), all input fields except this
one are locked. If in case of an error multiple fields shall be made editable again, they have to
be included in a CHAIN block. Within the block, the input check is called using the
(standalone) MODULE statement.

The following figure illustrates the behavior:

Figure 35: The CHAIN statement

Please note that all fields would be locked if the module that releases the error message would
be called outside a Chain and outside a Field statement.

It is allowed to use multiple CHAIN blocks. Each field may appear in more than one CHAIN
block using a FIELD statement. Especially in these cases, you must be very careful not to
cause problems with the data transport. As explained above, the Field statements delay the
data transport, which may cause errors. In case of doubt, add simple Field statements at the
beginning of the PBO for the corresponding fields.

If an error or warning message is displayed, the screen is called again, but PBO is not
processed again (otherwise, the user input would be overwritten by defaults set in the PBO).

Page 44
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 36: Behavior after the input has been changed

The figure above shows the behavior if multiple field and chain statements are used and the
input is changed due to an error message. After the input is corrected, the whole PAI block is
not necessarily executed again. Instead, it is checked if the value of a field has been changed.
The system starts at the first relevant field statement. In the example shown above, the module
that is called in the first Field statement would be re-executed only if the user changed the
content of f2.

If there was a warning message only and the input has not been changed by the user, the
processing continues after the corresponding message statement. If an error or warning
message is released in a chain statement, the values of all fields of the chain are transported
back into the screen fields.

11.10.7 Conditional calls of modules

Some input checks are only relevant if the user entered anything into the corresponding field
at all. If an input check is called nevertheless, there is potentially an unnecessary database
access and the performance of the program as a whole is decreased. For this and similar cases,
there are conditional module calls. These are controlled by additions to the FIELD and
MODULE statements.

11.10.7.1 Execution if initial value changed

FIELD fieldname MODULE modulename ON INPUT.

This statement calls the module modulename only if the value of the field is different form
its initial value. The addition ON INPUT is only usable in combination with FIELD.

Page 45
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

11.10.7.2 Execution on repeated input

FIELD fieldname MODULE modulename ON REQUEST.

This statement calls the module modulename only if the value of the field has been
changed since PBO (including overwriting the same value)8. The addition ON REQUEST is
only possible in combination with FIELD.

11.10.7.3 Conditional calls of modules in chains

A similar addition is available for the calls of modules inside chains:

CHAIN.
FIELD: a, b, …
MODULE modulename { ON CHAIN-REQUEST | ON CHAIN-INPUT }.
ENDCHAIN

This statement calls the module modulname only if the value of at least one of the fields in
the chain has been changed by the user (ON CHAIN-REQUEST) or is different from the
initial value (ON CHAIN-INPUT).

11.10.7.4 Execution on exit functions

At most one module per PAI may have the addition AT EXIT-COMMAND (in the screen
flow logic):

MODULE exit AT EXIT-COMMAND.

Inside the module itself, there might be a code like this:

MODULE exit INPUT.

CASE ok_code:
WHEN 'CANCEL'.
CLEAR ok_code.
LEAVE TO SCREEN 0.
WHEN 'EXIT'.
LEAVE PROGRAM.
ENDCASE.
ENDMODULE.

This is a module that is called before the automatic input checks, and the automatic data
transport and all other PAI modules are processed. It is called if an exit function is called.
This is a function of type E. The type of a function can be assigned in the GUI status using the
Menu Painter:

8
Keller and Krüger (2011, p. 544)
Page 46
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 37: Exit function in the Menu Painter: SAP-System-Screenshot

The small window is opened by a double-click on the function, in the example a double click
on BACK. Calling the BACK function would now execute the module “exit” displayed
above, in which the program could be left, for example.

A definition like this is used to be able to leave a screen even if the input is not correct.

11.10.7.5 Switch dependent execution

Another possible addition for the MODULE statement is the definition of a switch:

MODULE modulename SWITCH switch.

A module, which is included like this, is only called if the switch is enabled. Switches are
defined in the Repository, but they are not discussed in this course.

11.11 Exercise: Designing user interfaces

In this exercise, you will apply the contents of the previous sections and create your first
application with screens using the Screen Painter. The application created here shall be able to
maintain flight connections. On a first screen, a flight connection shall be selected by the user.
The second screen shall display the detailed data of that flight. This data shall be editable and
changes should be written to the database.

11.11.1 Creating the program

Open the Object Navigator (transaction code SE80) and create a new program named
ZZ_####_FLEDIT, but this time choose a program with TOP include. You will then be
asked for the name of the top include, name it ZZ_####_FLEDIT_TOP by replacing the
default value ****TOP proposed by the system. In the next window, choose the program type
Module Pool and the usual status Test program.

Page 47
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 38: Program attributes: SAP-System-Screenshot

Save your input, use your usual package, and request. Also assign the top include to your
request.

In your top include, all variable declarations must be made, which are required in different
parts of the program. In this case, the first thing you need is a data object that represents the
flight connection which is currently displayed on the fields of your screens. As you know, a
data object on the ABAP side of the program must have the same name as the corresponding
screen field. However, it would be a lot of work to define data objects individually for each
attribute of a flight, which shall be displayed. To be able to access structures from the
dictionary, there is a more convenient way: Using the TABLES statement:
TABLES spfli.

This statement is normally obsolete, but is still used for screen programming to be able to
create such an interface work area and define corresponding fields in the Graphical Screen
Painter with a relation to the Data Dictionary conveniently, so fields and descriptions can be
taken over from there easily.

To interact with the database, for example for your SELECT statements, define a work area
wa_conn, typed using the database table for flight connections (SPFLI).

The third required definition is the field for the OK code. Such a field is necessary to
represent the value of the OK code, which is the function code that has been called by the user
on the screen. Theoretically, this field is already available as sy-ucomm, but it is a good
programming style to define a separate field, because a self-defined field is writable, which
can be used to remove earlier values from the field to prevent these old values from being
Page 48
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

transported to the next screen, causing unexpected behavior of the program 9. Call the variable
ok_code and type it using the existing system field, i.e., using LIKE and the field sy-
ucomm.

Your TOP include should now look like this:

Figure 39: Top include: SAP-System-Screenshot

Save the include.

11.11.2 Creating the first screen

In the next step, you will add the first screen to your program, which is the screen on which
the user will be able to select the flight connection. For this purpose, right-click on the name
of the program (ZZ_####_FLEDIT) in the navigation tree on the left side of the Object
Navigator and select Create -> Screen from the context menu. You will be asked for a
number for the screen. Choose number 100 and commit. Then add a suitable short description
for the screen and choose 200 as the Next Screen number. The screen 200 will be defined
later, and it will display the selected flight. By choosing a next screen, after committing the
current screen the system jumps to that screen. As you know, this static next screen can be
overwritten dynamically.

To be able do design the screen, you will now switch to the Graphical Screen Painter (please
note that this tool is only available on Windows systems; this exercise cannot be done with
the Java GUIs for Linux or Mac OS). You can start the Graphical Screen Painter using the
Layout button or using the menu path Goto->Layout. While the Graphical Screen Painter is
active, the SAP GUI window cannot be used.

9
Keller and Krüger (2011, p. 538)
Page 49
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

The screen shall consist of a headline, the input fields for the selection of the flight
connection, alongside with a description and a pushbutton to commit the action. Furthermore,
at first you will define the headline, which explains what to do to the user.

Now add a text field in the Graphical Screen Painter using the

-button. Select the desired size in the grey main area of the screen by drag-and-drop. You
will then see that the input field Text in the upper area of the window is red. This shall inform
you that the field is mandatory. Enter “Please select a connection.” into this field. After that,
the Name field gets red. Enter INFOTEXT there (the red background disappears after
selecting a different field).

Figure 40: Graphical Screen Painter after changing the text field: SAP-System-Screenshot

Below the button for adding text fields, you can see further buttons, which can be used to add
other elements do a screen. It is also possible to insert the input fields this way. However, in
the case at hand, there is a simpler way to do this. As you know, the flight connections are
represented in a dictionary structure. This structure can be reused here, including the
corresponding field labels, so the corresponding input fields and descriptive labels don’t have
to be created manually.

For this purpose, click on the icon Dict/Program Fields Window or press the F6 key.
Another window opens in which input fields and text fields can be added to the screen based
on Data Dictionary objects. Enter the table SPFLI into the field Table-/Field Name and click
on the Get from Dictionary button. Now, all fields of the table are listed. Fields added like
this are only accessible using the TABLES statement you already entered before.

Page 50
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 41: Dict/Program Fields window: SAP-System-Screenshot

On the input screen, only the required key fields for the selection of the flight shall be
displayed. Hence, select the lines for the fields CARRID and CONNID by clicking on the
empty buttons at the beginning of the lines (The MANDT field is not needed as it is
automatically supplied in Open SQL). The lines are now highlighted in blue. Now click on the
button with the green check mark on the bottom left of the window.

You can now place the fields on the screen using your mouse. The outline of the fields and
labels to be created are visible to support your choice.

Figure 42: Outline of the fields: SAP-System-Screenshot

After you have chosen a position by clicking on the screen, your screen should look like this:

Page 51
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 43: Graphical Screen Painter with the input fields: SAP-System-Screenshot

In the next step, the button to commit the input shall be added. Insert a corresponding element
using the button Pushbutton , enter the text “Select” and the name SELECTBTN. Make
sure it is placed below the input fields.

Despite the specification of text and name for the button, it is still incomplete, because the
function code is not defined yet. This is also the reason for the red color of the button. To be
able to specify the code, open the attributes window by clicking on or by pressing the F2
key. In this window, you find the function code field with the name FctCode. Enter SELECT
into this field. Commit your input using the Enter key.

To make the button actually work, another important specification is necessary. As you know,
the ok code shall be transported to a variable on the ABAP side. For this purpose it is
necessary that this variable has the same name as the corresponding screen field, as for all
other fields and variables. In the case of the OK code field, the name on the screen side must
be determined first. Leaving out this step is a common source of errors, which leads to
problems when the OK code shall be processed but the variable is empty. To define the name,
click on the button Element List Window or press the F7 key. A new window is
displayed, which contains another red field. Here, the name of the variable to store the OK
code is expected. Hence, enter the name of your variable ok_code here (see next figure; make
sure you do not mix up underscore and hyphen).

Page 52
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 44: Element list: SAP-System-Screenshot

Remember this step for later programs. It is a very common error source (symptom:
empty ok_code value in PAI processing)!

Save, check, and activate your screen. The system asks if you want to activate your program
and your top include, too. Select all entries to activate screen, program, and top include.

Leave the Graphical Screen Painter. Make sure that you do not only close one of the sub
windows of the Graphical Screen Painter. This would cause SAP GUI to not react to your
input.

Programs with screens are started by transactions. Hence, open the context menu (right click)
of your package in the navigation tree of the Object Navigator and select Create -> Other (1)
-> Transaction to create a transaction. Enter the name of your program ZZ_####_FLEDIT
as the Transaction code and choose a suitable Short text. The type of the Transaction (Start
object) shall be a dialog transaction.

Page 53
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 45: Creating a transaction: SAP-System-Screenshot

Using this transaction, the program and its screens can be started and tested. Enter
ZZ_####_FLEDIT into the Program field and 100 into the Screen number field. Also set
the check mark for SAPGUI for Windows and SAPGUI for Java in the GUI support
section (see figure).

Page 54
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 46: Attributes of the transaction: SAP-System-Screenshot

Save and test the transaction. You should see the screen you defined in the Graphical Screen
Painter before. The airline carrier field has a value help. The field for the flight connection
number has no value help. This depends on the configuration in the dictionary. You will learn
how to define your own tables with value helps in the Dictionary later. For this exercise, we
will use the above mentioned, obsolete syntax for simplification based on screen flow logic
commands.
If you click on the select-button during your test of the transaction, an exception occurs. This
happens because the next screen, screen 200, does not exist yet.

First, the problem of the missing value help shall be solved. There are many different ways to
attach a value help to a field, which will be explained later during this course. In the current
exercise, you will use the PROCESS ON HELP-REQUEST to realize the value help. The
required Code is already defined in the system, so you have to include it at the correct
position only.

Open the Object Navigator again and open screen 100 of your program ZZ_####_FLEDIT
again, using the navigation tree on the left. Open the tab Flow logic. This is the place where
the flow logic of the screen (non-ABAP-Code!) is defined. You can see the keywords for the
two predefined processing blocks PROCESS BEFORE OUTPUT and the PROCESS AFTER
INPUT.
Add the block and the statement like in the following figure:

Page 55
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 47: Screen flow logic: SAP-System-Screenshot

This way, the module value_request will be called as soon as the user presses the F4 key for
the spfli-connid field (this is the name of the connection field, as we defined it using the
dictionary structure). This module must be created. Use forward navigation to do this, i.e.,
double-click on value_request. Commit the creation by clicking on yes. The system
now asks for the include in which the code for the module shall be located. By default, a new
include is used. Keep this selection as shown in the following figure.

Figure 48: Creating the include: SAP-System-Screenshot

After you commit this window, you see a warning. This warning tells you that an include
statement will be added to the main program. Commit the warning, because it is of course
necessary to do this, as otherwise the new include would in fact not be included in the
program. Commit your request also as usual.

You can now see the new include, which contains an empty module. Here, the value help can
be implemented. This coding is quite complicated here, so we created the required code
already for you. You can simply use this code by adding the following INCLUDE statement
between MODULE and ENDMODULE:

Page 56
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

INCLUDE ZZ_VALUE_HELP_EXAMPLE.

Save and check, then activate your program. Test it by calling the transaction
ZZ_####_FLEDIT. Both fields have a value help now, which makes the usage of the
program more convenient. However, you can also see that there is no proper title and the back
button is greyed out:

Figure 49: Program with value help: SAP-System-Screenshot

11.11.3 Configuring GUI status and title bar

Go back to the Object Navigator (Transaction Code SE80), and open the first screen of your
program again.

It is usual that every program has a title and a status bar. Hence, the required code is already
prepared by the system and can be adapted to your needs simply. First you need a PBO
module, as the title and status bar must be set before the screen is sent to the user.
Uncomment the module call in the PROCESS BEFORE OUTPUT by removing the star in the
line MODULE STATUS_0100. Then double-click on STATUS_0100. The system asks if
you want to create the module. Commit this question with yes.

The system asks you for the include in which the module shall be created. For the clearness of
the program, use a new include – this should also be the default selection of the system, so
you just have to commit the selection proposed by the system (cf. following figure):

Page 57
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 50: Creating a module: SAP-System-Screenshot

Commit your input. The system will send a message that the new include will be added to
your program using an include statement (This statement is added to the main program. If you
want to see it, you can double-click on the program name in the navigation tree on the left at
any time). Save and choose your request if the system asks for it.
Now you see the module source code. This Code is written in ABAP, as opposed to the screen
flow logic code that you saw before. The screen flow logic calls Modules that are
implemented in ABAP and contain the actual program logic. Make sure you always know
whether you are in a screen flow logic or a module written in ABAP. As the syntax looks
quite similar, the difference is not always obvious for beginners.

As announced before, the code for setting a GUI status and a title bar is prepared already. It
consists of the two lines with SET statements. Uncomment them by removing the stars at the
beginning of the two lines and change the name of the PF status and the name of the title bar
to 100 (see the next figure).

Figure 51: Changed code of the include: SAP-System-Screenshot

Page 58
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

These two lines set the GUI status and the title bar. However, both must be created first.
Generally, this would be possible by right-clicking on the program name in the navigation tree
on the left and choosing Create->GUI Status and Create->GUI Titles, respectively, but
again there is a simpler way in SAP GUI using forward navigation: To create status 100,
double-click on the “100” of the PF status line. Commit the question of the system whether
the status should be created. Enter a suitable short description and continue. You now see a
list of possible settings of menu bar, application toolbar, and function keys. Expand the
Function Keys section. You see the icons of the standard toolbar and some recommended and
freely assignable keys. For each icon or keyboard shortcut, you can define a function code
that shall be sent to the program if the corresponding key/ button is pressed (OK code).
Assign the code BACK to the icon with the white arrow on the green ball (see next figure).

Figure 52: Defining function codes: SAP-System-Screenshot

Double-click on the Code BACK you just entered. This opens a new window, where you can
see some details about the function. The field Functional Type indicates that the function has
the type “ ” (Space), which means it is a normal application function. Later during this
exercise, you will have to change that type to an exit function code, so please keep in mind
how to open these settings!

Page 59
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 53: Function Attributes: SAP-System-Screenshot

Leave the function attribute window without making any changes. Save the GUI status and go
back to your PBO module.

After you have successfully created the GUI status, you will now create the title the same
way. Hence, click on the “100” behind TITLEBAR and commit the creation of the title. A
new dialog appears. In this dialog, choose a suitable title (cf. following figure). After that,
commit.

Figure 54: Create title: SAP-System-Screenshot

Save the screen and activate all inactive objects. Test your program again by calling its
transaction. The user interface now contains the title, and the back button is not greyed out
anymore:

Page 60
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 55: Changed user interface: SAP-System-Screenshot

Now you have finished the creation of the user interface of the first screen. Before you start to
create the second screen, which will be used to edit the flight connection, you must define
what should happen depending on the action of the user. This means you have to implement
the PAI logic.

11.11.4 Implementing the PAI logic of the first screen

As you already know, the PAI is the part of the screen flow logic, which is called after the
user has performed an action on the screen. On your first screen, there are two possible
actions: either the user clicks on the select button to open a flight connection, or he or she uses
the back button that you have implemented in your GUI status. These two cases must be
differentiated. For the implementation of the logic, you will create another ABAP module.
This module will be called by the screen flow logic simply. The creation can be done by
forward navigation, similar to the PBO. Hence, open the flow logic of your first screen and
add a line MODULE USER_COMMAND_0100 below PROCESS AFTER INPUT. This line
is already prepared by the system, so you can simply remove the star at the beginning of the
line. Note, however, that this is just a suggestion – in general, you may create arbitrary
modules with names of your choice. Double-click on USER_COMMAND_0100 to create the
module as you did in the PBO before. Commit the creation and also commit that an own, new
include shall be used for the new module (which should be the default selection as shown in
the following figure):

Page 61
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 56: Creating the module: SAP-System-Screenshot

Commit the warning of the system, that an include statement will be created, and commit to
save the screen. Also commit your request as usual.

You can now see the source code of the ABAP module USER_COMMAND_0100, which is
called by the screen flow logic in the PAI. There is only a frame of the MODULE and
ENDMODULE statements but no other code, because the system has no idea about the purpose
of the module. In the following paragraphs, the necessary code will be described. An example
will be shown in a figure afterwards, but we strongly recommend to try on your own first and
not just to copy code from the screen shot.

To differentiate the two possible actions of the user, a CASE statement should be used. This is
more clearly than an IF statement, especially if further possible actions shall be added at a
later stage of development. In your module, you must check the value of the ok_code variable
in the CASE statement. You have defined this variable in the TOP include of your program
earlier and you gave the OK code field of the screen the same name. Because of that name
identity, the function code of the user action will be stored in the variable and can be
processed here.

First, check the variable for the value 'SELECT'. If this function code is used, the flight
connection shall be read from the database table SPFLI into the work area wa_conn (which
you have defined in the TOP include). In the WHERE part of the database query you can
access the fields SPFLI-CARRID and SPFLI-CONNID. These are components of the
interface work area that has been defined in the TOP include using the TABLES statement.
These fields also receive their value due to the name identity between screen fields and ABAP
fields.

Add a second possibility to your CASE statement which handles the code 'BACK'. In the
case of 'BACK', the program shall be left. Use the LEAVE PROGRAM statement for this.

After the CASE statement, the ok_code variable should be reset using the CLEAR
statement. The reason for this is that the data transport between screen fields and ABAP fields
with identical names happens in both directions. Hence, the value of the ok code field would
be transported back to the corresponding screen field in the PBO of the second screen. This
Page 62
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

can lead to problems: If an empty function code is called on that second screen, that empty
value will not be transported and the ok code of the first screen will stay in the ok code field.
Hence, it is generally recommended to reset the OK code field in the PAI as early as possible.
In more complex modules, it is a common practice to store the value of the field in an
additional variable, which is used for the ok code processing throughout the rest of the
module, while resetting the original OK code field immediately.

The completed code can be seen in the following figure. We recommend trying to implement
the module without looking at the screenshot first!

Figure 57: Code of the module: SAP-System-Screenshot

Attention: The values of OK codes for comparison (like SELECT and BACK here) must
always be written in UPPERCASE letters. Otherwise the ok code processing will not work.
This is a common programming mistake!

Save and check, then activate all inactive objects. Add a breakpoint to the module
USER_COMMAND_0100 at the beginning of the CASE block by clicking on the statement and
on the stop icon above. By doing this, the debugger automatically starts and the correctness of
the screen can be tested even though the program is not yet complete. Call the program (using
its transaction) and click on the back button. You should be able to see the ok code value
BACK in the ok code field using the debugger. After that, leave the program.

Page 63
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

11.11.5 Creating the connection editing screen

So far, it is possible to use the back button on the first screen, but the button on the screen to
select the flight connection still leads to an error. This is because the next screen (screen 200)
has not yet been created. This is what you will do in this section.

Right-Click on the program name in the navigation tree on the left side of the Object
Navigator and choose Create->Screen from the menu. Choose screen number 200 and
commit. In the next dialog, enter a suitable short description and choose 100 as the next
screen. This makes sure that the connection selection screen appears after leaving the second
screen. After that, save your screen.

Now open the layout of the screen in the Graphical Screen Painter. Open the Dict./Program
Fields window by clicking on . Enter Table SPFLI and click on Get from Dictionary.
Select the first eight fields beginning after the client field (MANDT), i.e., the fields from
CARRID to AIRPTO. Commit and place the fields on the top left of the screen. Afterwards,
select the next seven fields (FLTIME to PERIOD) and place them right next to the already
positioned fields. The system will ask whether you want to convert the FLTYPE field into a
checkbox. Commit this request.

Figure 58: Field conversion: SAP-System-Screenshot

The fields CARRID and CONNID are part of the primary key of the table SPFLI. Hence, it
should not be possible to change their values. To define this property, select the
corresponding field, use to open the attribute window and select the Program tab in the
Attributes section. There, choose not possible from the Input drop-down field (see
following figure). This must be done for the two fields separately. Save your screen.

Page 64
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 59: Disabling input: SAP-System-Screenshot

Your screen should now look like this:

Figure 60: Screen layout: SAP-System-Screenshot

Also for this screen, you must define the name of the OK code field. Hence, open the element
window and proceed like you did on the first screen. The name must also be ok_code. Note:
The scroll bar of the element list window is far on the right.

Save the new screen and leave the Graphical Screen Painter. You have now finished the
layout definition of the editing screen, but the logic is still missing.

11.11.6 Configuring GUI status and titlebar for the second screen

Open the flow logic of the second screen. Now this screen shall be provided with a GUI status
and a title. This will be done like for the first screen.

Page 65
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Hence, also add a module call to the process before output of this screen. Again you can use
the predefined code by removing the star at the beginning of the line. To create the module,
double-click on the module name STATUS_0200. Make sure the module is created in a new
include:

Figure 61: Setting the include name: SAP-System-Screenshot

Commit the usual system requests.

In this screen, you need three different functions. First of all, similar to the first screen, there
shall be a back function, which will lead back to the first screen later. This function shall be
named BACK again and use the green arrow. To make it possible to leave the program
directly from the second screen, add another function code LEAVE to the yellow arrow.
Finally, you also need a function code for saving the modified flight connection. Theoretically
it would also be possible to create a button on the screen itself for this purpose, but a
corresponding function key is already prepared and for reasons of ergonomics this function
key should be used. Hence, define the code SAVE for this function key (see figure).

Figure 62: Setting function codes (OK codes): SAP-System-Screenshot

Save the status and go back to the module STATUS_0200. As known from the first screen,
define a suitable title for this screen by double-clicking on the name 200 in the line that loads
the title.

Page 66
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

In the next step you must make sure that the data of the flight that shall be edited are loaded
into the screen fields. This may appear confusing for a second, because you have loaded the
data from the data base already, and there is an automatic data transport between ABAP and
screen fields. However, in the PAI of the first screen you have loaded the data into your work
area wa_conn, which does not have the same name as the screen fields. Hence, you must copy
the content of this work area to the interface work area spfli (the one defined by the TABLES
statement in the TOP include). From that interface work area, it will be transported to the
screen fields which have the same name by the system. The statement to copy the data is
simple, as both work areas have the same type. The resulting code should look like this:

Figure 63: Source code with the assignment: SAP-System-Screenshot

Save the include and activate all inactive objects.

Start the program using the transaction. Enter Airline AA and flight 0017 and commit. You
will now see that the data of the flight connection is properly displayed on the second screen
of your program:

Page 67
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 64: Data on the second screen: SAP-System-Screenshot

You will notice that it is possible to go back to the first screen using the green arrow or F3
(the back function). This may be surprising as the PAI logic has not been implemented yet.
The reason is simply that screen 200 is configured to have screen 100 as its next screen. As
there is no PAI logic yet, all actions lead to screen 100 automatically. The PAI logic must be
implemented in the next step of the exercise.

11.11.7 Implementing the PAI logic of the second screen

Now go back to your screen 200 and open the flow logic. Add a module call in the PAI
section. Again you can use the predefined call by simply removing the star at the beginning of
the line. Create the module by forward navigation, i.e., double-click on its name. The module
shall be created in a new include as usual:

Figure 65: Selecting the include name: SAP-System-Screenshot

Commit the questions of the systems as usual.

Page 68
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

In this module, another CASE statement is required. It must contain three possible cases for
the value of the ok_code variable: In the case of 'BACK', nothing has to be done, because
the next screen number is already set to 100. Alternatively, you could execute LEAVE TO
SCREEN 100 here. 'LEAVE' shall lead to the execution of LEAVE PROGRAM.

In case of the value 'SAVE', the data must be written into the data base. It should first be
checked if the user changed the values (if not, no data base access is required). This can be
done by comparing the spfli structure (which contains the field values entered by the user)
to the data in wa_conn, which is the original state read from the data base before. If the
structures differ, the values from the screen have to be written to the database table. Use the
MODIFY statement for this.

After the CASE block, the ok_code variable needs to be reset. If you added an explicit call
of LEAVE TO SCREEN 100 in the 'BACK' case, the reset must be added there, too,
because otherwise the screen could be left before the ok code has been reset. Alternatively,
you could also define an auxiliary variable, into which you copy the value of the OK code
right at the beginning. Then you could reset the ok code immediately and continue processing
with the copied value in the auxiliary variable.

The source code should now look like this:

Figure 66: Completed source code: SAP-System-Screenshot

Note again that the values of the OK code must be specified in uppercase letters. Otherwise
the comparisons will fail.
The MODIFY statement might appear a bit confusing, because it contains spfli two times.
However, this is correct. On the left side of FROM, the statement expects the name of the
database table, which is spfli. On the right side, a work area is expected. This must be the
interface work area, which is also named spfli. You may not use wa_conn here, because that
work area only contains the unmodified version of the record from the database, and not the
version that has been changed by the user.
Page 69
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Save, check, activate, and test the program another time. Open flight connection AA 0017
again. Change the value of the distance field and save the connection. After that, open the
same connection again and check that your change has been saved. Now undo the change and
save the connection again.

11.11.8 Adding messages

A deficiency of the program is that there are no messages yet. Extend your program by a
suitable message after the selection of the flight. Specify the name of the message class in the
PROGRAM statement of the top include. Then send a message (using the MESSAGE
statement) of type S after successful selection of a flight.

Another important aspect that must be changed is the behavior if a flight is selected that does
not exist. Currently, an empty second screen is displayed. Change your program so that a
message is displayed on the first screen and the value can be changed in this case. The result
should look like this:

Figure 67: Error message for wrong connections: SAP-System-Screenshot

Page 70
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

11.11.9 Keeping fields enabled and leaving despite wrong input

As you can see in the figure above, the error message has the consequence that both input
fields are disabled and the user cannot change his incorrect input anymore. Now, change your
program to make sure that both fields – the airline and the flight number – can still be
changed if there is an error message.

To do this, add a CHAIN statement in the screen flow logic. Within that CHAIN, you must
add FIELD statements for the two input fields that shall be enabled again, and the MODULE
statement that calls the module in which the Error message is called must also be moved into
the CHAIN. In case of doubt, have a look at the explanation of the CHAIN statement in the
theoretical parts.

Save, check, and activate your screen. Test the application again, using a valid Airline, but an
invalid flight number, e.g., AA 1234. If the chain is implemented correctly, there should still
be your error message, but both fields should be still enabled. Also test if loading a correct
flight connection is still working, e.g., using AA 0017.

Now there is still another problem in the user interface which should be fixed. If you enter an
invalid Airline, e.g., XY, you receive a system-defined error message, which is based on the
SCARR table. The problem with this message is that it is independent of the OK code. Hence,
the screen cannot be left using F3 or the back button without changing the field value. Make
sure that the screen can be left using back (F3) even though there is wrong input, without a
message blocking the user action.

For this task, you will need two things which you should know from the theoretical parts:
 The function code, which is used for the back function, must be configured to be an
exit function code. This is done in the GUI status and does not mean to rename the
function. Instead you must double-click on the function code in the gui status and
change its function type in the window that appears.
 A module that is called with the addition AT EXIT-COMMAND, in which the leaving
is implemented. You can choose any name for that module and create it by double-
clicking on it. It should contain a check of the ok code (function code) value.

Test the success by entering an invalid airline and pressing F3. It should now still be possible
to leave the program without an error message. Also test clicking on select after entering an
invalid flight number. An error message should appear, which cannot be skipped, and both
input fields should still be enabled.

Page 71
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

11.12 Complex design elements

So far you have seen a variety of design elements for screens already. Now you will get to
know some additional, more complex design elements which use subscreens for an improved
user interface.

11.12.1 Subscreens

Subscreens are special screens that are defined to be included in other screens. For this
purpose, the surrounding screen must contain a subscreen area. Subscreens are loaded into
subscreen areas at runtime. The loaded screen can be changed dynamically.

Fields of application for subscreens are, e.g.:

 A group of input fields in a screen shall be faded in/out or replaced

 A group of input fields shall be included into multiple screens (for the purpose of
reusability/ maintenance)

Subscreens are created like regular screens, but in their attributes they are marked as
subscreens in a radio button group in their attributes. A screen which is marked as a subscreen
there must respect some special requirements. A subscreen may not contain an OK code field
for example, because the function processing is a task of the surrounding regular screen.
Accordingly, its screen flow logic may not contain any module with the addition AT EXIT-
COMMAND. Within the modules, it is not possible to set a title bar, a GUI status, or to change
the screen sequence, because all this is done on the level of the regular screen. Because of the
tight integration, names must be unique across all subscreens.

On one screen, multiple subscreen areas can be defined. Similarly, a subscreen can be used on
multiple screens.

Subscreen areas are defined in the Graphical Screen Painter.

Page 72
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 68: Loading a subscreen into a subscreen area

The figure above shows how a subscreen is loaded into a subscreen area. The dashed lines are
only used for illustration purposes; they are not visible on SAP GUI. The subscreen
integration is seamless. Hence, the user cannot see that the currently displayed screen contains
a subscreen.

If the subscreen is larger than the subscreen area into which it is loaded, only those elements
are visible that fit into the screen area, measured from the top left corner. By setting a
scrollbar attribute for the subscreen area, this behavior can be changed to make scroll bars
visible. To prevent unnecessary scroll bars, it is strongly recommended to place the elements
on the included subscreen in its top left corner. Otherwise, you would waste space.

The attributes of subscreens, set in the screen painter, are:

 General:
o Name
o Position
o Size
o Switch
 Specific:
o Scrollable
o Resizing vertical/horizontal
o Min Lines / Min. Columns

The resize ability influences the behavior when the window is resized. If it is set, the area can
be adapted to the window size. By defining a minimum size (Min Lines/ Min Columns
attributes), it can be prevented that the subscreen area becomes too small.

Output fields on subscreens can be assigned a common context menu.

To use a subscreen, it has to be called in the PBO and PAI of the surrounding screen. This is
done with the CALL SUBSCREEN statement of the screen flow logic, which is used like this:

Page 73
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

PROCESS BEFORE OUTPUT.

CALL SUBSCREEN area INCLUDING programname screen.
PROCESS AFTER INPUT.
CALL SUBSCREEN area.

The information in the INCLUDING addition (which is only used in the PBO) informs the
program which subscreen (screen number of the subscreen) from which program shall be
included. If the subscreen is defined in the same program, the system field sy-cprog can be
used to select this name, which is stored in the system variable. The screen number can be
given as a variable, too. This way, a dynamic selection of the subscreen to be loaded is
possible. The variable can be typed based on the system field sy-dynnr.

CALL SUBSCREEN is neither allowed inside CHAIN statements nor inside LOOP statements
(here, a loop construct of the screen flow logic is meant, which is not covered in the course).

The CALL SUBSCREEN statement leads to the execution of the PBO or PAI of the
subscreens, respectively, as shown in the figure:

Figure 69: Subscreen call including PBO / PAI

It is also allowed not to load a subscreen into a subscreen area. In this case, the subscreen area
simply stays empty. There is no error in this case. Such a situation can be used for optional
enhancements of screens.

Page 74
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

The figure shows how global fields of the ABAP program can be used. Within a program,
only these are accessible. It becomes more problematic for Subscreens that are used across
different programs.

Figure 70: Subscreens and data transport

If subscreens that are defined outside the program shall be included, no access to the data is
possible and hence no data transport is possible. Instead, subscreens can be defined inside
function groups. Function groups may contain global data objects, which are then used for the
data transport. To access the data, function modules are defined inside the function group.

Page 75
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 71: Data transport to subscreens in function groups

The subscreens are able to access the global data of the function group. To be able to access
this data from the main program, function modules are defined, which can access the global
data of the function group and can provide this data to the main program.

The figure shows the order of calls for the data transport: In the PBO, the data is first exported
to the function group, and then the subscreen (from the same function group) is called. The
data is then available there. In the PAI, the order is the other way around: First, the subscreen
is called. After that, the (possibly changed) data is taken back.

Within function SEND_DATA, the data must be written into global fields of the function
group. In function GET_DATA, they have to be read from these global fields and returned to
the caller.

11.12.2 Tabstrips

Tabstrips have already been discussed in the chapter about selection screens. Also, on
individually designed screens, these easily usable visualization elements can be used to
display a lot of information in a sophisticated way on one screen. As a consequence, multiple
screens can be reduced or even unified to one single screen. Especially if an operation is
processed over multiple screens until it is finished, a tabstrip is a better solution than a long
chain of screens.

Page 76
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Tabstrips are useful:

 If you want do display a lot of information, which would otherwise lead to a confusing
screen
 If you want to avoid long chains of screens
 If you want to combine logical groups of screen element, but there is not enough space
for boxes

Tabstrips should not be used

 If the order in which the user accesses the tabs is not arbitrary, i.e., if a fixed call order
is necessary,
 If the environment of the tabstrip has to be changed for the call of certain tabs (e.g.,
hiding or un-hiding of screen elements depending on the selected tab),
 Or if the entering of data on one tab lets other tabs appear.

Tabstrips have the following attributes:

 General:
o Name
o Position / size
 Specific:
o Number of tabs
o Resizing Vertical/Horizontal
o Min. Lines / Columns

The specification of the size and resizing properties is meant in a similar way as for subscreen
areas explained before.

The individual tabs are based on the concept of subscreens, which you have learned about in
the previous section of this chapter. Each tab hence contains a subscreen area, which is used
to display screen elements on it. However, it is possible to use the same subscreen area for
multiple tabs. To do this, the corresponding tabs must be selected together in the Screen
Painter and then the subscreen area must be created. Another possibility is to set the Ref.
Field attribute of the tab, which contains the name of the subscreen which belongs to that tab.
Furthermore, each tab has a label on top to select it, of course. This is simply implemented as
a push button. By default, each tabstrip contains two tabs. To add further tabs, you just have
to add further push buttons next to the existing ones on the tab strip. The properties of the
push button determine the behavior of the tab strip, i.e., if the choice of a tab raises the PAI
event or not. The following figure shows the general structure. Please note that it is possible
to make tabs invisible by setting the ACTIVE attribute in the SCREEN system table to the
value 0.

Page 77
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 72: Technical structure of a tab

If not all tab titles fit to the width of the tabstrip, a pushbutton appears in the top right corner
of the tabstrip that can be used to display a vertical list of the other tabs. Furthermore, arrows
are displayed which can be used for scrolling.

To create a tabstrip on a screen, the following steps are necessary:

 Create a tabstrip control in the Graphical Screen Painter first (using ).
 Then add the tabs. Additional tabs are added using pushbuttons and placing
them on the tabstrip. The pushbutton has a function code, whose function type
determines the behavior:
o Function type P: Enables to scroll between the tabs without triggering the PAI
event
o Function type “ “ (space): Clicking on one of the tab labels triggers the PAI
event
o The two possible function types and their associated behavior will be explained
in more detail in the following subsections.

 Assign a subscreen area to teach tab. Alternatively, the assignment to multiple

tabs can also be done by entering the name of an existing subscreen area into the Ref.
Field attribute of another tab.

On the ABAP side, each tabstrip is assigned to a field that has to be defined with the
CONTROLS statement:

CONTROLS my_tab_strip TYPE TABSTRIP.

The type TABSTRIP is a structure type (defined in the type pool CXTAB), which has the
most important attribute ACTIVETAB. In this attribute, the function code, which is assigned
to the tab label of the currently visible tab, is stored.

As an alternative to the manual creation of the tabstrip, you can also use the Tabstrip Control
Wizard from the Screen Painter. This wizard guides you step-by-step through the
definition of the tabstrip by asking for the name of the tabstrip, the type of scrolling, the
names of the tabs, function codes, and includes. All the necessary objects can be created
conveniently this way.

Page 78
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 73: Tabstrip Control Wizard: SAP-System-Screenshot

11.12.2.1 Tabstrip scrolling without PAI

To be able to scroll between tabs without triggering the PAI event, all tab titles of the tabstrip
must have function type P. Also, all tabs must have different subscreen areas and all
subscreens of the tabs must be sent to the front-end when the surrounding screen is loaded.

Page 79
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 74: Tabstrips without PAI

If the surrounding screen is submitted, all field check of the individual subscreens are
executed as if it were one big screen. At PBO and PAI if the main screen, all subscreens are
called.

PROCESS BEFORE OUTPUT.

CALL SUBSCREEN subs1 INCLUDING …

CALL SUBSCREEN subs2 INCLUDING …

PROCESS AFTER INPUT.

CALL SUBSCREEN subs1.

CALL SUBSCREEN subs2.

11.12.2.2 Tabstrip scrolling with PAI

If tabstrip scrolling with PAI shall be used, no separate subscreens have to be defined for the
individual tabs. The program determines which subscreen has to be loaded into the (single)
subscreen area based on the function code value from the tab title selection.

For this purpose, function type “ “ (space) is chosen for the tab titles. Hence, PAI is triggered.
In the PAI, the page to be displayed is determined using the function code. In the following
PBO, the corresponding subscreen is included.

Page 80
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 75: Tabstrips with PAI

In the code, there is only one CALL SUBSCREEN statement that contains a variable with the
screen number to be loaded. In the field activetab of the tabstrip, the function code can be
buffered which is then used in the following PBO to load the desired subscreen. For this
purpose, a PBO module is required that sets the screen number based on the function code
before the CALL SUBSCREEN statement is executed. Do not forget to set an initial value to
make sure the tabstrip is not empty at the time of program start.

The following figure shows a code example.

Page 81
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 76: Implementation of PAI scrolling

11.12.3 Exercise: Tabstrips and subscreens

In this exercise, you will create a program that is able to display customer data. The address
data shall be separated from other data on the screen.

First create a new program ZZ_####_SUBS (with Top include). Enter the name
ZZ_####_SUBS_TOP for the top include.

The program shall display contents of the SCUSTOM table. Therefore, create an interface
work area for this table using the TABLES statement.

TABLES SCUSTOM.

Save the top include and create screen 100.

Page 82
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 77: Creating screen 100: SAP-System-Screenshot

Add a suitable short description, check, and save the screen. Then click on to start
designing the screen layout. Open the Dict./Program Fields window by clicking on .
Enter the table name SCUSTOM and click on Get from Dictionary. Select the ID line only
and commit using .

Figure 78: Selecting the line: SAP-System-Screenshot

Place the ID in the upper part of the screen:

Figure 79: Positioning the ID: SAP-System-Screenshot

In the next step, the tabstrip shall be created. Add a tabstrip control by clicking on and
selecting an area of the screen.

Choose MY_TAB_STRIP as the name. Then, choose the tab title Tab1 on the screen and give
it the name ADDRESS using the attribute window (which is made visible by the -button)
and enter the title Address and the function code FC1. Then choose the second tab, give it the
name DETAILS, the title Details, and function code FC2.

Page 83
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Select both tab titles now (by holding shift and clicking on the tab titles) and create a
subscreen area using and selecting an area that fills the whole space on the tabs. Name
this subscreen area SUBS1 and make sure it is entered in both tabs into the reference field
attribute.

Finally, add a pushbutton next to the input field. It shall be called DISPLAY and have the
Text Display and function code DSP. Save and check the screen.

Then call the element list window (make it visible with ) and select the name ok_code for
the OK code field.

Save and check the screen.

Figure 80: Screen 100: SAP-System-Screenshot

Now, create screen 101, which shall contain the address data. Add a suitable short description
and select the screen type Subscreen.

Figure 81: Screen type: SAP-System-Screenshot

Open the layout of screen 101. As before, use Dict./Program fields to add some fields from
the database table:

Page 84
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 82: Fields on screen 101: SAP-System-Screenshot

Change the attributes of the input fields by disabling the checkbox Input Field in the program
tab of the attribute window.

Then create a similar subscreen with the number 102, which should only be different
concerning the choice of fields. Choose CUSTTYPE, DISCOUNT, and LANGU here. You
will see this question:

Figure 83: Question about field conversion: SAP-System-Screenshot

Choose Do not Convert here to keep the field as a normal input/output field. Remove the
input property as for screen 101.

Figure 84: Screen 102: SAP-System-Screenshot

Save, check, and leave the screen.

Open the top include and add declarations for a work area wa, the OK code field ok_code,
a field for the screen number snum, and the CONTROLS statement for the tabstrip.

Your code could look like this (after the TABLES statement) now:

Page 85
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

DATA: wa TYPE SCUSTOM,

ok_code LIKE sy-ucomm,
snum LIKE sy-dynnr.
CONTROLS my_tab_strip TYPE TABSTRIP.

Save the top include and open the flow logic of screen 100. Uncomment the proposed module
USER_COMMAND_0100 in the PAI area, save, and create the module using forward
navigation (double-click). Make sure a name starting with ZZ_ is used:

Figure 85: Include selection: SAP-System-Screenshot

Commit the message about the include statement being inserted.

Add code to process the OK code now. On FC1 / FC2 the activetab attribute of the
tabstrip shall be set, on DSP a customer shall be read from the database. After that, the OK
code must be reset. A possible solution is:

CASE ok_code.
WHEN 'FC1' OR 'FC2'.
my_tab_strip-activetab = ok_code.
WHEN 'DSP'.
SELECT SINGLE * FROM scustom INTO wa WHERE id = scustom-id.
ENDCASE.
CLEAR ok_code.

Save and check the code, then go back to the flow logic of screen 100. Uncomment the
corresponding call and create the proposed PBO module STATUS_0100 by removing the
star and double-click on the name. The include name must also start with ZZ_.

In the PBO module, depending on the value of the activtab attribute of the tabstrips, the
screen number has to be set in snum. Furthermore the content of the work area wa, which
contains the data read from the database table, must be given back to the interface work area
scustom here:

Page 86
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

CASE my_tab_strip-activetab.
WHEN 'FC1'.
snum = '0101'.
WHEN 'FC2'.
snum = '0102'.
WHEN OTHERS.
snum = '0101'.
my_tab_strip-activetab = 'FC1'.
ENDCASE.
scustom = wa.

To make sure the subscreen with the selected screen number is actually loaded into the
subscreen area SUBS1, save, check, and go back to the flow logic of screen 100. Add a CALL
SUBSCREEN statement after the module call.

CALL SUBSCREEN SUBS1 INCLUDING SY-CPROG snum.

Add to the PAI before the module call:

CALL SUBSCREEN SUBS1.

Now only a function to leave the program is missing. To add one, open the module
STATUS_0100 and uncomment the SET PF-STATUS statement. Change the xxxxx into
STANDARD. Save, check, and create the status by forward navigation (double-click on
STANDARD). Add a suitable short description.

Open the function keys section and add the function code BACK as in the following figure.

Figure 86: Add a function code: SAP-System-Screenshot

Save and open the PAI module USER_COMMAND_0100 again. Add a corresponding element
to the CASE block, e.g., as follows:

WHEN 'BACK'.
LEAVE PROGRAM.

Save and check. Now activate all inactive elements.

After that, create a (dialog) transaction ZZ_####_SUBS. Choose the program name
ZZ_####_SUBS, Screen number 100 and activate the GUI support. Save and test the
transaction. Your program should look similar to this screen shot (there, 18 is already entered
and committed):

Page 87
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 87: Testing the program: SAP-System-Screenshot

Page 88
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

11.13 Chapter Submission

You are now at the end of this part of the course. Please consider the following things before
you send the e-mail described below:

o Make sure you did all exercises, including those that are not part of a chapter
explicitly named “exercise.”

o Make sure all your repository objects are working correctly

o Make sure all your repository objects are activated. To find objects which are
not yet activated, select Inactive Objects from the drop down menu above the
navigation tree in the Object Navigator. Enter your user name USER#-### into
the field below and commit. After that, the inactive objects are displayed in the
navigation tree. Activate them now. Please note that you may have to expand
the branches of the navigation trees completely. To get back to your package
afterwards, select Package from the drop down menu and commit your
package name by clicking on the Display button.

o Make sure the names of your repository objects are exactly the same as
described in this document. If you mistyped a program name, right-click on it
in the navigation tree of the Object Navigator and select Rename… from the
menu.

These notes are also relevant for all following chapters.

If you completed the course so far, send an e-mail to your tutor using the subject
“ABAP: Finished Chapter 11 User ####” (The quotes are not part of the subject). You
will then receive feedback: Either in the progress report if everything was correct, or by e-
mail, if you have to correct something. Make sure that you enter the subject exactly as
described above to ensure an efficient processing of your e-mail.

If you have any questions, please use a separate e-mail because the e-mails used for finished
chapters are usually only processed based on their subjects and no contents are read.

Page 89
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

12 Further concepts

12.1 Number ranges

If you already have some experience with database systems, you will know tables that contain
“auto increment” columns. These columns are used to assign a new value for the primary key
automatically when a new record is inserted into the table.

An example could be a table of articles, consisting of article number (primary key),

description, price, etc.

If now a new article shall be added to the table, the value of the article number column would
be determined automatically by incrementing the last or the maximum key value by one. Like
this, the user or the developer does not care for the selection of a unique number.

In SAP ERP, the concept to solve this problem is different. There are no auto increment
columns. Instead, number ranges are created. A number range maintains the numbers for a
certain field of application and is more powerful than a simple incrementing variable. To
demonstrate this, you will now create your own number range.

Number ranges use domains for the definition of numbers. Open the Data Dictionary. Create a
new domain named ZZ_####_NDOM. Add as suitable short description and chose the data
type NUMC. Choose a suitable number of characters and commit this field with the Enter
key. The output length is entered automatically (see the following figure).

Page 90
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 88: Maintain domain: SAP-System-Screenshot

Save, check, and activate the domain. Use your package and request as usual.

For the maintenance of number ranges, choose the menu path Tools -> ABAP Workbench ->
Development -> Other Tools -> Number ranges or use transaction code SNRO.

Choose the Object name ZZ_####_NR and click on the create button. Choose a suitable
short text and a suitable long text to describe your number range. Then enter the domain you
created before (ZZ_####_NDOM) as the Number length domain and select 90 for the field
Warning %. Save (accept the buffering warning) and click on the new button Number
Ranges. Then click on . Here, multiple intervals can be defined from
which the numbers shall be chosen. Create an interval with number 1, which assigns numbers
between 1 and a high number, e.g., 99999 – depending on the number of character in your
domain. Make sure the checkmark in the ext column is not set. Commit (Enter key), save,
and accept all occurring questions.

To receive a number from your number range object, use the predefined function module
NUMBER_GET_NEXT from function group SNR3. Open the Object Navigator. From the
drop down menu on the left, choose Function Group and enter SNR3 in the field below.
Commit with Enter and navigate to the function module NUMBER_GET_NEXT in the tree
below. Open it by double-clicking. As it is a predefined function module in the SAP
namespace, you cannot edit it, but you can test it. For this purpose, click on the corresponding
button or press the F8 key. An input mask is displayed where the parameters of the function
module can be filled with values. Choose your number range object ZZ_####_NR for the
OBJECT field and the number (1) of your number interval for the NR_RANGE_NR field
(see figure).
Page 91
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 89: Testing the function module: SAP-System-Screenshot

Commit using the F8 key. The function module is now tested with the data entered into the
mask. The results are printed to the screen. If you go back using the F3 key multiple times
and commit using the F8 key again each time, you can see how a new number is generated
each time. An example output is shown in the next figure.

Page 92
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 90: Result of the test: SAP-System-Screenshot

In the next part of the exercise, you will learn how to use the number range in a program. For
this purpose, create a new program ZZ_####_NRTEST with no top include.

Define a variable of type I in which a number shall be stored.

Then, call the function module NUMBER_GET_NEXT, as you learned it earlier in this
course in the chapter about modularization. The parameters exported to the function module
are nr_range_nr with the value '1' of your interval and object with the name of your
number range object, while number is imported from the function module.

Add a WRITE statement (chained statement) that outputs the determined number. Save,
check, activate, and test your program. The output could look like this:

Figure 91: Output: SAP-System-Screenshot

Page 93
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

12.2 Calling programs

Programs cannot only be called manually using SAP GUI, but also using statements in the
program code. This makes it possible to start programs out of other programs. The statements
differ, depending on the program being executable or requiring a transaction. Both
possibilities are presented here.

12.2.1 Calling executable programs

Executable programs are called using the SUBMIT statement. Its syntax is:

SUBMIT {prog|(prog_variable)} [additions] [AND RETURN]

The program to be called can be provided statically as prog or dynamically by using a

braced variable like prog_variable in the diagram that contains the program name at
runtime.

The possible additions are manifold. In the following descriptions the most important ones
will be explained.

Variants
...USING SELECTION-SET variant...

Using this addition, the selection screen of the program is filled using the given variant
variant.

Selection Screen

…USING SELECTION-SCREEN number…

This addition can be used to specify which of the selection screens defined in the called
program should be used.

Selection screen display

…VIA SELECTION-SCREEN…

This addition can be used to display the selection screen of the called program to the user. If it
is not used, the selection screen is automatically submitted and not shown to the user.

Specification of individual values

…WITH expression…

Using this addition, it is also possible to specify individual values for the selections. For the
syntax of the expression, have a look at the keyword documentation.

The addition AND RETURN determines if the calling program should be continued or not. If
the addition is used, the called program is just inserted into the program flow, and after it is
Page 94
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

finished, the calling program is continued at the same point. If the addition is not used, the
calling program is left at this point. This also has an effect on the memory management of the
system. As you should know, the SAP GUI consists of multiple sessions (windows). These
sessions are also called external sessions. Within each external session, there can be several
internal sessions. For each external session, up to nine internal sessions are possible. Each
program runs in such an internal session. If a program is called without the addition, the
internal session of the calling program is replaced by the internal session of the called
program. Otherwise, an additional internal session is used for the called program.

12.2.1.1 Excursus: Variants

Variants are sets of pre-filled input fields that can be created from the user interface.

Variants can furthermore define more detailed attributes for the adaptation of a user interface.

Attributes of variants comprise:

 Only for background processing: Makes the variant only be usable for background
processing if enabled.
 Protect variant: Prevents the variant from being used by a different user than its
creator.
 Only display in Catalog: This option makes the variant available in the catalog, but not
in the general input help (F4). The Catalog is normally only accessible by developers
and can be accessed by opening the ABAP Editor and selecting Goto -> Variants
from the menu and Variants -> Catalog there.
 System Variant (Automatic Transport): Variants that match certain name conventions
are client independent and are transported automatically. For other variants, a request
can be assigned manually using the variant maintenance. The name conventions are:
o SAP&xxx: These variants are part of the system shipped by SAP
o CUS&xxx: These are customer variants

Attributes for fields are:

 Required field
 SET-/GET-Parameter setting
 Save field without values: already entered values will be kept when the variant is
loaded
 Selection variable: Supply selection criteria with values from table variants or function
modules. For type T, values are stored permanently in the TVARVC table, for type D
data fields are filled with current values, and for type B they are filled with user-
specific variables (requires the definition of a MEMORY ID when the selection
criterion was defined)
 Hide field
 Protect field

The following exercise shows an example:

12.2.1.2 Exercise: Variants

Page 95
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Open your program ZZ_####_FLIGHTS. Enter Airline LH, but do not commit yet. Instead,
choose the menu path Goto -> Variants -> Save as Variant. Choose the Variant Name
ZZ_####_VAR1 and choose a suitable description. Then save the variant.

Figure 92: New variants button: SAP-System-Screenshot

Delete the input to the Airline field. Next to the Execute button, you see a new button Get
Variant (see figure above). Click on this button and choose the variant you saved before. The
input field of the airline is now again filled with the saved value LH.

Choice of the selection screen

... USING SELECTION-SCREEN num ...

This addition chooses the selection screen given as num instead of the standard selection
screen.

Displaying the selection screen

...VIA SELECTION-SCREEN ...

Using this addition, the selection screen becomes visible to the user, instead of being
processed in the background.

12.2.2 Calling transactions

To be able to call the program ZZ_####_FLEDIT, for example, or other programs that are
started by transactions, the CALL TRANSACTION statement is used. Its syntax is:
CALL TRANSACTION transaction [AND SKIP FIRST SCREEN].

Here, transaction is a data object that contains the name of the transaction that should be
called. The behavior is similar to that of the previously explained program insertion: The
program of the transaction is executed in its own internal session. When it terminates, the
calling program is continued. Using the addition AND SKIP FIRST SCREEN, the first
screen of the transaction can be skipped.

However, it is also possible to leave the program, using the following statement10:

LEAVE TO { { TRANSACTION transaktion} | {CURRENT TRANSACTION}

} [AND SKIP FIRST SCREEN].

In this call, the currently running transaction is terminated. This means, all internal sessions of
the current call sequence are removed and replaced by the called transaction.

10
Keller (2012, p. 321)
Page 96
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

12.2.3 Calling function modules

Apart from the well-known synchronous call of a function module, it is also possible to call a
function module asynchronously. For this purpose, an addition STARTING NEW TASK
taskname has to be added to the call. The task name can be chosen freely. The
asynchronous call requires the function module to be marked as remote enabled in its
attributes.

12.2.4 Data exchange between programs

Based on the architecture, there are several different ways to exchange data when programs
are called:
 Using the interface of a modularization unit (USING, CHANGING, etc.) – this has
been explained already.
 Using the SAP memory
 Using the ABAP memory
Theoretically, further possibilities exist using the data base or files.

12.2.4.1 Using the SAP memory

The SAP Memory is a Memory that is assigned to a user session. All programs that are
executed within the user session can access the GET/SET Parameters (GPA/SPA), which are
stored in the SAP memory11.

These parameters can be used to exchange data between programs in a limited way. The
syntax to read a value from the SAP memory is12:

GET PARAMETER ID pid FIELD dobj.

This statement reads the parameter with ID pid (a character-like data object of max. 20
characters), and its value is stored in the data object dobj.

By assigning predefined values using the SAP memory, it is possible to skip the first screen of
transactions, as it is possible for programs using the SUBMIT statement. For this purpose, the
addition AND SKIP FIRST SCREEN is used:

CALL TRANSACTION tname AND SKIP FIRST SCREEN.

12.2.4.2 Using the ABAP memory

The ABAP Memory is a memory that is associated with the internal session. It is possible to
store data in data clusters therein, which can be accessed during the call sequence of multiple
programs, for example.

To write data to the ABAP memory, the EXPORT statement is used13:

11
Keller and Krüger (2011, p. 174)
12
Keller (2012, p. 1265)
13
Cf. Keller (2012, p. 1172)
Page 97
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

EXPORT
{ {p1 = dobj1 p2 = dobj2 … } | { p1 FROM dobj1 p2 FROM dobj2 …} }
TO MEMORY ID id.

Here, the values of the data objects dobj1, dobj2, … are stored using the names p1, p2, …
in an area (cluster) of the ABAP memory.

The opposite way is handled by the IMPORT statement14:

IMPORT
{ {p1 = dobj1 p2 = dobj2 … } | { p1 TO dobj1 p2 TO dobj2 …} }
FROM MEMORY ID id.

The meanings are similar here: The statement reads back the values stored under the names
p1, p2, ... of the cluster id.

The following figure shows an example for the usage of the statements.

Figure 93: Interaction with the ABAP Memory

12.3 Locks
A problem on multi user systems like SAP ERP is the simultaneous access to the same data
set. This can cause inconsistencies:

Example: A user displays a flight. While he or she sees the flight on his screen, another user
changes the flight. If the first user also changes the flight on his screen and saves it to the
database, the changes of the second user are lost.

To avoid this problem and similar other problems, the concept of locks is used in database
systems.

14
Cf. Keller (2012, p. 1181)
Page 98
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

In SAP, there is also a lock concept, but this is not a projection of the lock mechanism of the
underlying database system. Instead, it is completely realized inside the SAP system.

For this purpose, lock objects have been developed. They can be defined in the ABAP
Dictionary. Each lock object has an assigned primary table, which shall be locked.
Additionally a lock mode is defined, but this is only a default value.

There are three different lock modes:

Shared lock

The shared lock is abbreviated 'S'. It allows simultaneous read access of multiple users, but
prevents setting an exclusive lock (for writing).

Exclusive lock

The exclusive lock is abbreviated 'E'. It locks the selected records completely for other users,
but the user who has set the exclusive lock may set further locks.

Exclusive but not cumulative lock

The exclusive but not cumulative lock is abbreviated 'X'. It acts like a write lock, but the user
can lock the records only once.

Lock objects are created in the ABAP Dictionary. The lock parameters (lock arguments),
which are used to identify the records that shall be locked, are automatically generated based
on the primary key during the creation of the lock object. For all lock modes, there is only one
lock object.

To be able to set locks in ABAP code, the function modules ENQUEUE_... and
DEQUEUE_... are automatically created during creation of the lock objects. The three dots
represent the name of the lock object. SAP recommends beginning lock object names with E.

The ENQUEUE function module sets the lock, while the DEQUEUE function module
releases it again. The function module calls can be inserted into the source code easily using
the Pattern button of the ABAP Editor.

Using transaction code SM12, you can watch current locks (it depends on your permissions if
you can access this transaction, it may be inaccessible on our systems).

Page 99
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

12.4 Exercise on locks

In this exercise, you will extend your program ZZ_####_FLEDIT by locks to avoid
inconsistencies in the database.

The required lock object already exists in the system. You can have a look at it: Open the
ABAP Dictionary (transaction code SE11). Choose Lock object, enter the name EZ_SPFLI
and choose Display.

Figure 94: Lock object in the Dictionary: SAP-System-Screenshot

Here you can see that the lock mode Read Lock is predefined. However, this is just a default
value. Hence, you can use this lock object for both read and write operations. Furthermore,
you can see the name of the table to which this lock refers, which is SPFLI. If you open the
Lock parameter tab, you can also see that the parameters of the lock object are the same as
the primary key fields of the SPFLI table.

In your program, the reading access as well as the writing access to the flight connection table
shall be secured by appropriate locks. The read lock must already be set on the first screen,
because here, in the PAI, the flight is read, and a corresponding error message should also
appear there if the flight is currently locked. Open the PAI module of the first screen of your
program ZZ_####_FLEDIT, in which the data is read from the data base, and place the cursor
in front of the corresponding SELECT statement.
S explained before, for all lock objects, the system automatically generates function modules
ENQUEUE_... and DEQUEUE_.... Here, the ENQUEUE module for setting a lock is
required, while we will need the DEQUEUE module later for unlocking. It is the easiest
technique to generate the call to the function module with the well-known pattern button.
This will create the basic structure of the call.
Add the parameter values, so the call should look as shown in the following figure. Make sure
the lock mode S is used, which refers to a read lock, and the lock arguments are correctly
passed to the function module parameters:

Page 100
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 95: Function module call: SAP-System-Screenshot

Inside the IF statement, add a suitable error message, which tells the user that the lock could
not be set (using the MESSAGE statement). You do not need to send different messages for the
different exceptions the module provides.

In the next step, you will release the read lock again. This must happen when the display of
the connection is left, hence in the PAI of screen 200. At the places explained in the
following, add calls to the function module DEQUEUE_EZ_SPFLI using the pattern button
again. First, add such a call in the CASE/WHEN statement for the BACK case. Make sure to
use lock mode S and the usual lock arguments. In the LEAVE case, you do not need an
explicit removal of the lock, because all locks are automatically released when the program is
closed. In the SAVE case, it is necessary to release the lock though. Hence, add the same call
to the DEQUEUE function module. Place it at the end of the case, i.e., behind the IF
statement which wraps the MODIFY. The reason for this position is that we will add a write
lock around the MODIFY in the next step. If setting this write lock fails, the screen will not be
left due to an error message, and hence the read lock may not be released before.

You can see the syntax of the call to the DEQUEUE function module in the following figure.

Figure 96: Call of the function module to release the read lock: SAP-System-Screenshot

Page 101
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

The function module call shown in the figure should now be part of your code two times: In
the BACK case and at the end of the SAVE case.

While the display of a flight connection requires a relative long lock duration, the write access
only needs a lock to be set just before the MODIFY statement, which can be released directly
after that statement. Add these function module calls now. Attention: Make sure to use the
lock mode E for both the lock and the lock release. Also make sure not to confuse the
function modules: The ENQUEUE module is used to set the lock, the DEQUEUE module is
used to release the lock. Also in this case, add an error message when the lock could not be
set. The enhanced case statement can be seen in the following figure:

Figure 97: Extended CASE structure: SAP-System-Screenshot

Page 102
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Note that the lock mode must be E in both cases. At the bottom of the figure, you see the
release of the read lock, which you implemented before and which has lock mode S.

Save, check, and activate all inactive objects. Now open an additional session (SAP GUI
window) and open transaction SM12 therein. In this transaction, enter table name SPFLI and
commit. You can now see a (probably empty) list of locks, which are active on the SPFLI
table. Now go to your first session and call the transaction of your program
ZZ_####_FLEDIT. Open a flight connection in the program. Then go to the second session,
which contains the SM12 transaction and press . You should now see the read lock
with lock mode S (see figure below).

Figure 98: Currently set locks for table SPFLI: SAP-System-Screenshot

Now, in your fist session with your FLEDIT program, go back to the first screen using the F3
key. Now refresh the lock list in your second session again. The lock should not be listed
anymore.

The write lock cannot be seen so simply, because it is released directly after the write
operation. To test this lock, too, open the source code of your program and set a break point
on the line with the MODIFY statement by clicking on the grey border at the beginning of the
line:

Figure 99: Breakpoint: SAP-System-Screenshot

Page 103
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Now start your program again. Open flight AA 0017 and change the flight distance. Then
click on the save button. Now the debugger will open. Go to the session in which the SM12
transaction is running and refresh the list. You can now also see your write lock with lock
mode E. In the debugger session, continue using the button or F8. Your program reaches
the first screen again. Refresh the lock list in the SM12 transaction again. There should not
appear any locks anymore, because both locks are released in the PAI of screen 200.

Now leave the SM12 transaction and your program. Remove the breakpoint from your source
code.

Page 104
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

12.5 Remoting
In ABAP, it is possible to call function modules that are located in a different SAP system
than the caller. This process is called remote function call (RFC). The concept is explained
only briefly here. The call to remote function modules is not part of the course, but it helps
you to get a better understanding of the system.

The RFC interface is not only responsible for the communication between SAP systems. It
can also handle the communication between SAP and other systems. There are connectors for
Java, the .NET platform (C#, VB.NET...), and C / C++.

The interface is responsible for15:

 Realization of communication between the systems

 Login, logout, and authorization checks for the remote system
 Conversion of parameter values into the representation of the corresponding system
 Exception handling

To call a remote function module, the CALL FUNCTION statement is used with the addition
DESTINATION. For this addition, a destination must be provided. The destinations are
maintained in transaction SM59. For a connection to another SAP system, the client must be
specified, as the connection is established on this level. The function call is normally executed
synchronously, which means that the calling program waits until the called function of the
remote system is finished. If, however, the addition STARTING NEW TASK is used, an
asynchronous call is realized, so that the calling program proceeds immediately after the call
to the remote function module. If the addition IN BACKGROUND TASK is used, a
transactional call is used. In this case, the execution is only registered and can be executed by
the statement COMMIT WORK. If the additions STARTING NEW TASK or IN
BACKGROUND TASK are used, the specification of the DESTINATION is optional.

To make a function module callable by a remote caller, it has to be marked as remote-enabled

in its attributes. This also has the consequence that parameters may only be passed by value.
In the local system, remote-enabled function modules can be called like normal function
modules or using RFC. The destination of a local system is called NONE.

15
Keller (2012, p. 1332)
Page 105
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

12.6 Predefined input checks

To avoid inconsistent input into input fields, it is useful to check the user input. The input
check can be defined in the Dictionary already based on single values and foreign key
relationships.

12.6.1 Input check by a domain

The simplest case of an input check can be realized by a domain. As described earlier already,
a domain describes the technical properties of a type and can contain a set of values. If these
values are defined, screen fields, which rely on this domain, are automatically restricted to
values of this predefined set.

To see an example, open the table SBOOK in the ABAP Dictionary. Double-click on the
data element that is used to type the class, and then double-click on its domain. In the domain
view, choose the tab Value Range. You see the predefined values there:

Figure 100: Value range of a domain: SAP-System-Screenshot

The defined values prevent the input of invalid values on screens, and they are available in the
F4 help of the corresponding field. Alongside single values, intervals can also be specified.
At the bottom, you see a field called Value Table.

Figure 101: Definition of a value table: SAP-System-Screenshot

Here, a database table can be provided from which the values for a value check can be taken.
Note, however, that the selection of a Table in the Value Table field does not lead to an
Page 106
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

input check or an F4 help. The field Value Table in the attributes of the domain is only
used by the system to generate a proposal during the definition of a foreign key
relationship.

12.6.2 Input checks based on foreign keys

Figure 102: Input checks based on foreign keys (1)

When you created your program ZZ_####_FLEDIT and tested it, you should have noticed
that there are some error messages on incorrect input which you did not define yourself. The
figure above shows an example: Entering an invalid airline causes an error message, which
tells you that the airline is not contained in the SCARR table.
The reason for this message is a foreign key definition, which prevents such an incorrect input
on GUI level. The foreign key table has been defined by SAP for this field, as you can see in
the following figure.

Figure 103: Input checks based on foreign keys (2)

Page 107
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

The figure shows the definition of the foreign key for the check field CARRID in the SPFLI
table. The check table is the table SCARR, which contains all airlines. From the SPFLI table,
the whole primary key of the referred SCARR table is referenced for the foreign key
relationship.

Note: The check is only performed on GUI level! The definition of a foreign key does not
prevent an ABAP program to insert inconsistent data that violates a foreign key
relationship. The reason for this behavior is the system performance: Foreign key checks are
quite expensive; hence they are not used if efficiency is the critical goal in the development of
a program.

Figure 104: Domain equivalence of check field and key field

The domains of the check field and the referenced key field of the check table must be
identical to make sure there is no conflict caused by different data types or lengths. It is not
important which data element is used, as long as the domain is the same for both data
elements. For the other key fields, this requirement does not exist, but is recommended
because changes of the domain affect both tables then and the relation is kept in a consistent
state. The figure above shows an example for the CITYFROM field of the SPFLI table. This
field has a different data element than the CITY field of the check table SGEOCITY (which
makes sense, because the field descriptions should be different). Nevertheless, the domain is
S_CITY in both cases. Please don’t be confused here: There is a domain and a data element
both with the name S_CITY here.
The value table of the domain is proposed by the system when a foreign key is defined. This
proposal is not necessarily correct in every case. This occurs especially if domains are reused
in inappropriate situations.

Page 108
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

For each foreign key relationship, there is a certain cardinality. This cardinality describes,
how the records of the two tables may be related to each other. Here, the relation on the side
of the foreign key table (n) and the check table (m) are differentiated. The following options
are available16:

 For the side of the foreign key table (n):

o 1: For each record, there is exactly one record in the check table
o C: There may be records without a record in the check table. This is relevant in
cases where the foreign key field may be empty.
 For the dies of the check table (m):
o 1: For each record, there is exactly one entry in the foreign key table.
o C: For each record, there is at most one entry in the foreign key table.
o N: For each record, there is at least one entry in the foreign key table.
o CN: For each record, there is an arbitrary number of entries in the foreign key
table.

From these possibilities, eight combinations are possible. The relationship of the CARRID
field between the SPFLI and SCARR tables is a 1:CN relationship. The following figure
depicts the relationship with this cardinality:

Figure 105: Cardinality 1:CN in an example

There are different types of foreign key fields. The type determines if the foreign key field
uniquely identifies a record. Foreign key fields can be key fields and non-key fields, or key
fields of a text table (this is a special case). The following types are available17:

16
Gupta (2011, p. 104)
17
Gupta (2011, p. 101)
Page 109
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

 Not Specified: The type of foreign key is not defined. In some cases, e.g.,
maintenance views, this option is not allowed.

 Non-key-fields/candidates: The foreign key fields are not primary key fields and
cannot uniquely identify a record.

 Key fields/candidates: The foreign key fields are primary key fields or they are
candidates that can uniquely identify a record.

 Key fields of a text table: In this special case of the previous type, the foreign key
table is a text table of the check table. The key of the foreign key table differs from the
one of the check table by an additional language key field.

Figure 106: Text table

The figure shows the table SMEAL (for meals) and its text table SMEALT, which contains
the names of the meals in different languages. The key of SMEALT differs only in an
additional language field from the key of table SMEAL. Like this, names of a meal in
different languages can be stored in the SMEALT table. The relationship must be defined
from SMEALT to SMEAL and the type key fields of a text table must be used as the type of
foreign key relationship. For each table there can be only one text table.

12.6.3 Exercise on input checks

For this exercise, two new tables shall be defined:

 A table ZZ####_PROF for professors

 A table ZZ####_CH for chairs

The table ZZ####_CH shall contain the following fields:

 MANDT: Client number

 CHID: 5-character number of the chair

 NAME: Name of the chair

Page 110
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

The table ZZ####_PROF shall contain the following fields:

 MANDT: Client number

 PERSID: 7-character person ID

 FIRSTNAME: First name of the professor

 LASTNAME: Last name of the professor

 CHAIR: 5-character number of the chair of the professor

 TYPE: Type of professorship (Adjunct, Full)

First create a domain ZZ_####_CHAR15. This domain shall be able to store 15-characters.
Also create a domain ZZ_####_N5 and a domain ZZ_####_N7 for 5 and 7 character
numerical strings, which shall represent the numbers. Furthermore, create a domain
ZZ_####_TYPE. This domain shall contain a sign to symbolize the values A (adjunct) and F
(full). Enter these values as single values on the Value Range tab.

Figure 107: Values of the domain: SAP-System-Screenshot

After that, create data elements ZZ_####_CHID, ZZ_####_CHNAME,

ZZ_####_PERSID, ZZ_####_PFN (first name), ZZ_####_PLN (last name), and
ZZ_####_TYPE for the table fields based on the domains created before. Do not forget to
activate data types and domains.
Now, create a database table ZZ####_CH. The delivery class shall be A and
Display/Maintenance Allowed. The client field MANDT can be typed using the MANDT
data element. For all other fields, use the data elements defined before. The key shall contain
client and chair ID. Also maintain the technical settings as usual. Then save and activate the
table.

Figure 108: Fields of the chair table: SAP-System-Screenshot

Now, create the table for professors similarly.

Page 111
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 109: Fields of the professor table: SAP-System-Screenshot

Save and activate both tables.

The next step is the definition of foreign keys. Open the table that contains the chairs and go
to the field list. Put the cursor into the MANDT field and click on (foreign key). The
system asks if a proposal should be determined based on table T000. Commit this question.
In the semantic attributes section at the bottom of the next window, choose Key
fields/candidates and cardinality 1:CN. Add a suitable short description and click on Copy.

Save and activate the table. In the tab Entry help/-check, you see the check table now:

Figure 110: Check table: SAP-System-Screenshot

Close the table now and open your domain ZZ_####_N5. In the Value Range tab, enter
ZZ####_CH as the value table. Save and activate the domain.
Open the table ZZ####_PROF. First insert a foreign key relationship as you did for the table
ZZ####_CH before. Then put the cursor to the field CHAIR. Let the system propose a
foreign key relationship. Because you entered a value table for the domain ZZ_####_N5
before, a proposal based on the table ZZ####_CH is generated. Accept this proposal, save,
and activate the table.

Now, open the chair table again and go to the menu path Utilities -> Table Contents ->
Create Entries. Enter some example chairs there.

Then, open the same functionality for the professor table. Try to insert invalid data there (non
existing chair IDs). The system will send an error message as intended:

Figure 111: Error message after input check: SAP-System-Screenshot

Page 112
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

12.7 Search helps

From your program ZZ_####_FLEDIT, you already know search helps that simplify
entering data into screen fields. For example, if you press F4 in the Airline ID field, this
window is displayed:

Figure 112: Search help in the ZZ_####_FLEDIT program: SAP-System-Screenshot

Alternatively, you could also use the button inside the input field that appears when the input
field is selected. The input help not only contains the IDs of the airlines. Instead, also their
names are displayed. This is very helpful for users that try to find the correct entry. They do
not have to remember the formal IDs.

Page 113
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

The search help is a standard feature of the SAP system. SAP tries to realize a similar
structure of this function throughout the whole system. To achieve this goal, there are tools to
define search helps in a standardized way. Usually a search help is defined in the ABAP
Dictionary.

Figure 113: Context sensitivity: SAP-System-Screenshot

The figure above shows how the search helps processes the context: In the airline ID field,
there is already a value LH. As a consequence, the search help for the flight number offers
only flights provided by the airline chosen already. It is also possible to use information from
earlier dialog steps.
The additional information, like the departure and arrival cities here, is defined by the search
help. It is a design decision of the developer which information should be displayed here.

If the value list is very large, a search help can display a search mask first. Based on this
mask, the number of records displayed in the search help thereafter can be reduced
significantly.

After the choice of a value from the input help, this value and possibly additional information
has to be transmitted to the screen. This includes explanatory text fields on the screen.

Page 114
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 114: Search helps and their interfaces

In the ABAP Dictionary, the object type search help is used to represent the search help. The
search help comprises all attributes that describe the behavior explained above.
The interface determines which data is used from the context and which data is returned to
the screen when an entry is selected. Furthermore, it contains a selection method, which
defines how the data for the search help is determined and a dialog behavior, which defines
the interaction between search help and user, for example, whether there is a search mask or
not. The separation of interface and behavior is similar to function modules.

Page 115
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

12.7.1 Selection method

The selection method determines the source of date to be displayed in the search help. This
data is retrieved at runtime.

If all data that is required for the selection in a search help is contained in one table, this table
can be used to determine the entries. For data that is spread over multiple tables, the definition
of a view is recommended. Maintenance views cannot be used here. Database views are
restricted to the use of inner joins, which is not always intended. Hence there is an additional
type, the help view, which can be used instead of a database view.

Help views support the left outer join, too, and are defined analogously to maintenance views.
A primary table is selected and additional tables are added based on the relationships of the
primary table. The disadvantage of a help view is mainly that it can only be used in search
helps. Due to these reasons, the database view is the superior option, because it can also be
used in other contexts of programming. The names of help views usually start with H_, hence,
help views with prefix H_Y and H_Z are part of the customer namespace.

If a table has a text table, this is recognized by the system. The text from the text table can be
used as an additional field inside the search help. This way, you do not need to define a view
in this case.

12.7.2 Dialog behavior

Figure 115: Pop-Up for value search: SAP-System-Screenshot

Page 116
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

The dialog type of a search help determines if input fields for the restriction of values shall be
displayed before the list of values. There are three possible options:

 Display values immediately: Here, the list of matching records is displayed

immediately. This makes sense if the list is not too long.
 Dialog with value restriction: Here, the input fields for the restriction of values is
displayed first. This makes sense if the list is quite long, because a more detailed
selection increases the clearness of the dialog. Furthermore, the system performance
could be influenced negatively.
 Dialog depends on set of values: If this option is chosen, the system decides
automatically whether the dialog should be displayed or not. If there are more than
100 records, the dialog is shown, otherwise the system directly presents the list of
matching records.

To simplify the input, elementary search helps can have shortcuts. This is relevant if the
elementary search help is part of a collective search help. If a shortcut is defined, the input
field can be used with a short notation:

=shortcut.sel1.sel2
Here, shortcut is the letter of the shortcut and sel1, etc., are values that are (ending with
a star) taken over to the input fields of the pop-up for value restriction. After that, the result
list is called automatically.

Parameters of elementary search helps can be displayed as non-editable fields on the value
restriction pop-up. This is useful for import parameters that are assigned to screen fields that
are not editable.

The SAP system offers three visualizations of search helps:

 Listbox

 Control

 SAP dialog

The listbox is very restrictive, as it offers only the simple selection of predefined values. Its
advantage is the simplicity. This makes it advantageous for small search helps. It can be
activated by configuring the Dropdown attribute of the corresponding input field in the Screen
Painter. Switching between the other two options can be done by the user later using the menu
path Help -> Settings. The default setting is made by the system administrator.

Figure 116: Selection of a search help display: SAP-System-Screenshot

Page 117
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

12.7.3 Interface

Figure 117: Interface of a search help

The figure above shows the interface of a search help in action. The interface of a search help
is divided into IMPORT and EXPORT parameters. Import parameters are taken into the
search help, while export parameters transport data back to the screen after the selection of a
value from the search help.

All fields that shall appear on the search pop-up, in the value list, or in both windows must be
defined as parameters of the search help. All fields of the selection method can be used except
the client field (in client dependent selection methods the selection is always restricted to the
current client). Furthermore, it is required that the search help parameters are typed by data
elements. The parameters have the data element of the corresponding field of the selection
method if not specified differently. As you can see in the figure, not all parameters must be
displayed in the search help pop-up. This depends on their attributes. The most important
attributes of search help parameters are:

 Import parameter: If this attribute is activated, the field content will be transported
from the screen to the search help. The field on which the search help is called is only
transported if it contains a wild card (* or +).

 Export parameter: This attribute determines if the parameter should be transported

back to the screen on selection of an entry in the search help.

 LPos: This parameter determines the position of the parameter in the result list. It is a
numerical value. Attention: If this field is empty, the field is not displayed at all!
Hence, do not forget to specify this attribute if you want to display the parameter.
However, there may be cases where a parameter is used for the value selection only
and shall not be displayed at all.

 SPos: This parameter determines the position in the dialog for value selection, similar
to LPos.
Page 118
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

 SDis: This checkbox can be used to make a field disabled, so its value cannot be
changed by the user in the dialog.

 Default value: Using this attribute, a default value (a literal, a system field, or a GET
parameter) can be defined. This value is used under the following circumstances18:

o If the parameter is not an import parameter

o If there is no assignment for this parameter in the corresponding search help

attachment

o If the field is missing on the screen and the screen flow logic

o In the context of collective search helps, if there is no connection to the

parameters of the collective search help

18
Gupta (2011, p. 292)
Page 119
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

12.7.4 Search help attachment

To use a search help, it must be assigned to a search field. This process is called search help
attachment. There are two general possibilities:

 Attachment to an input field of a screen in the Screen Painter

 Attachment in the Dictionary

The first mentioned possibility is bad style and also has some limitations for the parameter
assignment (only one parameter is possible). Instead, the attachment should always be done
using the dictionary. This supports reusability.

During attachment, the import and export parameters of the search help have to be assigned to
fields. The search field itself should be attached as an import and export field to be able to
transport a field value with placeholders to the search help and of course to be able to
transport the selected value back to the field.

If the search help is assigned to the Dictionary field, it is automatically used on screens that
use the corresponding field.

There are three ways of attachment in the ABAP Dictionary:

 Attachment to a data element: A direct attachment to a data element is possible. The

search help is available at all places where the data element is used. However, the
attachment is only active for that field, so no other fields can be filled with export
parameters from the search help.

 Attachment to a field of a structure or table: The search help can be attached

directly to a field of a structure or a table. An assignment between interface parameters
and fields of the structure or table takes place. On all screens that use fields based on
this structure or table, the search help is available, and all attached input and output
parameters are used. This is the most convenient way of search help attachment.

 Attachment to a check table: If the field contains a check table, a search help based
on the key fields of the check table is automatically offered. If the check table has a
text table, the first char-like non-key field of that table is added, too. You can test this
check table help using your table ZZ####_PROF by calling the value help of the
chair field in the input mask (using F4 or the button in the input field). If the
information offered here is not enough, a value help can be attached to the check table.
The interface parameters of the search help are assigned to key attributes of the check
table in this case.

Page 120
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

12.7.5 Determination of the search help to be used

There may be cases where multiple search helps are defined, e.g., one search help could be
attached on the screen, while there is another available from the dictionary. There is a
hierarchy of search helps that determines the choice.

 Search helps that are attached directly on the screen have the highest priority. There
are three possibilities for this, which are selected in the following order:
o The PROCESS ON VALUE-HELP in the flow logic. This possibility has
been demonstrated in the FLEDIT exercise for the predefined search help. It is
an event which can be used to define a search help using the function modules
F4IF_FIELD_VALUE_REQUEST and
F4IF_INT_TABLE_VALUE_REQUEST.
o A search help attached to a field in the Screen Painter
o Search help attachment using the FIELD…SELECT syntax in the flow logic.
These statements are outdated and should not be used any more.
 After that, the system continues to search for a search help in the Dictionary. The
search proceeds in the following order:
o Search help attachment for the table or structure type
o Search help using a check table (from a foreign key relationship). If the check
table has a search help, this is used. Otherwise, the primary key fields of the
check table are displayed, and if it has a text table, the corresponding text is
also displayed in the corresponding user language.
o Search help attachment for the data element
o Fixed values from the domain
o If none of these exist, at last there are some input widgets for date and time
fields, which are displayed as input helps. For other types, no input help is
shown at all in this case.

12.7.6 Collective search helps

Depending on the context and individual requirements of the users, there may be very
different criteria for the search for records. In most cases, users do not search by specifying
the key of a record. Instead, they specify a variety of other attributes. In a table of persons,
one user could search based on the address, while another user knows some part of the name.
A third user may describe the person using customer specific attributes. The access using non-
key fields requires the configuration of search paths. It should be possible to offer multiple
search paths for the same field.

Single search paths can be defined by elementary search helps as described above. However,
each field can have just one search help, but for multiple search paths a mechanism is
required, which can assign multiple search helps to one field. This is realized by collective
search helps in the SAP system.

A collective search help combines multiple elementary search helps and, therefore enables
multiple search paths for various requirements.

Page 121
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

Figure 118: Collective search help

A collective search help also defines an interface consisting of import and export parameters.
This interface is used as a common interface to the individual search helps. It can be attached
to fields, tables, etc. just like a normal search help.

The description of the selection method and the dialog behavior is in the responsibility of the
elementary search helps. The individual search helps are offered to the user in a tabstrip. The
lastly chosen tab is selected automatically. The collective search help must only be configured
in terms of included elementary search helps. Furthermore, the interface must be defined, and
parameters have to be assigned to those of the elementary search helps.

Collective search helps may also be included in other search helps. Also, a search help can be
used inside and apart from multiple collective search helps.

Page 122
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

12.7.7 Append search helps

Append search helps can be used to enhance an existing search help of the SAP system
without the need for a modification. It is similar to a collective search help. Using the append
search help, you can add your own search helps to the collective search help of SAP.

Figure 119: Append search helps

It is also possible to remove an elementary search help from an SAP collective search help.
For this purpose, the search help is included in the append search help and made invisible
there. This could also be done without an append, but then it would not be a technique without
modification anymore.

12.7.8 Further adaptations of search helps

The adaptations presented so far are not the limit of possibilities to adapt search helps in SAP
systems. If a deviation of the system-wide standards for the design of user interfaces is
intended, search help exits can be used. These are special function modules with a

Page 123
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

standardized interface. If available, they are called before each step of the search help process
(e.g., the selection of an entry). The interface is used to supply all information on the current
state of the search help that can be modified by the function module.

An example of a search help exit can be seen in the function module

F4IF_SHLP_EXIT_EXAMPLE. Search help exits must match the same interface.

Search help exits should only be used in special cases. They are a bit dangerous because it is
easy to manipulate the standard behavior and increase the maintenance cost of the search help.

12.7.9 Exercise on search helps

For this exercise, open your table ZZ####_PROF in the ABAP Dictionary and choose the
menu path Utilities (M) -> Table Content -> Create Entries. Put the cursor into the input
field for the Chair ID and press F4 to see the current help.

Figure 120: Search help of the chair field: SAP-System-Screenshot

This automatically generated search help is based on the check table and not very helpful.
Instead of displaying the ID only, the Chair name shall be displayed.

Leave the table and open the initial screen of the ABAP Dictionary. Choose Search help and
enter the name ZZ_####_CHHELP. Create it and commit that it should be an elementary
search help.

Add a suitable short description and enter the table ZZ####_CH in the Selection method
field. Then add the CHID and the NAME column to the parameter table below. Use the F4
help for this step.

Figure 121: Search help parameters: SAP-System-Screenshot

Mark the Chair ID as an import and export parameter (IMP and EXP). In the LPos and SPos
enter position numbers, e.g., 1 and 2. This determines the order of fields. Attention: Leaving
Page 124
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

the fields empty makes the Fields invisible. Use the F1 help to display a detailed explanation.
Save, check, and activate the search help.

The search help is not yet effective, as it has not been attached to the table yet. Open your
table ZZ####_PROF in the dictionary and place the cursor on the field CHAIR. Then click
on . In the next window, enter the name of your search help and commit. In the
following window, you can generate a proposal for the field assignment using the Generate
Proposal button. Make sure the proposal is correct (only the chair ID should be assigned. It
can happen that the system tries to assign the chair name to the name of the professor, which
is wrong as it means that after selecting a chair, the chair name is written to the professor
name field). After that, commit the window. Save, check, and activate the table.

After that, go back to the insertion of records. Call the F4 help of the chair field. Now, your
search help is used:

Figure 122: Using a self-defined search help: SAP-System-Screenshot

Page 125
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami
 Introduction to ABAP

12.8 Chapter Submission

You are now at the end of this part of the course. Please consider the following things before
you send the e-mail described below:

o Make sure you did all exercises, including those that are not part of a chapter
explicitly named “exercise.”

o Make sure all your repository objects are working correctly

o Make sure all your repository objects are activated. To find objects which are
not yet activated, select Inactive Objects from the drop down menu above the
navigation tree in the Object Navigator. Enter your user name USER#-### into
the field below and commit. After that, the inactive objects are displayed in the
navigation tree. Activate them now. Please note that you may have to expand
the branches of the navigation trees completely. To get back to your package
afterwards, select Package from the drop down menu and commit your
package name by clicking on the Display button.

o Make sure the names of your repository objects are exactly the same as
described in this document. If you mistyped a program name, right-click on it
in the navigation tree of the Object Navigator and select Rename… from the
menu.

These notes are also relevant for all following chapters.

If you completed the course so far, send an e-mail to your tutor using the subject
“ABAP: Finished Chapter 12 User ####” (The quotes are not part of the subject). You
will then receive feedback: Either in the progress report if everything was correct, or by e-
mail if you have to correct something. Make sure that you enter the subject exactly as
described above to ensure an efficient processing of your e-mail.

If you have any questions, please use a separate e-mail, because the e-mails used for finished
chapters are usually only processed based on their subjects, and no content is read.

Page 126
Copyright Prof. Dr. Heimo H. Adelsberger/Dipl.-Wirt.-Inf. Pouyan Khatami