ABAP Dialog Programming

ABAP Training

Dialog Programming

ABAP Training Dialog Programming 2

Overview of Components

Unlike report, interface, and conversion development which generally entails the creation of one autonomous program which can be executed independently of other objects, dialog program development entails development of multiple objects, none of which can be executed on its own. Instead, all objects are linked hierarchically to the main program and are executed in a sequence dictated by the program.

Dialog programs are composed of the following main components: Screens Module pool Subroutines Menus/GUI statuses Transaction codes


Screen Overview

Screens are made up of the following components: Screen attributes Screen layout/screen elements Fields Flow logic

Flow logic is comprised of two events: The process before output (PBO) event invokes any processing which

is to occur before the screen is displayed to the user. The process after input (PAI) event invokes any processing which is

to occur after the user has completed interaction with the screen by invoking any one of the possible functions (I.E. Save, back, enter, etc.).


Module Pool Overview

The module pool consists of modularized ABAP/4 syntax which is placed inside include programs belonging to the dialog program.

These modules are invoked when called upon by flow logic. Processing of flow logic and ABAP/4 modules is handled by different

processors in the SAP system. Flow logic is processed by the dialog processor while all ABAP/4 is

processed by the ABAP/4 processor.


Module Pool Overview Contd..

The ABAP/4 module pool consists of the following components:

The main program which will contain a series of include programs. Customer dialog programs should begin with SAPMZ or SAPMY.

Global data declarations in the form of a top include program. The program is named with the last five characters of the main program followed by ‘TOP’ (for TOP include). All data declarations will be placed within this program during development.


Module Pool Overview Contd..For modularization purposes, remaining ABAP/4 is developed using the following structure of include programs:

A PBO module include program is created to hold modules invoked by the PBO event of any of the screens in the dialog program. A PAI module include program is created to hold modules invoked by the PAI event of any of the screens in the dialog program. The proper naming convention uses the last five characters of the main program followed by either ‘O’ for PBO modules or ‘I’ for PAI modules, ending with a sequential number beginning with ‘01’. All PBO and PAI modules are placed inside their respective include program until the need for further modularization arises at which point a new include can be created using the next number in the sequence.

If further modularization is required a forms include program is created for subroutines name with the last 5 characters of the main program followed by ‘F’ for forms followed by a sequential number beginning with ‘01’.


Dialog Processor Vs. ABAP/4 Processor

When processing is transferred from the dialog processor (screen) to the ABAP/4 processor (module pool), the values of all screen fields must be passed to their respective ABAP/4 fields. This data transfer process must also occur when processing returns to the dialog processor form the ABAP/4 processor.

In order for values to pass successfully between the dialog processor and the ABAP/4 processor, screen fields must be named identically to their respective ABAP/4 fields.

In the most basic case, data transfer between the dialog processor and the ABAP/4 processor occurs at the beginning of the PBO event and immediately after the function code is invoked for the PAI event. Exceptions to this include the existence of the field statement in the flow logic or the use of a control table.


Dialog Processor Vs. ABAP/4 Processor


Review: Components of Dialog Program

Dialog programs are composed of the following components: Module pool Screens Subroutines Menus/GUI statuses Transaction codes

The individual components of a dialog program interact to form an executable transaction.

Screens are processed by the dialog processor. Process before output (PBO) and process after input (PAI) flow logic instructions are read by the dialog processor which in turn invokes the ABAP/4 processor and passes the values of the screen fields to the identically named ABAP/4 fields. The ABAP/4 processor processes the PBO or PAI modules called by the flow logic. When completed, control is returned to the dialog processor and the values of the ABAP/4 fields are returned to the identically named screen fields. This process is repeated as necessary until all instructions have been executed.


Creating Components Using the Standard Dialog Programming Toolset


Dialog Programming ToolsetCentral Component Tool Transaction/

Path

All Components* Object Browser SE80 Tools > ABAP Workbench > Object Browser

Screen Screen Painter SE51 Tools > ABAP Workbench > Screen Painter

ABAP/4 Module Pool ABAP/4 Editor SE38 Tools > ABAP Workbench > ABAP/4 Editor

Dictionary Objects (tables, fields, etc.)

ABAP/4 Dictionary

SE11 Tools > ABAP Workbench > ABAP/4 Dictionary

Menu Menu Painter SE41 Tools > ABAP Workbench > Menu Painter

Transaction Maintain Transaction

SE93 Tools > ABAP Workbench > Development > Other Tools > Transactions


Dialog Programming Toolset Contd..

Dialog program development utilizes tools available in the ABAP workbench which are the same tools used in developing the standard SAP applications.

* Dialog programs should always be developed via the object browser (SE80). When developed by the object browser, all objects become linked to the main program without having to explicitly point each object. Additionally, advanced navigation techniques speed up the process of moving from one object to another.


Object Browser

Individual tools such as screen painter are invoked from within the object browser in one of two ways: Example 1: position the cursor on the main program, choose create,

then select an object from the object list. After naming the object to be created and choosing ‘create’ again, the associated tool will be launched in create mode.

Example 2: position the cursor on an object in the object list (i.E. Screen) and choose ‘create’. Object browser will then launch the tool associated with the object that was selected.


Creating Objects Using Forward Navigation

Dialog program objects can also be created using the forward navigation functionality of the SAP system.

For example, during the creation of the flow logic for a screen, clicking on the name of an ABAP/4 module that has not yet been created will result in a system prompt stating that the object you have selected does not exist, ‘do you wish to create the object?’ Choosing ‘yes’ will launch the appropriate tool. In the case described here, the developer will select a program to include the module in and the ABAP editor (SE38) will be invoked.

Creation of objects via standard navigation works for other objects such as global data declarations, include program development, screens, and many other objects. This functionality is available in all phases of development including non-dialog program development.

In dialog program development, creating objects via standard navigation ensures that objects reference each other appropriately. Therefore, this is the preferred method for creating objects in a dialog program.


Developing a Simple Dialog Program


Creating a Dialog Program

1) create the main program2) create top include3) create first screen

Define attributes Define graphical user interface Assign field attributes via field list Define flow logic using dialog flow logic syntax

4) create follow up screens (Same steps as first screen)


Creating a Dialog Program5) create ABAP/4 processing logic (modules, sub-routines, etc.)

Choose (create if necessary) the PBO include which will contain the ABAP/4 modules Write PBO modules (ABAP/4) Choose (create if necessary) the PAI include which will contain the ABAP/4 modules Write PAI modules (ABAP/4) Create any required subroutines (create include programs if necessary)

6) define ABAP/4 global data TOP include Names must be identical to names used in screens!

7) create menus (if necessary, not yet discussed) 8) create transaction

* Steps 5 and 6 can be transposed and often occur together.


Creating the Main Program

From the object browser (SE80) choose the ‘program’ radio button, enter your program name (SAPMZxxx) and choose display.

Message dialog is displayed ‘the program SAPMZxxx does not exist. Do you want to create the object? Choose ‘yes’.


Creating Main Program (With Top Include)

A ‘create program’ window is displayed with the name of the main program and a checkbox ‘with top include’ defaulted to ‘X’. To work with an explicit TOP include, leave this box checked. This will cause the system to automatically create a TOP include along with the main program. Choose ‘enter’.

Another ‘create program’ window is displayed for the TOP include which the system will now attempt to create. The default name will be MZxxxTOP. Choose enter.

The ABAP/4 editor (SE38) is invoked and the ‘ABAP/4 program attributes’ screen is displayed. As with all program development, provide a short description and assign relevant attributes.


Creating Main Program (With Top Include)

Assign the type ‘M’ (default) for module pool. Unlike type ‘1’ programs (reports, some utility programs, etc.), Type ‘M’ programs cannot be executed directly. They must first have a transaction code assigned to them (discussed later).

After saving the main program and leaving the program attributes screen (i.E. Choosing ‘back’ from the menu) you will again be prompted with the ‘create object catalog entry’ screen where a development class is assigned. This time the name of the TOP include program MZxxxTOP will be displayed. You must save from this screen or the TOP include program will not be created.


Viewing Program From Object List

After saving the TOP include, the object list is displayed from within the object browser.

The main program and the TOP include are displayed in a tree format. All objects added to the dialog program will be displayed in this

hierarchy. Objects displayed here include: dictionary structures, global data,

macros, PBO modules, PAI modules, subroutines, screens, GUI status, GUI title, transactions, and includes.

Although dictionary structures, global data, macros, PBO modules, PAI modules, and subroutines are displayed as independent objects belonging to the main program, they are actually objects defined within the include programs which are also listed. For example, if a PBO module is added to an include program for PBO modules, that module will be displayed underneath the main program under PBO modules and the include program containing that module will be displayed with the include programs.


Creating Screens

Create the first screen, usually numbered ‘0100’, by positioning the cursor on the main program and choosing ‘create’, or by double clicking on the ‘program object types’ entry of the object browser.

The ‘program objects’ list is displayed with the various types of objects which can be created.

Choose the screen radio button, supply the screen number, and choose ‘create’ at the bottom left of the screen.

Assign the screen attributes. Provide a short description. Choose a screen type (default ‘normal’). Enter the follow-up screen to be processed after completion of current screen.

Save the screen attributes. Choose the ‘full screen’ button from the top to define the screen layout

(‘paint the screen’).


Defining the Screen Layout Elements are added to screens using screen painter. Two editors are

available in screen painter, the alphanumeric screen painter and the graphical screen painter (as of v3.0 and requires windows 95, windows NT, or UNIX).

In the alphanumeric mode fields are input/OUPUT fields are represented by underlines ‘_’ and text fields are types on the screen. Additionally, graphical elements can be added to the screen (i.E. Group boxes, radio buttons, check boxes, icons, buttons, control tables, step loops) by placing a field on the screen, placing the cursor on the field and choosing ‘graphical element’.

With the graphical screen painter, screen elements are chosen from a graphical list of elements and are placed on the screen using the mouse. Screen fields and objects can then be manipulated in a ‘drag and drop’ fashion.

To add fields from the data dictionary, choose ‘dictionary/program fields’ from the GOTO menu.

As a general rule, screen fields should reference dictionary fields whenever possible.


Assigning Field Attributes

Attributes must be defined for all screen fields. Objects taken from the dictionary retain the attributes

assigned in the data dictionary unless otherwise specified. These attributes include field name, length, type, etc. And are taken from the data element and data domain.

There are six field list views for defining field attributes. They are located in the menu path Goto > field list views and include: field types, text/templates, general attributes, display attributes, modification groups, and list/mc currencies.


Assigning Field Attributes

Additionally, field attributes can be assigned and displayed by selecting the field and choosing ‘attributes’ from the screen painter or by choosing ‘field list’ from the flow logic portion of screen painter. Field types Tests/templates General attributes Display attribute Modification groups List/mc currencies


Flow Logic and ABAP/4 Modules

Flow logic is defined from the screen painter by choosing ‘flow’ from the screen painter, or by navigating to the desired screen from the object list.

Flow logic consists of a limited syntax which is different than ABAP/4. Its general purpose is to define the flow of execution of dialog programs.

Module statements are inserted in the flow logic to designate which ABAP/4 modules will be executed.

By double clicking on the module name, ‘forward navigation’ will create the empty ABAP/4 module for you in the appropriate include program.


PBO and PAI Modules

PBO and PAI modules are developed in ABAP/4. PBO module statements are followed by OUTPUT and PAI module

statements are followed by INPUT. PBO and PAI modules should be placed in separate include programs. All ABAP/4 statements are placed between the MODULE and

ENDMODULE statements.


Global Data and Top Include

Global data is defined in the TOP include. Field names must be identical to screen field names for values to pass

between the dialog processor and ABAP/4 processor at runtime. Fields can be created via forward navigation or by going directly to TOP

include in the ABAP editor. If a TOP include is not defined explicitly, data is placed in the global data

area and the TOP include is used implicitly.


Creating Transaction Codes

Dialog programs (type M) cannot be executed directly from the ABAP editor or transaction SA38, the 'ABAP/4 execute program' transaction. To execute a dialog program, create a transaction code using one of the following methods:

From the object list of the object browser: Choose the create button. Choose transaction. Enter a transaction name (customer transactions begin with Z or Y). Choose the create button again.

From the 'maintain transaction' utility (transaction SE93, menu path tools > ABAP workbench > development > other tools > transactions): Enter a transaction name (customer transactions begin with Z or Y). Choose the create button.


Creating Transaction Codes Contd…..

The following steps are the same in either case: Specify the type of program. For dialog programs, choose

dialog. Choose enter. Provide a short description/transaction text. Specify the program name that the transaction will execute. Specify the first screen number that should be called by the

transaction. Authorization object should be specified but is not required. For this case, leave the 'maintenance of standard

transaction variant allowed' check box on (allows specification of a customer defined variant to be used each time the transaction is called - see transaction SHD0).


Creating Transaction Codes Contd…..

Choose save to create the transaction. To execute the program, enter the transaction code you

have created in the system command line with the appropriate system command prefix (/n to overwrite current session with new session, /o to open a new session).


Transaction Types

Dialog transaction: Used to start a dialog program

Report transaction: Used to start a type 1, on-line/report program (can refer to reports, conversion programs, interface programs, utility type programs etc.)

Variant transaction: Used to start a program using a predefined variant

Area menu transaction: Used to start an area menu. Area menus will be discussed with menu painter. Area menus are developed via transaction SE43 and can be used in place of or along with the standard SAP menu (S000). The menu that a user sees when they first logon is defined at the user level in the user profile.

Parameter transaction: Used to start a program to which parameters can be passed.


Dialog Naming Standards

Module pool/program name: SAPMZxxx or SAPMYxxx (where xxx can be freely defined characters)

TOP include: first 5 characters correspond to last five characters of first main program name. Last three characters are TOP. Example: MZxxxTOP

PBO include: first 5 characters correspond to last five characters of main program name. Last three characters are Onn, where 'O' stands for output and 'nn' is a number identifying first, second, etc. Include for PBO modules. Example: mzxxxo01, mzxxxo02, etc.


Dialog Naming Standards

PAI include: first 5 characters correspond to last five characters of main program name. Last three characters are inn, where 'I' stands for output and 'nn' is a number identifying first, second, etc. Include for PAI modules. Example: mzxxxi01, mzxxxi02, etc.

All other includes begin with last 5 characters of main program followed by a three character description.


Defining Elements on the Screen


Dictionary Fields in Dialog Program

To add a dictionary program field to a screen following steps required:

Navigate to Goto > Dict/program fields or simply choose the Dict/ProgFields button from the graphical screen painter within the full screen editor

Enter the table or program that contains the field you want to use, then enter the field name.

Select the field by positioning your cursor on the line retrieved from the dictionary.

Choose the appropriate attributes that you wish to use.


Dictionary Fields in Dialog Program

Choose the copy button and position the field on the screen with the mouse.

When using a dictionary field in a dialog program, the field receives the same attributes as defined in the data dictionary.

Field type and length will be the same as defined by the domain of the field chosen.

All entries to the field will then be verified against the type and permitted values as determined by the domain. If a check table exists, all entries to this field during program execution will be verified in reference to the check table. Invalid entries will produce an error message.


Radio Buttons and Check Boxes in Dialog Programs

Radio buttons are mutually exclusive fields. Radio buttons must be assigned to a graphical group within

which exclusivity is decided. For radio buttons defined by a graphical group, the system only allows one radio button to be activated within that group.

Within the programming logic, radio buttons and check boxes can be interrogated using their field name to determine whether they are active or not. If the radio button or check box has been activated by the user, the value is 'X' (can be read as anything other than space), otherwise, the value will be space.


Icons In Dialog Programs

Icons can be added to text fields in the screen painter by double clicking on the field and assigning one of the icons from the icon list.

Additionally, status icons can be added to the screen (new with graphical screen painter). A status field is an output field with an icon. Status fields are used when the actual icon that will be used is not decided until runtime.

Status icons are assigned via the function module ICON_CREATE (see transaction SE37 for further details). Status icons must have an internal length of at least 6 (6 does not include any text). Visualized length must be at least 2.


The OK Field, Setting The OK-CODE

Every screen by default is given one field of type ‘OK’. The OK field is a PAI field which holds the function code

invoked by the user at runtime. Remember, the start of the PAI is triggered by the user invoking one of the possible function codes (I.E. Enter, save, back, exit, etc.).

The OK field, like SY-UCOMM, can be read at runtime to determine how the program should react.

The OK code field receives the value of the function code defined in the menu (to be discussed with menu painter) or by the function code assigned to a pushbutton in screen painter.


The OK Field, Setting The OK-CODE

You must assign a field name for the OK type field. The OK field can be displayed in screen painter by choosing the ‘field list’ button from the flow logic of screen painter, or by going to field list views -> field types. The OK field is the last field displayed. It has the type OK and no name.

You must define a name for the screen field AND declare a field in the ABAP global data. Within the global data declaration (TOP include) this field can by defined ‘LIKE SY-UCOMM’ or as a four character field. This field is commonly named OK_CODE or OKCODE.

At runtime, this field will receive the value for the function code that was assigned to the option the user chose.


Field Input Validation


Automatic Field Input Validation

Automatic field input checks are carried out at the following levels:

Field definition attributes from the field list Required entry (?), field type (C, N, F, P, I, etc.). Definition of attributes from data dictionary Field type from dictionary must match input (CHAR, DEC,

etc.). If check tables are specified in the domain of the dictionary

field, the entry is validated against the check table.


Automatic Field Input Validation

If the dictionary field's domain has enumerated values, input is validated against these fixed values.

F4 functionality (possible entries) is also available for dictionary fields as defined in the data dictionary.

Automatic field input checks occur immediately after a function has been invoked (I.E. User presses enter) but before the PAI is processed. Additional field input checks can be programmed.

If all entries pass the checks, processing continues with the PAI modules, otherwise message dialog occurs prompting the user for further action.


User Defined Field Input Validation

User defined field input checks can be added to a program in the following ways:

Field input checking in the module pool Within the PAI modules, fields input by the user can be interrogated by the program to determine whether processing should continue. This can be used in conjunction with the flow logic which will determine how the error will be presented to the user and what options they will have for continuing.

Field input checking in the flow logic The limited flow logic syntax also allows for a certain degree of automatic field input checking.


Field Statement for Input Validation


User Defined Field Input Validation Contd.

To perform a field level input check in the module pool, the field statement is used in the flow logic syntax in conjunction with a call to the module where the check is performed.

Use of the field statement opens the associated field for input if execution of the called module results in an error or warning message. The screen is redisplayed without processing the PBO modules for that screen. When the screen is redisplayed, only the field identified in the flow logic prior to the module call is ready for input. All other fields have been changed to display only.

When the user has corrected any errors, processing resumes at the precise point where the failure occurred.


Field Statement for Input Validation


Data Transfer and the Field Statement

Field statements can exist anywhere in the flow logic that preserves the integrity of the process.

By default, data transport of field values from the dialog processor (screen work area) to the ABAP processor (ABAP work area) occurs at the beginning of the PAI event for all values not contained in a field statement.


Data Transfer and the Field Statement

For fields placed within a FIELD statement, values are not passed from the screen to the ABAP work area until the field statement is encountered by the dialog processor.

Any given field can exist in multiple field statements. Values of fields contained in multiple field statements will

remain in the screen work area until all field statements referencing that field have been processed. Values are temporarily transferred to the ABAP processor for the duration of the check performed by the field statement until the last field statement is successfully completed.


Chain Statement

The chain statement is available to allow further control of field input checking.

By using the chain statement, you can control which fields will become ready for input following a negative result from an input checking module.

All fields within the CHAIN, ENDCHAIN statement become ready for input.

Fields can be used in more than one chain and/or field statement.

Additionally, any manipulation of screen fields that may have occurred in the PAI event prior to the field input check will not show up when the screen is redisplayed unless the manipulated fields were part of the chain statement that resulted in an error (or warning).


Chain Statement


Conditional Execution of Modules


ON INPUT / ON REQUEST Overview

Field input checking does not always needed. For instance, if no input value was entered or the value has not changed since last time the screen was executed, there may not be a need to perform field input validation.

Conditional execution of modules techniques allow the developer to control whether field input checking routines should be executed. Two methods are available:

ON INPUT (flow logic) will result in execution of validation processing only if those fields are not at their initial value.


ON INPUT / ON REQUEST Overview

ON REQUEST/ON CHAIN-REQUEST (flow logic) will result in execution of validation processing only if the value of a screen field has changed since the last time the screen was called using.

When utilizing the FIELD statement to perform input checks, using the additional ON INPUT specification will avoid execution of the specified modules unless the fields have a value other than their initial value. Remember, the initial value is dictated by the type definition either in the data dictionary or the screen field attributes.

ON CHAIN-INPUT can be used to check if at least one screen field within a CHAIN ENDCHAIN statement is not at its initial value before processing continues.


On Request / On Chain-request


On Request / On Chain-request

When utilizing the FIELD statement to perform input checks, using the additional ON REQUEST specification will stop the system from processing the specified modules unless the value of the field was changed by the user.

ON CHAIN-INPUT can be used to check if at least one screen field within a CHAIN ENDCHAIN statement has been changed by the user before processing continues


Field Input Checks in the Flow Logic


Module Pool Overview

Limited field input checks can also be performed within the flow logic. The basic commands available are select and values.

Select within the flow logic performs much like the select single used in ABAP/4.

Using the values parameter within the flow logic allows you to enumerate permitted values.


Message Handling in a Dialog Program

(E)rror and (w)arning messages:Have the result of redisplaying the screen where the error occurred, re-opening those fields for input that were part of the CHAIN or FIELD statement that produced the error.

(A)bend messages:The text of an abend message is displayed on the current screen. After the user presses enter, processing ends and the user is returned to the initial screen. This becomes important in the case of database updates and logical units of work (LUW).

(I)nformation messages:Interrupt processing and display on the screen which produced the message. When user hits enter, processing continues from the point of interruption.

(S)uccess messages:Displayed on the next screen.


Parameter Ids and SAP Memory



SAP memory allows for storage of values using parameter ids. If a field is given a parameter ID, its values can be sent to memory or received from memory during runtime.

Values sent to memory reside for the term of the current logon session. Therefore, values can be stored beyond the execution time of one program and can be used by many programs.

SET and GET parameter are used to send field contents to memory and get field contents from memory.



SET parameter id copies field contents to the SAP memory at the PAI event.

GET parameter id retrieves contents of the parameter ID from memory and places them in the designated fields at the end of the PBO event if the field is at its initial value. If the field already contains data from a module performed in the PBO of the current screen, GET parameter will not overwrite the contents.

SET and GET parameter should not be used for intermediate storage in passing values from one program to another because parameter ids are session independent within a user logon. Therefore, it is possible for a parameter ID to inadvertently be set in one session while being used in another.


Parameter Ids and SAP Memory - Example

Many standard SAP programs use parameter ids and SAP memory. Notice that when working with a program in the ABAP/4 editor (SE38), SET and GET parameter are used. Once working with a program in the editor, should the editor be left and restarted, the program parameter will contain the name of the program last worked on. Similarly, the report execution program (SA38), utilizes the same parameter ID. Thus, not only will the name of the last program that was been worked on in the editor default in the program name of the editor after leaving and returning, but it will also display when entering transaction the report execution transaction.


Using SAP Memory in Dialog Programs

In order for SAP memory to receive the contents of fields, SET parameter must be specified for the appropriate fields and parameter ids. Likewise, for fields to receive the contents of SAP memory, GET parameter ID must be specified for the appropriate fields and parameter ids.

Not all fields have an associated parameter ID. Parameter ids are defined at the data element level of dictionary fields. If the field you wish to use SET and/or GET parameter with does not have a parameter ID assigned, you can define one in table TPARA.

In dialog programs, you can specify SET and GET parameter as field attributes. SPA and GPA checkboxes correspond to set parameter and get parameter respectively.


Using SAP Memory in Dialog Programs (Cont.)

In addition to specifying SET and GET parameter via the field attributes of the screen painter tool, SET and GET parameter can be specified in ABAP/4 programs (i.E. In PBO modules).

The above examples indicate the proper syntax for use of SET and GET parameter. Notice the use of MEMORY ID in the above parameters declaration.*

* PARAMETER ID and MEMORY ID are very similar. However, when using SAP memory in the parameters statement, notice the requirement of the key word MEMORY ID rather than PARAMETER ID. Likewise, notice the use of PARAMETER ID in the SET and GET statements. Also, notice the use of single quotes for SET and GET parameter, but no quote when using MEMORY ID.


Additional Field and Screen Attributes


Setting Default Values for Screen Fields

SAP provides three ways to define default values for screen fields in a dialog program:

Utilizing SAP memory and parameter ids: SET/GET parameter

Fields can be defined so as to retrieve data from SAP memory which has been set by the current program or some other program where the same parameter ID was used.

SET and GET parameter can be activated via the field attributes of screen painter or within the ABAP/4 module pool.


Setting Default Values for Screen Fields

Setting default values in the PBO modules (ABAP/4) Additionally, default values can be assigned within the

ABAP/4 modules that are called by the PBO event. This method simply assigns values to the ABAP/4 fields and passes them to the screen fields before the screen is displayed to the user.

Utilizing the HOLD DATA screen attribute to set default values

Much like the field attributes which can be assigned in screen painter, screens also have attributes which can be maintained. When the HOLD DATA screen attribute has been activated, the system stores all screen field values in memory upon leaving that screen. The stored values then appear as default values the next time that screen is called.


Setting Default Values in the PBO Modules (ABAP/4)

In the above example, the PBO event of the current screen calls MODULE INITIALIZTION, which checks to see if a value has been entered in the screen field 'year'. If not (the field is initial), the year is defaulted to the current year. At the end of the PBO event the ABAP/4 field value is sent to the screen field and displayed to the user.


The HOLD DATA Screen Attribute to Set Default Values

From the full screen editor, choose GOTO > SCREEN ATTRIBUTES. By activating the hold data check box, screen field values will be saved. The next time this screen is called, the saved values will again appear.

Copying of saved values to the screen fields will occur after the GET parameter instruction and will therefore overwrite contents set by GET parameter. This is only true if the user has not left the current session, as HOLD DATA is only valid during the life of the current session.


Positioning the Cursor on a Screen

By default, the cursor will appear on the first input field of a screen. However, a default cursor position other than the first field of a screen can be set by the programmer via screen attributes or within the ABAP/4 modules.

Using screen attributes to set the cursor position The screen attributes function of screen painter (GOTO > SCREEN

ATTRIBUTES from screen painter) allows you to specify the desired default cursor position. By placing the field name where the cursor should first appear in the 'cursor position' of the screen attributes function, the new default location is set.


Positioning the Cursor on a Screen (Cont.)

Using the module pool to set the cursor position Cursor position can be set dynamically in the module pool using the

statement SET CURSOR FIELD '<field name>'. Notice that the field name is in single quotes. Field name can be set up

as a variable within the PBO module whose value is the appropriate name. If this method is used, the quotes are not necessary.

When using a variable to hold the field name, the variable must be defined globally.

For more information on SET CURSOR, use the help function of the ABAP editor for the keyword SET.


Additional Screen FIELD Attributes

Field attributes can be maintained via screen painter. If you wish for a field to use a matchcode object from the

data dictionary, you specify the matchcode name in the matchcode field of dictionary attributes within screen painter.


Additional Screen FIELD Attributes Contd…The following is a partial list of field attributes which may be used:

Dictionary attributes SET parameter GET parameter Foreign key check Upper/lower case Program attributes Input/output field Output field only Required field


Additional Screen FIELD Attributes Contd…

Possible entries button Right justified With leading zeros Display attributes Fixed font Bright Invisible 2D display

For a full list of field attributes, choose the FIELD LIST button from the full screen editor.


Menu Painter


Creating a GUI Status Via the Object Browser

Menus (GUI status) allow you to define the processing alternatives a user will have when they come to a screen. When creating a menu, you have the ability to assign functions codes to drop down menus from the menu bar, to buttons in the application tool bars (tool bar always appears at top of screen; I.E. Print, save, etc.), To buttons which will appear across the top of a screen underneath the application tool bar, and to function keys (i.E. F11 for save, shift + F12 for print, etc.)

Menus are crated using the menu painter tool of the ABAP development workbench.

For dialog programs, the menu painter tool is invoked via the object browser by choosing the create button, selecting the GUI status radio button, naming the status, and choosing the create button again.


Creating a GUI Status Via the Object Browser Contd……..

You must specify the status type: SCREEN used for creating a GUI status for a full screen which has a

menu bar, pushbuttons, and input/ouput fields. DIALOG BOX used for screens that do not have a menu bar and that

request only pushbuttons LIST used for a full screen with a menu bar, pushbuttons AND LIST

FUNCTIONS (i.E. Scrolling) List in dialog box is used for a dialog box that contains a list. Menu

buttons available but no menu bar.


Assigning Function Codes

Assigning function codes to GUI status. This can be done in the following areas of the GUI status:

Drop down menus that appear at the top of the screen Standard and application tool bars at top of screen (icon for print etc.) Function keys Push buttons (displayed along top of screen) When creating a GUI status, you have the option of displaying standard

menu options which you can then change and/or add to. To do this, double-click on the button immediately to the left of the test 'display standards' text.

In order for menus to become active, they must be generated after creating them and after each time they are changed.


Assigning Function Codes - Drop Down Menus


Assigning Function Codes - Drop Down Menus II

To define drop down menus, you double-click on the menu you wish to creator modify (from within the menu painter tool after choosing the status type)

You can define up to 6 different drop down menus per GUI status. Each drop down menu can have up to fifteen menu options. Each menu option may have a function code assigned to it by placing a freely defined function code to the left of the test under the FUNC header. Alternately, each menu option may reference a sub-menu which again has 15 menu options.

To create a sub-menu, type the name of the sub-menu in the menu line, do not put a function code, and double-click on the line. The a new menu with 15 possible options will appear. Again, function codes or other sub-menus can be assigned.


Assigning Function Codes - Drop Down Menus II

To add a separator line to a menu line, position the cursor on the line you wish to add the separator to, navigate to EDIT > INSERT > SEPARATOR LINE.

Menu items can be activated or deactivated using the active <-> inactive button of menu painter. If the menu option has been deactivated, the user sees the option but it is greyed out and cannot be chosen.


Assigning Function Codes - Tool Bars


Assigning Function Codes - Tool Bars II

The next section of menu painter allows you to assign function codes to the tool bars at the top of the screen.

The first tool bar is considered the standard tool bar (navigate back, exit, cancel, or print, save, etc.). These buttons should not be changed from their standard use. They can be activated by placing the appropriate function codes in them or removing them.

The application toolbar lies immediately below the standard tool bar. These are the options that appear and are specific to the application the GUI status is used for. These are also activated by placing the function codes in the appropriate places. You can assign an icon to the function codes of the application toolbar. They can appear with text or without.


Assigning Function Codes - Function Keys

The next part of the menu painter allows you to define function codes for the function keys. By placing function codes in the appropriate fields, those function key/code combinations will be activated within the program that references the GUI status.

You define function keys in the 'freely assigned function keys' section of the menu painter.


Assigning Function Codes - Function Keys


Invoking the Menu/GUI Status

Each screen may have a different menu created for it. One screen may even have multiple menus defined for it. The menu that is displayed to the user is specified in the ABAP/4 program.

The GUI status must be invoked in the PBO modules. The proper syntax is SET PF-STATUS '<status name>'. The status must

belong to the dialog program that is calling it.


Setting the Title Bar Dynamically

It is also possible to create title bars which can be set dynamically by the PBO modules. By setting the titlebar in the program the default titlebar taken from screen attributes is overwritten.

Titlebars are created from the object browser like all other objects. Place the cursor on the highest node of the dialog program hierarchical

structure (main program) and choose create. Choose titlebar and give the titlebar a name. Choose create again and create your titlebar.

To set the titlebar in the module, use the statement: SET TITLEBAR '<titlebar name>


Assigning Function Code Attributes & Using AT EXIT-COMMAND

To assign function code attributes, place cursor on function code from menu painter and double click.

‘Exit’ type function codes can be assigned type ‘E’ for exit. This allows use of the AT EXIT-COMMAND statement in the PAI flow logic. AT EXIT-COMMAND is a conditional execution statement. Only when a function code with type ‘E’ is invoked will that module be executed.

All function codes which will be used to allow the user to exit out of the current program should be assigned type ‘E’.

The default function type is blank which allows the developer to freely define how the program will react that function. Additional types are transaction and system. For a full list of available function types choose help from the attribute assignment screen of menu painter.


Updating the Database - ABAP4 Open SQL


Updating the Database - ABAP/4 Open SQL - Overview

There are four commands available for updating the database: INSERT - adds new records to the database table UPDATE - changes one or more fields of specified records MODIFY - changes existing records or adds new ones DELETE - deletes specified table records

With all four options, SY-SUBRC is set to 0 for success and something other than 0 for failure.

When database changes occur, the SAP database triggers a command in the underlying database system.

Updates occur in a sequence of related steps which are grouped together to make up a logical unit of work (LUW).


Updating the Database - ABAP/4 Open SQL - INSERT

INSERT <dbtab> adds the contents of the table work area (defined in the tables statement) to the database table. Note that authorization checks are not supported by the INSERT statement. These must be included by the programmer if required.


Updating the Database - ABAP/4 Open SQL – INSERT II

INSERT INTO <dbtab> VALUES <identically structured work area> adds the contents of the identically structured work area to the table.

Tables: SFLIGHT. Data: FS_SFLIGHT like SFLIGHT. Move 570 to FS_SFLIGHT-MANDT. Move 'LH' to FS_SFLIGHT-CARRID. Move ... Insert into SFLIGHT values FS_flight.


Updating the Database - ABAP/4 Open SQL – INSERT III

INSERT <dbtab> FROM TABLE <itab> adds the contents of the internal table to the database table.

Tables: SFLIGHT. Data: begin of INT_SFLIGHT. Include structure SFLIGHT. Data: end of INT_SFLIGHT. . . Move 570 to INT_SFLIGHT-MANDT. Move 'LH' to INT_SFLIGHT-CARRID. Move ... Append INT_SFLIGHT. . . Insert SFLIGHT from table INT_SFLIGHT.


Updating the Database - UPDATE

UPDATE <dbtab> changes a record in the database table. If not suitable record is found, the update will fail with a return code (SY-SUBRC) not equal to 0.

Note that authorization checks are not supported by the UPDATE statement. These must be included by the programmer if required.

Tables: SFLIGHT. Select * from SFLIGHT Where CARRID like 'l%'. Move '*' to SFLIGHT-CARRID. Update SFLIGHT. If SY-SUBRC NE 0. Message e001 with text-001. "Update failed ENDIF. ENDSELECT. If SY-SUBRC NE 0. Message e001 with text-002. "No records updated ENDIF.


Updating the Database – UPDATE II UPDATE <dbtab> FROM TABLE <itab> changes the corresponding

records of the database table to the values of the internal table.Tables: SFLIGHT. Data: begin of INT_SFLIGHT. Include structure SFLIGHT. Data: end of INT_SFLIGHT. Select * from SFLIGHT into INT_SFLIGHT. Loop at INT_SFLIGHT where ... If INT_SFLIGHT-CARRID = ... Move 'LH' to INT_SFLIGHT-CARRID. Move ... Modify INT_SFLIGHT. ENDIF. Endloop. . Update SFLIGHT from table INT_SFLIGHT.


Updating the Database – UPDATE III

UPDATE <dbtab> SET <field x> = <value> WHERE <field y> = <value> changes only those table fields specified with SET for all records in which the WHERE condition is met.

Tables: SFLIGHT. Update SFLIGHT Set CONNID = '0064' Currency = 'USD' Where CARRID = 'LH' And PLANETYPE = 'a319'. If SY-SUBRC NE 0. Message e003 with text-003. "No records updated ENDIF.


Updating the Database – DELETE

DELETE <dbtab> deletes only the table record with the key which corresponds to the key values of the dbtab work area.

Note that authorization checks are not supported by the DELETE statement. These must be included by the programmer if required.

Tables: SFLIGHT. Move 'LH' to SFLIGHT-CARRID. Move '0064' to SFLIGHT-CONNID. Move '19990324' to SFLIGHT-FLDATE. Delete SFLIGHT.


Updating the Database – DELETE II

DELETE <dbtab> WHERE deletes all table entries for which the WHERE condition is met.

Tables: SFLIGHT. Delete from SFLIGHT Where CARRID = 'LH' And CONNID = '0064'.


Updating the Database – DELETE III

DELETE <dbtab> FROM TABLE <itab> deletes all database table entries for which the key matches one of the keys from the internal table itab.

Tables: SFLIGHT. Data: begin of INT_SFLIGHT. Include structure SFLIGHT. Data: end of INT_SFLIGHT. Select * from SFLIGHT Where ... into INT_SFLIGHT. . . . Delete SFLIGHT from table INT_SFLIGHT.


Logical Units of Work (LUW) and Database COMMIT


Dialog Steps and COMMIT WORK

SAP dialog programs (transactions) are broken down into several dialog steps.

A dialog step consists of the part of the program that begins immediately following the users choice of a function (i.E. Enter, continue, etc.) With the PAI event and ends immediately following the completion of the last instruction of the PBO event for the next screen.

Although several update commands may be included in one dialog step, changes to the database for those commands do not occur until the SAP system issues a COMMIT WORK or a ROLL BACK WORK command. At that point, the database connection is closed.


Dialog Steps and COMMIT WORK

After COMMIT WORK has occurred the database has been transformed to its new state.

In the case of ROLL BACK WORK the database remains in the same state it would be in if no update commands were executed.

In the R/3 system, COMMIT WORK or ROLL BACK WORK commands are processed at the end of each dialog step (after each screen, just before the next screen is displayed) by default.

ROLL BACK WORK, which backs out any database change instructions that have occurred since the last database commit, is executed in place of COMMIT WORK if an append message has been output any time prior to the closing of the database connection for the current COMMIT WORK event.

When a rollback occurs, the system keeps the log entries for the current commit. These entries can be maintained via transaction SM13.

COMMIT WORK and ROLL BACK WORK can both be stated explicitly in an ABAP/4 program and thus will trigger the COMMIT WORK event. This method is used in ASYNCHRONOUS UPDATES.


Logical Unit of Work (LUW)

SAP dialog programs (transactions) are also broken down into logical units of work (LUWs).

A logical unit of work consists of the time time immediately following one database COMMIT through the end of the next database COMMIT. If no specific program instructions specify otherwise (i.E. As in the case of asynchronous update commands), an LUW directly corresponds to a dialog step.

From the functional perspective it is possible that the committing of database changes is not suitable after each dialog step (after each screen). For this purpose, asynchronous updates are possible which allow several consecutive dialog steps to be grouped together into one LUW.


Asynchronous Updates

Asynchronous updates are used when the developer wishes to combine several consecutive dialog steps into one logical unit of work (one database level commit).

Two methods are available for performing asynchronous updates: CALL FUNCTION '<function name>' IN UPDATE TASK - in this case, the

function called is designated as an update type function. All database update commands (INSERT, MODIFY, CHANGE, DELETE) are placed inside the function to be called. Within the program, rather than specifying UPDATE <dbtab> etc., The update function with the relevant open SQL statements will be called. This places the update requests into a log table rather than passing them to the database. All entries remain in the log table until COMMIT WORK is explicitly specified in the ABAP/4 program (syntax: COMMIT WORK). At this point, all update requests placed in the log table since the last COMMIT WORK will be sent to the database. Likewise, if any updates failed in any of the function calls and the program handled the failing return code (IF SY-SUBRC NE 0...) With an append (type a) message, the log entries are flagged with an error and no database changes occur for the current LUW.


Asynchronous Updates Contd……..

PERFORM <subroutine name> ON COMMIT - in this case, the subroutines contain the database update commands. By specifying ON COMMIT, the update requests are not sent to the database until the COMMIT event is triggered by an explicitly stated COMMIT WORK in the ABAP/4. Like calling a function IN UPDATE TASK, any append messages prior to closing the database connection will result in a rollback.


Asynchronous Updates Contd……..

Update functions and subroutines are the same as standard functions and subroutines with the following exceptions:

CALL FUNCTION '<function name>' IN UPDATE TASK: No export parameters can be used when defining the function interface and no exceptions can be raised. When maintaining the update function module via FUNCTION MODULE ADMINISTRATION, update with immediate start (V1) or update with delayed start must be chosen. V1 updates are time critical updates and will occur prior to V2 updates. If an error occurs during the V2 update, the V2 entries as well as any V1 entries associated with the current commit remain in the log table, although the V1 entries will correspond to updates which were committed while the V2 error entries will correspond to uncommitted updates.

PERFORM <subroutine name> ON COMMIT: When using ON COMMIT, no parameter passing is permitted.


SAP Locking Logic


Creating Lock Objects

Lock objects are created in the ABAP/4 dictionary (TOOLS > ABAP/4 WORKBENCH > ABAP/4 DICTIONARY pushbutton or transaction SE11).

You can also defined lock objects in the object browser (TOOLS > ABAP/4 WORKBENCH > OBJECT BROWSER pushbutton. From the object browser click on the dictionary objects radio button from the single objects section of the screen, and click on the EDIT pushbutton.

Customer defined lock objects begin with 'EZ'. By creating a lock object, you create a view for one or more records or

several tables and selected fields. When a lock object is created, the system automatically creates two

function modules. ENQUEUE_<lock object> and DEQUEUE_<lock object>.

Information on existing lock objects can be found in the ABAP/4 dictionary information system.

SAP locking logic


Creating Lock Objects (Cont.)

Two modes are available for lock objects: Exclusive - only one user can have a lock at a time. Shared - only one user can have change access, others may share

access in view mode


Using Lock Objects

Within your program, locks entries must be set and deleted. Locks should be set prior to perform the read access. Locks must be

deleted after the update has been performed. You must also set lock objects to be deleted for the BACK and CANCEL

functions, the system does not do this automatically.


Setting and Deleting Lock Entries

ENQUEUE_,lock object> checks whether a lock was set for the same object. If so, the exception FOREIGN_LOCK is raised. If the object is not locked, the lock is set by the function module.



By specifying _WAIT = 'X', the system automatically continues trying to set a lick at regular intervals until it succeeds or exceeds the time limit set in the profile parameters.



_SCOPE is important in asynchronous updates: _SCOPE = 1 - lock remains in the dialog program _SCOPE = 2(default) - lock is retained for the update

program _SCOPE = 3 - both dialog program and update program

are owners; There are two entries per object



Module ENQUEUE input. Call function 'ENQUEUE_EZ_SFLIGHT' Exporting CARRID = SFLIGHT-CARRID CONNID = SFLIGHT-CONNID FLDATE = SFLIGHT-FLDATE ... _Scope = '2' _Wait = 'x' Exceptions FOREIFN_lock = 01 System_failure = 02. ....



Module DEQUEUE. Call function 'DEQUEUE_EZ_SFLIGHT' Exporting CARRID = SFLIGHT-CARRID CONNID = SFLIGHT-CONNID FLDATE = SFLIGHT-FLDATE ... _Scope = '2'


Dynamic Screen Modification


Modifiable SCREEN Field Attributes

Screen fields and their modifiable attributes are automatically stored in a system internal table named SCREEN.

The initial values of the table fields are set by the attributes defined in screen painter.

To determine the current attributes of the screen from within the ABAP/4 modules, you can LOOP at the SCREEN table where the field is the one you wish to obtain information for to get the value.

You can also change the value by modifying the values in the SCREEN internal table.


Changing Field Attributes in the Module Pool

Screen modifications must be programmed in the PROCESS BEFORE OUTPUT modules.

When reading the SCREEN table, the WHERE condition is NOT supported (you also cannot READ from the screen table).

When modifying screen fields, the value 1 indicates true, or on, and the value 0 indicates false, or off.

SCREEN ACTIVE* = 0 makes the field invisible and not ready for input. It has the same effect as the 3 combined statements SCREEN-INVISIBLE = 1, SCREEN-INPUT = 0, and SCREEN-OUTPUT = 0.

*SCREEN-ACTIVE can only maintained from the module pool as long as it has not been set to invisible in the field attributes of screen painter.


Dynamic Screen Sequence


Determination of Follow-up Screen

Default follow-up screens are set in the screen attributes when a screen is first created.

Screen sequence can be set dynamically at runtime in the module pool. Methods for dynamically setting screen sequence include:

Set screen Call screen Leave screen


Using SET SCREEN to Set Follow-up Screen

SET SCREEN nnnn temporarily overwrites the default next screen with SCREEN nnnn.

After processing of called screen, follow-up screen of calling screen is invoked unless current screen is terminated with the LEAVE SCREEN statement.

Screen nnnn must be in same module pool as calling screen. To leave the current screen for good you can also use

LEAVE TO SCREEN nnnn.


Using SET SCREEN to Set Follow-up Screen

SET SCREEN 0 LEAVE SCREEN and LEAVE TO SCREEN 0 take program back to location that screen was called from.

Set screen 0100. . Set screen 0100. Leave screen. . Leave to screen 0100. . Set screen 0. Leave screen. . Leave to screen 0.


Using CALL SCREEN to Set Follow-up Screen

CALL SCREEN nnnn interrupts the current screen, inserting screen nnnn and any of its subsequent screens.

Called screen nnnn must be a screen in the same module pool as calling screen.

LEAVE PROGRAM can be used to terminate current program and return to the place where terminated program was called.

.

. Call screen 100. . . . Leave program. . .


Calling a Dialog Box (Screen) and Returning

By calling a screen defined as a modal dialog box and specifying STARTING AT and ENDING AT you can specify position and size of the called screen.

If ENDING AT is left out, the size of the dialog box is taken from the ‘USED’ size in its screen attributes.


Calling a Dialog Box (Screen) and Returning

Processing is taken to PBO of called dialog screen. SET SCREEN 0, LEAVE SCREEN could be placed in the program logic of the PAI for the dialog screen to return to the called screen.

.

. Call screen 100 Starting at 20 10 Ending at 60 30. . .

Called screen must be defined as a modal dialog box in the screen attributes


Linking Dialog and List Processing


Linking Dialog and List Processing

By linking program components, dialog (screen) processing and list (report) processing and be combined.

List programs (reports) can call a sequence of screens, and dialog programs can interrupt screen processing to perform list processing.

When called from a dialog program, list processing can occur in a full screen or in a modal dialog box. All interactive reporting techniques (drill-down, list modification, etc.) Are available.


Dialog to List Processing

LEAVE TO LIST-PROCESSING will cause the system to branch from dialog processing to list processing.

All PAI modules of the calling screen are processed BEFORE the list is output to the screen.

In order to invoke the standard list menu, use the command SET PF-STATUS SPACE.

By specifying AND RETURN TO SCREEN nnnn, processing will resume at screen nnnn after list processing. List processing ends when the user has chosen the BACK (F3) command or when the system encounters the LEAVE LIST-PROCESSING statement.


List to Dialog Processing

Within a list processing program, CALL SCREEN nnnn can be used to call a dialog box or a full screen.

The called screen must be a component of the calling program. Specifying LEAVE TO SCREEN 0 from within a module invoked by the

called screen will return control to the calling program.


Table Controls


Table Control Concept

Table controls were introduced as a special screen field type with v3.0. The purpose of a table control is to allow multiple lines (rows) of the

same type to exist on one screen. When declaring screen fields, dictionary fields may only be used one

time on each screen. Table controls are a structure much like an internal table which contains one or more rows of one or more columns.

Prior to v3.0 the STEPLOOP structure was used to allow multiple occurrences of one field type to exist on a screen.


Table Control Concept

Table controls are a significant enhancement to the STEPLOOP concept and have the following characteristics:

Resizable table grid for displaying and editing data Columns can be resized and repositioned by the user Lines and columns can be selected by the user Single, multiple, and ‘all’ line selection possible Columns can be selected by header Horizontal and vertical scrolling Key columns can be fixed Individual field (cell) attributes can be modified at runtime.


Mechanics of the Table Control

To process table controls, data is read from the database into an intermediary internal table in the module pool.

During the PBO event, data is read line by line from the internal table into the control table in screen painter.

During the PAI event, the contents and attributes of the control table are once again fed line by line into the internal table in the module pool, and then if necessary, into the database.

Table controls are created in screen painter like other fields. With the graphical screen painter table controls can be selected and placed on the screen. In the alphanumeric screen painter choose EDIT -> create element -> table control.

From within the ABAP program, the table control is defined of type ‘TABLEVIEW’, which is a complex type structure storing all of the attributes of the control table.


Structure of Table Control

To process table controls, data is read from the database into an intermediary internal table table in the module pool. During the PBO event, data is read line by line from the internal table into the control table in screen painter. During the PAI event, the contents and attributes of the control table are once again fed line by line into the internal table in the module pool, and then if necessary, into the database.

Table controls are created in screen painter like other fields. With the graphical screen painter table controls can be selected and placed on the screen. In the alphanumeric screen painter choose EDIT -> create element -> table control.

From within the ABAP program, the table control is defined of type ‘TABLEVIEW’, which is a complex type structure.


Processing a Table Control

LOOP AT and ENDLOOP statements are used for processing control table in the flow logic.

ON REQUEST determines whether the user has manipulated the control table. If not, no modifying of the control table is necessary.

If the user has made changes, you must reflect these changes to the fields of the table control in the relevant internal table so they appear after the next PBO is executed (user hits enter or scrolls).

By processing the complex structure, field attributes (field selected, visible, etc….) Can be checked and/or changed.

Documents

ABAP Dialog Programming