ABAP Book Module Pool PDF

Training Document
Transactions/Module Pool Programing
Document Name
Module Pool Programming
Section
Version
1.0
2.0
Change
Initial
Table of Contents
Deloitte Consulting India Pvt. Ltd.

Date
12/18/2007
01/08/2007
Changed by
Deloitte Consulting
Deloitte Consulting
GENERAL INTRODUCTION TO TRANSACTIONS ................................................ 4

LOGICAL UNIT OF WORK (LUW)............................................................................. 4
DYNPRO CONCEPT....................................................................................................... 6
SCREEN PAINTER ......................................................................................................... 7
Using Screen painter........................................................................................................... 7
Creating a new Screen ........................................................................................................ 7
Designing of Screen ............................................................................................................ 8
Elements of screen .............................................................................................................. 8
Selecting Screen fields ........................................................................................................ 9
Attributes of Screen Elements ............................................................................................. 9
FIELD LIST .................................................................................................................... 10
SCREEN FLOW LOGIC............................................................................................... 10
PBO event ......................................................................................................................... 11
PAI event........................................................................................................................... 11
POV event ......................................................................................................................... 11
POH event......................................................................................................................... 11
MODULE POOL PROGRAMMING........................................................................... 12
Creation of Module Pool Program ................................................................................... 12
Communication between Dynpro and Module Program .................................................. 12
CREATION OF A COMPLETE TRANSACTION .................................................... 14
Steps involved to create a complete transaction............................................................... 14
Handling Function Code................................................................................................... 14
THE FIELD CHECKS ................................................................................................... 16
Automatic Field Checks .................................................................................................... 16
About at Exit Command ................................................................................................. 17
IN MODULE POOL PROGRAM................................................................................. 17
Flow Logic Validations..................................................................................................... 18
Module assign. ................................................................................................................. 18
Module Pool Program Validations................................................................................... 19
DYNAMICALLY CALLING THE SCREENS ........................................................... 21
About Displaying Next Screen .......................................................................................... 21
Set Screen.......................................................................................................................... 22
Call Screen........................................................................................................................ 23
Leave to screen ................................................................................................................. 23
SUBSCREENS ................................................................................................................ 24
TABLE CONTROLS...................................................................................................... 25

Features of Table Controls ............................................................................................... 25

Declaring of Table Control in the Module Pool Program ............................................... 26
Designing Table Control on Screen.................................................................................. 26
Passing data to table Control ........................................................................................... 27
STEP LOOPS .................................................................................................................. 29
Types of Step Loops .......................................................................................................... 29
BRANCHING TO LIST PROCESSING...................................................................... 31
Switching To List Mode .................................................................................................... 31
Returning back from LIST mode ....................................................................................... 31
HELP & VALUE REQUEST ........................................................................................ 32
Process on HELP-REQUEST event.................................................................................. 32
Value Request.................................................................................................................... 33
CHANGING THE SCREEN DURING RUNTIME.................................................... 37
Need To Change Screen.................................................................................................... 37
Modifying the screen......................................................................................................... 37
ENDMODULE.................................................................................................................. 38
Working with Search Help Objects................................................................................... 39
Creating Search Help object............................................................................................. 39
Defining Search Help object............................................................................................. 39
Creating Search Help IDs................................................................................................. 40
Selecting secondary tables................................................................................................ 40
Using Search Help ............................................................................................................ 41
LOCK OBJECTS............................................................................................................ 42
Creating Lock Objects ...................................................................................................... 42
Types of locks.................................................................................................................... 43
Activation of Lock Object.................................................................................................. 43
EXERCISES.................................................................................................................... 44

GENERAL INTRODUCTION TO TRANSACTIONS

Transaction, in R/3 system is an operation that lets the user make necessary changes to the
database. The entire R/3 system is nothing but a set of business transactions. The data transfer
from old system to SAP R/3 database, or modifying data, or deleting data, which is not required,
is done through transactions.
For SAP system, Transaction is nothing but sequence of steps called as dialog steps and for user it
is sequence of screens that appears one after the other depending upon the option he selects. The
special transaction monitor called the SAP dispatcher handles the sequence of steps that takes
place in any transaction. The main task of a transaction is to update relevant database tables. The
database table is not updated until a transaction is completed. All changes can be rolled back if
the transaction has not finished.
The transaction contains two steps which are as following:
Interactive phase: In this step, user enters the data, which needs to be inserted or deleted
or modified on to the screen. There can be single screen or multiple screens depending
upon the transaction. So this step can consist of single step or multiple steps. In this
phase you prepare database record.
Update phase: This phase processes the database record and updates the database table.
Actual updating of database table takes place in this phase.
All the transactions are associated with transaction code. And all these codes are stored in a table
TSTC.
Logical Unit of Work (LUW)

The R/3 system is multi user system and many users access the same information at the same
time, which is mainly DATA. Consider the case where one user is modifying a record, and
second user is trying to delete the same record. If the second user is successful in deleting the
record then the first user will face problem for modifying the record that is already deleted. To
avoid such a situation, R/3 system has provided Logical Unit of Work, which is defined as a
locking mechanism to protect transaction integrity. Of course, there are other measures, which

ensure data integrity like check table i.e. foreign key relationship. Within SAP system there are
three types of transactions and may be distinguished as:
Database transaction known as LUW. It can be defined as a period in which operation

requested must be performed as a unit, i.e. all or nothing operation. At the end of LUW,
either all of the database changes are committed or rolled back.
Update transaction or SAP LUW. One SAP LUW can have several database LUW. So a
set of a database is either committed or rolled back. The special ABAP/4 command
COMMIT WORK, marks the end of a SAP LUW.
ABAP/4 transaction. Is made up of a set of related task combined under one transaction
code. ABAP/4 transactions are for programming environment, in which ABAP/4
transaction functions like one complete object containing screens, menus and transaction
codes.
R/3 system has provided in built locking mechanism, which defines the Logical Unit of Work.
Also user can set his own locking mechanism. The LUW starts when a lock entry in the system
table is created, and it ends when the lock is released.
To provide the user the facility to communicate with the table in order to modify or delete or
insert data, R/3 has provided tool called SCREEN PAINTER. This tool allows you to design
screen, process screen through program and update the database table. Many standard
transactions are available to update standard table but if the need arises, the developer should be
able to develop new transaction, which allows the updating of database tables. This can be
achieved by using various components of screen painter.

Following are the few concepts and steps for creating entire new transaction.
Dynpro concept
A Dynpro refers to the screen + flow logic. With screen painter you can develop screen
and flow logic. The relationship between screen, flow logic, and program can be shown
as follows:
Flow logic
Screen 100
Flow logic
Module Pool
Program
Screen 200
Flow logic
Screen 300

Dynpro, as figure indicates consist of screen and flow logic and places exactly one call to module
pool program. A transaction consists of many screens and for each screen flow logic is attached.
When the transaction is executed, the screen places a call to flow logic and flow logic in turn
places a call to module pool program.
A module program is an usual ABAP/4 program that consist of modules and data
declaration.
ABAP/4 is an event driven language. In module pool program too, events get triggered
and these events are handled in flow logic. Flow logic editor is subset of ABAP/4 editor.
The system automatically displays the two important events for the flow logic.
Screen is the important component of Dynpro and can be created, designed by screen
painter.
Screen Painter
A screen painter can be started by
Development workbench Screen Painter
Or
SE51 transaction code.
Using Screen painter

The process of creating a dynpro (screen) includes the creation and definition of all the needed
screen components.
The steps involved in creating the dynpro (screen) are as follows:
Create screen and attributes by using screen attribute screen.

Select and place the needed fields within the screen by using dict/program fields.
Establish the field attributes to which the screen belongs by using field list.
Define the flow logic respect to the transaction to which it belongs by using flow logic.
Creating a new Screen

Steps involved are as follows:
Enter the name of program and number of the screen

Click on Create
On screen attribute screen enter short description
Enter screen type. Normally, you select NORMAL option for usual R/3 screen. Other
options available are SUBSCREEN & MODAL DIALOG BOX. Modal dialog box is

used to establish independent and interactive dialog box while sub screen is screen within
screen( a subscreen does not have its own OK_CODE ).
Next attribute to be passed is NEXT SCREEN. Here you need to specify the next screen
number, which must be processed after the current one.
Designing of Screen
Screen can be designed by using FULL SCREEN EDITOR. You can go to full screen editor.
From screen attribute screen
By pressing full screen editor pushbutton
Or
From initial screen of screen painter.
There are two modes available with full screen editor.
Graphical mode. The graphical mode works similarly to typical windows application.
Alphanumeric mode (rarely used).
Elements of screen
Text Standard text or field labels.

Entry - Display field.
Radiobutton Radiobuttons must be associated with a group.
Checkbox Normally used for YES/NO operations.
Pushbutton Used for activating particular function ( Examples are CREATE,
CHANGE or DISPLAY ).
Boxes grouping together many screen elements.
Sub screens This is a screen area in which you can display another screen.
Table controls This is used for having a tabular input format. A typical example for the
usage of a table control would be the entering of Line Item Details
Status - Display output fields containing icon.
All these elements are on the control bar of full screen editor and can be placed on the screen
work area by clicking and placing them wherever needed.

Selecting Screen fields

Screen field can be either dictionary objects or program fields. Steps involved in the placing of
fields on the screen are as follows:
Click the pushbutton Dict/program fields on the full screen editor
Or
Goto dict/prog fields.
Enter table name.

Click Get from dictionary.
Select fields.
Click copy pushbutton.
Position the cursor where you want those fields to be placed.
To adjust various screen elements, you can use drag and drop facility for screen elements.
Attributes of Screen Elements

The entire element of a screen has some attributes, which determines their behavior.
General These attributes are directly managed by the screen painter like name of the
element, or text of element or column width and various things associated with the
screen.
Dictionary These attributes are applicable to fields, which are from dictionary. Various
components of dictionary can be attached to this element like search help, foreign key.
Program.
Display Behavior of the element with respect to their display feature.
Attribute dialog box can be displayed by
Clicking on the ATTRIBUTE push button on the application tool bar.

Double clicking on the element.

Field List
This list displays a list of all screen elements together with their screen attributes. One important
element of Field list is OKCODE. Push buttons are associated with a function code ( Menu Items
are also associated with their function codes ). When the user clicks the pushbutton this code is
stored in OKCODE. This OKCODE is created by system without a name and is not visible on the
screen. In ABAP/4 this field is work field and is nothing but an area wherein system stores the
variable and is the last field of the field . A name might be given to the OKCODE so as to access
its value in different screens. It is always advisable to have different names for the OKCODEs of
different screens. The system field which stores the same value as the OKCODE is SY-UCOMM.
Screen Flow Logic

You can go to this screen either by
Initial screen of Screen painter Flow logic
Or
From Screen attribute screen Flow logic
When transaction is executed, the screen is displayed, user enters few fields, selects few
functions. Later the screen is processed and processing of screen is done by flow logic. The
events that are associated with screen are as follows:
Process before Output (PBO)

Process after input (PAI)
Process on value request (POV)
Process on help request (POH)
The system automatically displays two very important events or modules in flow logic i.e. PAI
and PBO

10
PBO event
This event is triggered before the screen is displayed. The processing of screen before the display
of screen is done in this event. In otherwords, a call to any screen always causes the PBO event of
that screen to trigger first. A typical example of the application of the code present in the PBO
event would be defaulting of certain fields on the screen, or changing the display attributes of a
field on the screen( such as making it input enabled/disabled).
PAI event
This event is responsible for processing of screen after the user enters the data and clicks the
pushbutton i.e when the user performs any action on the screen (typically causing a change in the
SY-UCOMM or OKCODE value). The processing within the PAI event can include a variety of
operations such as displaying another screen, just displaying list or quitting the transaction itself
etc. OKCODE plays an important role in the PAI event since the course of action or processing
largely depends on the OKCODE value (OKCODE gives an indication as to what user action has
been performed and therefore what subsequent processing is to be done )
POV event
Process on value request is triggered when the user clicks F4 key. You can handle this event
when the user presses F4 key by writing code for the same in module pool program. Normally
when the user presses F4, list of possible values is displayed. The standard list produced by
system is adequate for applications you develop yourself. However, you can also have the option
of setting up your own documentation and lists of possible values that are more detailed.
POH event
Normally when the user places the cursor on the field and presses F1 function key, the system
displays its own Help for that particular field. You can add your own functionality to the Help
button by writing code for the same in the POH event.

11

This component though is not attached to the screen painter, plays important role in transaction.
Normally, for reports, on line executable programs are written but for transaction, Module Pool
Programs are written. The module pool program contains only modules to handle various events
associated with screen and data declaration statements.
System divides the module pool program into several include program. It is upto the developer to
decide upon the includes that are used. For example a general practice in module pool
programming is to have a TOP include for all the data declarations, a separate include for all the
modules in the PAI event and a separate include for all the modules in the PBO event.
NOTE : These include statements are inserted into the main program of the Module Pool.
Creation of Module Pool Program

You can create module pool program either through
Object browser
System automatically creates the module pool program and for these program which are created
through object browser, system creates the include modules.
Or
ABAP/4 editor
It is similar to normal program creation. Type of program should be given M and is not created
by system.
Predominantly SE80 transaction may be used since it gives the ability to navigate through the
different elements of a module pool program ( such as the screen, includes, modules etc. )
Communication between Dynpro and Module Program

For each screen, the system executes the flow logic, which contains corresponding events. The
control is passed to Module Pool Program. Module Pool Program handles the code for these

12
events and again passes back control to the flow logic and finally to screen. Typically, the
modules that are to be executed are placed in sequence in the flow logic. The code for the
modules is given in the module pool program (includes).
For example.
FLOW LOGIC
PBO
MODULE PREPARE_DISPLAY.
MODULE FETCH_DATA
The above code is written in the flow logic part which determines the sequence of operations in
the PBO event i.e. first prepare the fields for display and then fetch the data from the database
tables.
The code for these modules may in turn be present in one of the includes of the module pool
program. Hence the flow logic passes the control from the FLOW LOGIC to the module pool
program to execute the code for the module.
INCLUDEPBO1 (In the module pool program)
MODULE PREPARE_DISPLAY
Loop at screen.
If screen-name = NAME.
Screen-input = 0.
Modify screen.
Endif.
Endloop.
ENDMODULE
Unlike in on line program, in this case, the control remains with flow logic. The switching of
control between flow logic and module pool program and back is common process when user
executes transaction.

13
Creation of a Complete Transaction

Steps involved to create a complete transaction
Create module pool program.

From screen painter create screens.
Write flow logic for each screen.
Write code for all the events in module pool program.
Check for any error in screen and flow logic.
Generate each and every component of screen i.e. flow logic and screen.
Single screen can be tested using Screen Painter.
Create transaction code through object browser.
Generate the transaction code.
User can execute the transaction by entering the transaction code in the command field.
Handling Function Code
The function code or OKCODE is the last field of Field list. Function code can be handled as
follows:
During the Designing of the screen, a function code is assigned to pushbutton.
In field list, developer needs to specify OKCODE as last field.

In module program it is a global field and can be evaluated in the PAI event.
A function code is treated in the same way, regardless it comes from pushbutton, menu
item or any other GUI element.
A complete example for transaction is shown below:

If you have a screen like the one below:

14
When the user clicks on the Display button, you want to display details of sflight, with
corresponding carrid and connid (which is entered by the user).
Module pool program to handle this particular screen is as follows:
Program YVTEST7.
TABLES: SFLIGHT.
DATA: OKCODE TYPE SY-UCOMM.
MODULE INPUT1 INPUT,
CASE OKCODE.
WHEN DISP.
SELECT * FROM SFLIGHT
WHERE CARRID = SFLIGHT CARRID AND
CONNID = SFLIGHT CONNID.
ENDSELECT.
LEAVE TO SCREEN 200.
WHEN EXIT.
LEAVE TO SCREEN 0.
ENDCASE.
ENDMODULE.
INPUT1 INPUT
MODULE USER_COMMAND_0200 INPUT.
CASE OKCODE.
WHEN BACK.
ENDCASE.
ENDMODULE.
USER_COMMAND_0200 INPUT

15
When the user clicks on display, control is transferred to screen no. 200 on which you display
sflight details & on the same screen, when user clicks on BACK button, he comes back to main
screen.
Flow logic for screen 100 is as follows:
PROCESS AFTER INPUT.
MODULE INPUT.
Flow logic for screen 200
PROCESS AFTER INPUT.
USER_COMMAND_0200.
MODULES: Modules are handled in module pool program.
You need to write flow logic for screen 200 and design screen 200.
In case of transaction transfer of data from program to screen is automatic i.e. you need not
transfer the data from program to screen explicitly. The fields, which you define in the screen
receives the data from program and displays the same.
The Field Checks

As already mentioned Transaction is the only method, which SAP recommends to update the
database tables. Data entered in the database table should be valid and correct. Data entered is
validated at each and every point. ABAP/4 offers various methods to validate data and those are
as follows:
Automatic field checks

Checks performed in the flow logic
Checks performed in the ABAP/4 module pool program
Automatic Field Checks

These checks are based on the field information stored in the dictionary. These checks are
performed by the system automatically when the user enters the data for the screen field. System
performs these checks before PAI event is triggered. Types of field checks performed by system
are as follows:
Required input

16
While designing the screen, for particular screen field if you click the Req. Entry checkbox, the
field becomes mandatory. When the transaction is executed if user leaves this particular field
blank, the system displays error message. User cannot proceed until the user enters some data.
Proper Data Format

Each field has its own data format whether it is table field or screen field. Whenever data is
entered, system checks for the proper format of the data. For example date. Each user has its own
format for date, which is defined in the user master record. If the date defined in the user master
record is in the format DD/MM/YYYY, if the user enters the date, say, in YY/DD/MM, the user
displays the error message. System also checks for the value of month or days. For example if
month entered is greater than twelve then the error message is displayed.
Valid Value for the Field

In data dictionary two tables are related by Primary key-Foreign key relationship. Whenever the
user enters the data, the system checks for the check table values. Also in Domain, if you have
fixed values, then the system checks for these values.
Automatic field checks are repeated each time the user enters the data.
About at Exit Command

Automatic field checks can be avoided by AT EXIT-COMMAND, which works exactly
the same way as Cancel works on application tools bar. In the R/3 screen, if you want to
quit the processing of that particular screen without entering the mandatory fields, user
can click the Cancel button. Same functionality can be incorporated in the user-defined
transaction by using AT EXIT-COMMAND. This module can be called before the
system executes the automatic field checks and it goes without saying that before PAI
event. Code for AT EXIT-COMMAND in flow logic and in module pool program can be
written as follows:
In Flow Logic
Process After Input.

Module exit AT EXIT-COMMAND.
In module pool program.

Module exit.
Case okcode.
When Exit.
Leave to screen 0.

17
To achieve this kind of functionality a pushbutton or menu item should be assigned a

function type E. It tells the system to process this particular module before carrying out any
field checks.
Flow Logic Validations

Consider the case where you want user to enter only LH and SQ for sflight-carrid. In this case,
you are restricting value of a screen field. This cannot be achieved by automatic field check.
Hence there is a need of additional validation. It can be done in flow logic by using following
statement:
Field --------------- Values
Syntax
PAI.
Field sflight-carrid values (LH).

For multiple values
PAI.
Field sflight-carrid values (LH SQ).

Field sflight-price values (between 1000 and 2000).
In this case when the user enters the value, PAI is triggered and field is checked for that
particular value. If the value entered happens to be wrong, that field is enabled for user to enter. If
you have multiple Field statements in your flow logic, it is sequential execution.
Consider the following case:
PAI.
Module assign.
Field sflight-carrid values (LH SQ).
In ABAP/4
Module assign.
Data: carrid1 like sflight-carrid.
18
Carrid1 = sflight-carrid.
Endmodule.
In this case, Sflight-carrid is used in the flow logic before the field statement. The system will
give invalid value or some previous value as the field sflight-carrid is used in module before it is
checked i.e., field statement is after the module in which sflight-carrid is being used. The field is
not available to the system unless it executes the field statement. Field statement transfers the
values to the program and is done only once. If you dont have Field statement in your flow logic,
transfer of values takes place in PAI event.
Consider one more case where you have multiple field statement.
PAI.
Field Sflight-carrid values (LH).
Field Sflight-connid values (0400 0500).
In this case if the user enters only carrid wrong, then this particular field is enabled and rest of the
fields are disabled for user to input. Many times if the user enters wrong value for one field, then
you might want to give option to user to enter all the fields, which is not possible by using Field
statement only. This functionality can be achieved by CHAIN ENDCHAIN.
Syntax
Chain.
Field sflight-carrid value (LH).
Field sflight-connid values (between 200 and 500).
Endchain.
Field sflight-price values (100 1000).
In this case, if the user enters wrong value only for carrid, both the fields i.e. carrid and connid
are enabled as they are grouped together in the Chain statement. The field price will be disabled
for input. Usually, logically related fields are grouped together with Chain-Endchain statement.
Module Pool Program Validations

Checking fields ABAP/4 program includes

19
Field statement in flow logic.

Module statement in ABAP/4 module pool Program.
Syntax
PAI.
Field sflight-carrid module <name>.
This module can be handled in the main program i.e. module pool program.
In ABAP/4 program
Module Check.
Select single * from sflight where carrid = sflight-carrid.
If sy-subrc ne 0.
Message e001.
Endif.
In this case, field sflight-carrid is checked in the table for its existence.

20
Dynamically Calling the Screens

About Displaying Next Screen
Transaction is a sequence of screens, which are displayed one after the other. The next screen
displayed depends upon the attributes of first screen. In attributes you need to give Next Screen
number i.e. if next screen displayed should be 200 screen, then this number should be given in
next Screen attributes. These are static attributes of the screen. By default, if nothing is specified
in the program, the system branches out to the screen number, which is specified in the attribute
screen.
But this doesnt happen always. If you have many pushbuttons on the screen like the one in the
following case:
In this case, if user selects MARA pushbutton, then fields from Mara table are displayed.
When the user clicks on the MARD, then the fields from MARD table are displayed.
Depending upon users selection, the screen is branched out and this has to be done during
runtime. This functionality can be achieved by dynamically calling the screen in module
pool program.

21
The screen can branch out to new screen depending upon user selection. Following command in
module pool program can do this:
SET SCREEM
CALL SCREEN
LEAVE TO SCREEN <NUMBER>

All these commands override the specifications given in the attributes. This overriding is
temporary. The values stored in the attribute are not changed.
Set Screen
Syntax
Set screen <number>.
In module pool program
Case okcode.
When DISP.
Set screen 200.

When LIST.
Set screen 300.

Endcase.
In this case, the entire processing of current screen takes place and then the system branches out
to next screen. If you want to branch out to the next screen without processing the current screen,
LEAVE SCREEN should be used along with the SET SCREEN.
For Example:
Case okcode..
When DISP.
Set screen 200.

Leave Screen.
When LIST.
Set screen 300.

Leave Screen.
Endcase.
22
When SET SCREEN is used, control cannot be transferred to the main screen or previous
screen, unless you write code for the same.
Call Screen
Usually used for pop up screens. Many times, there is a need for user to enter additional
information or secondary information on another screen or pop up screen. Once the user enters
the data, he should be able to go back to main screen or to the screen where he started. This is not
possible by using SET SCREEN. CALL SCREEN achieves this functionality.
Syntax
Call Screen 200.
Will simply call a screen number 200 from a main screen. Once the screen is displayed the user
can enter all the data and return to the main screen by clicking BACK button.
To call screen as pop up screen the syntax is
Call screen starting at <col.no.> <line no>

Ending at <col no> <line no>.
In this case window will be popped as window and user can close it by using BACK button.
Leave to screen
To SET a new screen without processing current screen, you need to use the following two
statements together:
SET SCREEN 200.

LEAVE SCREEN.
Or a Single statement

23
Subscreens
A subscreen is a screen within screen. Consider the following case.
If user clicks on FIRST pushbutton, you want to display details of MARA table and if user clicks
on the SECOND pushbutton, you want to display details of MARD table. You can do this by
calling two different screens. But the information will be displayed on the next screen. Displaying
data on the same screen is possible by using SUBSCREENS.
Step to create a subscreen are as follows:
Create a subscreen area on MAIN screen and name it.

Create a separate screen of subscreen type.
Arrange the fields on this screen so that they fit in subscreen area exactly. Only when it is
larger, the part of the screen that fits in the main area will be visible.
Write code for calling subscreen in flow logic.
To call subscreen, from your flow logic, you need to include the statement both in PAI and PBO.

24
Syntax
PBO.
Call subscreen <area> including <prg name> <screen no>.

PAI.
Call subscreen <area>.
Area - is the name of the area on main screen.
Prg. Name - is the name of the module pool program.
Screen number - is subscreen screen number.
Some of the donts with subscreen are:
GUI status cannot be set to the subscreen
OKCODE is not applicable to the subscreen.
Subscreen cannot call another screen.
It cannot contain AT EXIT-COMMAND.

You can call multiple subscreen in the same area (at any given point of time, only one
subscreen can be called in the subscreen area) and is done dynamically during runtime by
using variable screen number.
Table Controls
A table can be created in transaction. These tables when designed on the screen are called as
SCREEN TABLES. These screen tables are of two types viz.
Table controls
Step loops
Though these are tables when code is written to handle them, the tables are treated as loops.
Features of Table Controls
Data is displayed in the form of table when many records match the criteria.

25
Table control gives user the feeling of an actual table.

You can scroll through the table vertically and horizontally.
You can select rows and columns
Resize the width of a column
You can have separator lines in between rows and columns
Automatic resizing of the table when the user resizes the window.
In general table control includes all the features of an actual table and user gets the feeling that he
is actually working with table. You can update information in table control and it can be updated
in the database table by writing code for it.
Steps associated for creating complete screen table are as follows:
Declaration of table control in module pool program.

Designing of table control on the screen.
Passing data to table in flow logic.
Declaring of Table Control in the Module Pool Program

Syntax
Controls TCL type Tableview using screen <screen no.>

When you use table control in a screen you must declare the structure in module pool program.
Important fields of tableview are as follows:
Lines number of displayable rows in a table.

Top_line the row of table where the screen displays start.
Current_line The row currently being processed inside a loop.
When you process the table control in flow logic depending upon where you want to start display
of rows, you need to use these variables.
Designing Table Control on Screen
To design table control on the screen, you need to click on Table in control bar and place
it on the screen. You can adjust the length and width of table control.
Name the table control. (Here you need to use same name which you have used for
declaration of table control in module pool program)

26
From dictionary object/program fields, select table fields and place them in the table
control.
Passing data to table Control

As already mentioned, table controls are tables but are treated like loops. Usually transfer of data
from program to screen is automatic. But in case of table control, transfer of data is not automatic.
You need to explicitly transfer the data to table control. ABAP/4 provides loop statement, which
is associated with flow logic to transfer the data. Because table control is treated like a loop, data
from where it is transferred should be a loop. You cannot transfer the data by only select
statement; you need to put the data into internal table. ABAP/4 provides the LOOP statement,
which is associated with the flow logic and allows you to loop through the table control and
internal tables. In between LOOP-ENDLOOP, you can use most of the flow logic keywords like
field values. Module etc.
You need to code a LOOP statement in both PBO and PAI event of the screen. With LOOP
statement, you can transfer the data from program to table control and vice versa. That is, if user
updates the value in the table control, you can update database table with its value. And this can
be done in PAI event. So even if you are not updating database table through the table control,
you need to put the LOOP statement in the PAI event also.
Syntax
PBO.
LOOP AT <internal table> with control <table control name> cursor <scroll variable>
PAI.
Loop at itab.
Proper usage of Table Control is as follows:
In flow logic.
PBO.
LOOP AT ITAB WITH CONTROL TC1 CURSOR TC1-TOP_LINE.
MODULE ASSIGN.
ENDLOOP.
PAI.
27
LOOP AT ITAB.
ENDLOOP.
Considering, we have following fields in table control and the screen looks like this:
CONTROL TC1 Type tableview using screen 200.

Module assign.
Sflight carrid = itab carrid.
Sflight - connid= itab - connid.
Sflight - fldate= itab fldate.
Endmodule.
The transfer of the data from program to table control takes place in steps and these steps are as
follows:
With LOOP AT statement the first row is picked up and placed in the header of the
internal table.
Whatever statements you have in between LOOP-ENDLOOP are executed. In this case,
you have Module statement. In Module statement, value of internal table is assigned to
table control field.

28
The row in internal table is transferred to the first line of the table control as stated in the
LOOP AT statement.
The system encounters the ENDLOOP statement and Control is passed to the next line of
the internal table.
In the same way, all the records of the internal table are passed to the table control.
STEP LOOPS
Step Loops are type of screen table as already mentioned. Step loops are repeated blocks of field
in a screen. Each block contains one or more fields and these blocks are repeated. Step loops
arent like actual table. You can scroll vertically but not horizontally. Three steps are associated
with creation of step loops:
Creation of step loops on screen, which includes declaring fields on the screen and then
defining the step, loops for these fields.
Passing data to the step loop is exactly similar to the passing of data to table controls.
In step loop, you dont need to define the step loop as such in the module pool program
but the cursor needs to be defined in the program.
Types of Step Loops
Static Static Step Loop (SSL) have fixed size that cannot be changed during the
runtime. If user resizes the window, the size of the static step loop is not changed.
Dynamic Dynamic Step Loop (DSL) is variable in size. When the user resizes the
window, the system increases or decreases the number of the step loop blocks.
You can have only one dynamic step loop and can have as many static loops in your
transaction.
Programming with the Static and dynamic step loop is exactly same. For the system or for the
user it doesnt make any difference whether it is static or dynamic step loop. Only attribute,
which you fix during designing of the step loop, is type attribute for step loop F for fixed i.e static
and V for variable i.e. dynamic.
Writing code for Step Loop in the flow logic.
PBO.
Loop at itab cursor cl.

29
Module set.
Endloop.
PAI.
Loop at itab.
Endloop.
* Empty loop is must for both table control and step loop
LOOP AT statement for step loops and Table controls is similar. Loop At statement
transfers the data to screen table. You need to have the Module to assign the values for
the screen table.
In module pool program you need to define the cursor.
Date: CL TYPE i.
* Cursor parameter tells which line of step loop display should start.
Module Set in module pool program assigns the values to step loop fields, which is similar to
table controls.

30
Branching to List Processing

Switching To List Mode
You can display a list within a transaction.
You can produce a list from module pool program by using the command
Leave to List-Processing.
This statement switches the system from dialog mode to list mode. And from this point onwards
until you return to dialog mode, you can use all the normal report statement like write, select or
any other event.
Returning back from LIST mode

You can return back to dialog mode by clicking the BACK button.
You can have your GUI status and write code for the same. You can include the
command LEAVE LIST-PROCESSING. When the system reaches this command, it
leaves the list mode and returns to the dialog mode.

31
Help & Value Request

In any transaction, When the user presses F1 or ? on a field, System provides the help
facility for that particular field. In dialog program, when F1 is pressed, help provided by
R3 system is sourced from data element documentation. If this documentation is not
present for that particular field or if user needs to display additional information for that
particular field, then user defined help can be provided through PROCESS ON HELP
REQUEST.
In ABVP/4 help can be provided to the user by:
Data element documentation: The F1 help can be enhanced, by adding an additional text for the
data element in ABAP/4 dictionary.
It can be done with the help of following steps:
Place cursor on the screen field,
GOTO DOCUMENTATION DATA ELEMENT DOCUMENT
You can now extend the existing help.
USING THE PROCESS ON HELP-REQUEST.
If you dont have this event in a program, then the documentation of the field in the ABAP/4
dictionary is taken into consideration. If this event exits in the program then it is executed.
Process on HELP-REQUEST event

This event is triggered when user presses F1 on a screen field. You need to handle this event in
flow-logic by specifying the fields and attaching the module to it.
Syntax
PROCESS ON HELP REQUEST.
FIELD SFLIGHT-CARRID MODULE HELP-FOR-CARRID.
MODULE HELP.
Write : `This is field is from sflight table
Write : / It is of four Character.
ENDMODULE.

32
When the user presses F1 on this particular field, then this message will be displayed on the
screen.
Value Request
Whenever the user presses F4 on the screen field list of possible values, particular fields are
displayed. If the standard value-help is inadequate or if you want to display additional fields or
with different combination of fields, developer can program this in PROCESS ON VALUEREQUEST event in the flow-logic and subsequent module in the module pool program. When the
user presses F4, list of possible values are displayed either from Search Help objects or check
table or help view or domain. Each one of them is explained briefly.
Search Help objects: Are aggregated dictionary objects and detailed procedure to create these
objects is explained in the later part of the material.
Check Table: If a check table is assigned to the table field and if the user presses F4 for that
particular field, then all the key fields are displayed.
Domain Values: The values defined in the domain are displayed. These values are set in domain
when the domain is created in the dictionary.
Help views: In cases where the check table is not sufficient, you can create a help view with this
check table, which gives additional information like explanatory text for the fields of the check
table.
PROCESS ON VALUE_REQUEST.
Each time the user presses F4 on the screen field, following algorithm is called internally.

33
Does this field have its own F4

module in the Screen Painter?
Execute
the module
Search Help object

in the Screen
Execute
help
SearchHelp
Check table?
Domain
values?
Help view for the

check table?
Display
help view

N
Y
Display
check
Display domain
values
Message ``No
display of possible
entries here
34
When the user presses F4 on flight number, the following screen is displayed.
The screen displayed is pop-up screen and code for the flow logic and module is written
below:

35
Flow-logic code
PROCESS ON VALUE-REQUEST.
FIELD SFLIGHT-CONNID MODULE HELP-FOR-CONNID.
Code for module pool program.
MODULE HELP-FOR-CONNIDINPUT.
DATA: BEGIN OF ITAB OCCURS 0,
CONNID(50),
END OF ITAB.
REFRESH ITAB.
ITAB-CONNIDI= POSSIBLE VALUES FOR CONNECTION ID.
APPEND ITAB.
SELECT CONNID FROM SFLIGHT INTO TABLE ITAB.
CALL FUNCTION POPUP_WITH_TABLE_DISPLAY
EXPORTING
ENDPOS_COL =
45
ENDPOS_ROW
=
25
STARTPOS_COL
=
10
STARTPOS_ROW
=
1
TITLETEXT
=
TEXT
IMPORTING
CHOISE
=
Some Integer Variable
TABLES
VALUETAB
=
ITAB
EXCEPTIONS
BREAK_OFF =1
OTHERS
=2.
ENDMODULE.
HELP-FOR-CONNID INPUT

36
Changing The Screen During Runtime

The attributes are assigned to the screen field when the screen is designed in full screen
editor. Such kind of assignment is static, which means that these attributes are fixed. But
many times the need to change the attributes of the screen arises. And this has to be done
during runtime.
Need To Change Screen

There can be a requirement in the transaction that, certain fields on the screen
Appear only in certain conditions.
Are in Change/display mode according to user inputs
Become mandatory subject to specific inputs.
Changes its format depending upon certain conditions.
Modifying the screen

At the runtime, attributes for each screen field is stored in system defined internal table,
with header line, called as SCREEN TABLE. It contains name of field and its attributes.
This tab le can be modified during the runtime i.e. through module pool program. Screen
table has following fields:
Field Name Length

NAME
GROUP1
GROUP2
GROUP3
GROUP4
ACTIVE
REQUIRED
INPUT
1
OUTPUT
INTENSIFIED 1
INVISIBLE
LENGTH
DISPLAY 3D
30
3
3
3
3
1
1
1
1
1
1

Description
Name of screen field
Field belongs to field group1
Group 2
Group 3
Group 4
Hide/Show
Field input is mandatory
Enable/Disable
Field for display only
Field is highlighted.
Field is suppressed.
Field output length is reduced
Field is displayed with 3-D Frame
37
VALUE_HELP
Field is displayed with Value help
E.g., SCREEN-ACTIVE = 0
SCREEN- INPUT
= 0.
SCREEN-OUTPUT = 0.
SCREEN-INVISIBLE = 1.
The fields SCREEN-NAME and SCREEN-GROUP 1 through SCREEN-GROUP4 tell you
which field and / or field group has the attributes.
You can assign up to 4 groups to a field.
You need to program screen modifications in module, which is processed during the event
PROCESS BEFORE OUTPUT.
`SCREEN is an internal table with header line and, in order to change the field values,
LOOP statement has to be used so that the header-line can be populated with the new
values, changing the earlier values, the SCREEN table consisted for the specific screen.
Finally the changed record in the header-line is NOT APPENDED, but is MODIFIED to
the SCREEN table. That is, we first use `LOOP AT SCREEN and then assign the values.
And finally PRIOR TO ENDLOPP give `MODIFY SCREEN.
PROCESS BEFORE OUTPUT.
MODULE MODIFY_SCREEN OUTPUT.
MODULE MODIFY_SCREEN.
LOOP AT SCREEN.
IF SCREEN-NAME = SFLIGHT-CARRID.
SCREEN-INPUT = 1.
MODIFY SCREEN.
ENDIF.
ENDLOOP.
ENDMODULE.

38
Working with Search Help Objects

A Search Help is an aggregated object and it gives list of possible values for the user. A Search
Help is a collection of search terms on which you retrieve a data from the database table.
All Search Help are associated with either selection criteria or parameters. When an input
field has a little triangle in the right-hand corner, it indicates that it has an associated
Search Help. When you click on drop-down arrow or press F4 button, it gives a list of all
possible values. For example MATNR field i.e. material number from MARA table, user
might not know all the material number, but they might know other details like material
description, type or any other details. You can create Search Help, which has all these
search terms i.e. you can create Search Help with description as search term or Search
Help with type as search term.
R/3 system includes many predefined Search Help but developers can create new Search Help as
is created in following case. Usually, system displays list of possible values for all the primary
keys with particular search term. Usually you create Search Help in following cases:
When you use non-primary key of input.
You need different search term for the primary key.
Creating Search Help object

Entire Search Help object is created in two steps:
Defining of Search Help object.
Defining one or more search ids for the object.
Defining Search Help object

It includes all the tables and fields, which make up the Search Help, which are used for Search
Help Ids.
Steps for defining Search Help object are as follows:
From dictionary, enter name (four character).
Select Search Help radiobutton and click on CREATE.
Define attributes for the object i.e. description.

39
Select primary table.

Select the fields for the table by clicking on the fields.
Activate the object.
If at all you are selecting secondary table then it is done after selecting primary table.
And steps are as follows:
Tables Choose secondary table. A dialog box appears, which displays list of possible
secondary tales. Select the table by Choose copy.
To activate the object, Search Help object -
activate
Creating Search Help IDs.

Once the object is created, you need to define search term for the object and steps are as follows:
Click on the Search Help ID from maintenance screen.
Enter attributes for the Search Help Id.
Short text.
Update type - Default is 1 for logical updating. It means that at the moment when you access the
Search Help object, the table is created like view. Unlike logical updating, physical updates are:
A,S,P.
System Search Help: If you click this particular field, it indicates a system Search Help, which is
used by SAP software and cannot be changed by the end user.
Autho.checks: If it is checked, the system performs authorization checks for this Search Help Id.
Selecting secondary tables

Position the cursor on the base table of the ID.
Edit Choose secondary tables
A dialog box appears listing the tables linked to the table by foreign keys
Select table.
Save.
Selecting fields for Search Help Id

Select fields.
Choose fields.
Once all the fields are selected, click on copy fields.
40
Fields are transferred to the Search Help Id.
Activation of Id
A corresponding database view is created in the database during activation for the Ids of update
type I. During activation, a check is made to see whether the corresponding index to support view
selection exists in the database. If it doesnt, a warning is displayed.
Testing the Search Help Id.

To test the Search Help Id:
Maintain Search Help object.
Utilities display Search Help data.
Using Search Help

When the user do not know which Search Helps are available for a field, user can find the Search
Help by:
Positioning the cursor on a field and clicking on drop arrow or pressing the F4 key.
A dialog box appears with a list of available Search Help
User can select another Search Help by clicking on the NEW selection button.
Double click on a Search Help to use it. If you want to use this as default Search Help, click on
standard button. If user does this once, the selected Search Help is proposed automatically the
next time.
You can enter the search term and press ENTER. If search term is not specified, the system
displays all the records for the specific Search Help.

41
Lock Objects
In a system where many users can access the same data, it becomes necessary to control the
access to the data. In R/3 system this access control is built-in on database tables. Developers can
also lock objects over table records.
To lock an object you need to call standard functions, which are automatically generated while
defining the lock object in ABAP/4 dictionary. This locking system is independent of the locking
mechanism used by the R/3 system. This mechanism also defines LUW i.e. Logical Unit of
Work. Whenever an object is locked, either by in built locking mechanism or by function
modules, it creates corresponding entry in global system table i.e. table is locked. The system
automatically releases the lock at the end of transaction. The LUW starts when a lock entry is
created in the system table and ends when the lock is released.
Creating Lock Objects

Lock object is an aggregated dictionary object and can be defined by using the following steps:
From initial data dictionary screen, enter the name for the object, Click Lock object radio
button and then click on Create. The system displays a dialog box for Maintain Lock
Objects screen
o Enter short text as usual and the name for primary table.
o Save
o Select Tables option
From this screen you can:
Select secondary tables, if any, linked by foreign key relationship.
Fields for the lock objects. This option allows you to select fields for objects (R/3 system allows
locking up to record level). Lock object argument are not selected by user but are imposed by the
system and includes all the primary keys for the table.
o

42
Types of locks
You can lock the table or record by using following types of locking:
Exclusive (E) the locked data can only be displayed or modified by single user i.e. the owner of
the object. Access to other users is denied.
Shared (S) several users can access the same record simultaneously, but only in display mode and
except the first one, who has asked for the data in update mode.
Exclusive not cumulating (X) it is similar to exclusive lock. It allows only a single user access. E
can be called several times from the same transaction. In contrast, a lock type X can be called
only once during the transaction. Any other call for this lock is rejected.
Activation of Lock Object
When you activate the lock object, the functions are automatically generated. And these are
ENQUEUE-EZN and DEQUEUE-EZN. EZN is name of the lock object.
While ENQUEUE is used in program to set the code over the selected data depending upon the
lock object arguments. DEQUEUE is used to release the lock.

43
EXERCISES
1. Create a Search Help for MARA-MATNR with one Search Help ID. The fields in the ID
should be MARA_MATNR., MARD-WERKS. MARD-LGORT. MAKT-MAKTX.
2. Create a GUI status of type list with the following features and attach it to a report. (Create a
simple report with Write statement).
Use the statement SUBMIT REPORT AND RETURN TO CALL A REPORT.
Menu
REPORTS
SYSTEM
HELP
Materials
Vendors
Exit
Application tool bar: 3 push button - Material, vendors, exit.
When material push button or menu option is chosen to display a list a materials with the
following fields:
MARA-MATNR, MARD-WERKS,MARD-LGORT,MAKT-SPRAS.
When vendor pushbutton or menu option is chosen, display a list of vendors with the
following fields.
LFA1-LIFNR, LFA1-NAME1, LFA1-ORTO1.
Exit to quit the program.
3. Create a transaction with three screens
Screen 1:
Radio button: 2 R1, R2.
Pushbutton : 2-Next, Exit,
When NEXT button is pressed, display screen 2 or screen 3 on the radio button selected.
i.e., if R1 is selected display screen 2 or if R2 is selected display screen3.
Screen 2:
44
Entry fields : SPFLI-CARRID, SPFLI-CONNID, SPFLI-CITYFROM, SPFLI-CITYTO.

Pushbutton : First screen, Exit.
Screen 3.
Entry fields : SFLIGHT-CARRID. SFLIGHT-CONNID.SFLIGHT-FLDATE.SFLIGHTSEATSMAX, SFLIGHT-SEATSOCC.
Pushbuttons: First screen, Exit.
`First screen pushbutton is to display screen 1 and exit is to quit the transaction.
***********USE SELECT-SINGLE*************
4. Create a transaction with on screen.
Screen one
Entry fields: MARD-MANTNR, MARD-WERKS,MARD-LGORT
Pushbuttons: First record Next Record, Previous record, Last Record, Exit.
Select the data from MARD into an internal table and whenever a button is pressed display the
corresponding record (i.e. First, Next, Previous, or Last) using the internal table index.
Exit to quit the transaction.
5. Copy above transaction and enhance it with these features. Place another pushbutton List.
When this button is pressed, Display a list with the following fields. MARDMATNR,MARD-WERKS,MARD-LGORT.
**********Use LEAVE TO-LIST-PROCESSING***********
6. Create a transaction with two normal screens and two subscreens.
Screen1 : Normal screen.
Entry fields: MARA-MATNR
Radio buttons: Plant, Description
Push-button: Display, Exit.
Screen2: Normal screen.
Display fields: MARA-MATNR.
Pushbuttons:Back,Exit.
Screen3: Subscreen.
Display fields: MARD-WERKS,MARD-LGORT.
Screen4: Subscreen
45
Display fields:MAKT-SPRAS,MAKT-MAKTX.
When the display pushbutton is clicked, display Screen2 with proper subscreen attached to it
based on the selection of radio button..
i.e. Screen 3 - if plant is selected and Screen 4 - if description is selected.

46

ABAP Book Module Pool PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ABAP Book Module Pool PDF

Uploaded by

Copyright:

Available Formats

Training Document

Transactions/Module Pool Programing

Module Pool Programming

Module Pool Programming

Deloitte Consulting India Pvt. Ltd.

GENERAL INTRODUCTION TO TRANSACTIONS ................................................ 4

Deloitte Consulting India Pvt. Ltd.

Features of Table Controls ............................................................................................... 25

Deloitte Consulting India Pvt. Ltd.

GENERAL INTRODUCTION TO TRANSACTIONS

Logical Unit of Work (LUW)

Deloitte Consulting India Pvt. Ltd.

Database transaction known as LUW. It can be defined as a period in which operation

Deloitte Consulting India Pvt. Ltd.

Deloitte Consulting India Pvt. Ltd.

Using Screen painter

Create screen and attributes by using screen attribute screen.

Creating a new Screen

Enter the name of program and number of the screen

Deloitte Consulting India Pvt. Ltd.

Text Standard text or field labels.

Deloitte Consulting India Pvt. Ltd.

Selecting Screen fields

Enter table name.

Attributes of Screen Elements

Attribute dialog box can be displayed by

Clicking on the ATTRIBUTE push button on the application tool bar.

Deloitte Consulting India Pvt. Ltd.

Screen Flow Logic

Process before Output (PBO)

Deloitte Consulting India Pvt. Ltd.

Deloitte Consulting India Pvt. Ltd.

Module Pool Programming

Creation of Module Pool Program

Communication between Dynpro and Module Program

Deloitte Consulting India Pvt. Ltd.

Deloitte Consulting India Pvt. Ltd.

Creation of a Complete Transaction

Create module pool program.

Handling Function Code

In field list, developer needs to specify OKCODE as last field.

A complete example for transaction is shown below:

Deloitte Consulting India Pvt. Ltd.

Deloitte Consulting India Pvt. Ltd.

The Field Checks

Automatic field checks

Automatic Field Checks

Deloitte Consulting India Pvt. Ltd.

Proper Data Format

Valid Value for the Field

About at Exit Command

Process After Input.

In module pool program.

Deloitte Consulting India Pvt. Ltd.

To achieve this kind of functionality a pushbutton or menu item should be assigned a

Flow Logic Validations

Field sflight-carrid values (LH).

Field sflight-carrid values (LH SQ).

Module Pool Program Validations

Deloitte Consulting India Pvt. Ltd.

Field statement in flow logic.

Deloitte Consulting India Pvt. Ltd.

Dynamically Calling the Screens