ABAP Part 5 GUI [PDF]

Zitiervorschau

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 SCREENACTIVE = 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 4

Keller (2012, p. 860) 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 o o o o o



Poss. entries key (input help button) Right-justified Leading zeroes * Entry Without reset 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 EXITCOMMAND 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:      

7

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.

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 syucomm. 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 doubleclicking 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 EXITCOMMAND. 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 selecting an area of the screen.

and

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 the OK code field.

) and select the name ok_code for

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 email, 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 userspecific 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) Keller (2012, p. 1265) 13 Cf. Keller (2012, p. 1172) 12

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 with lock mode S (see figure below).

. You should now see the read lock

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 17

Gupta (2011, p. 104) 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

18



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

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 nonkey 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 F4IF_SHLP_EXIT_EXAMPLE. Search help exits must match the same interface.

module

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 email 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