MODULE POOL PROGRAMMING (DIALOG PROGRAMMING):

http://www.sapabapwebdynprotutorials.com/search/label/D
ialog%20Programming
PURPOSE:

1. Design new SAP Transactions which are specific to customers

2. Enhancing Existing SAP transactions (used along with enhancements) 

cross-apps

Dialog Programming  Screen painter tool (SE51)

Screen painter tool  Contains 4 sections

1. Attributes  Description, Type of screen (Normal , Subscreen, Dialog box)

2. Layout  Design the Transaction with different elements
3. Flowlogic  Implement the events in the corresponding module definitions
4. Element List  SAP internal use  contains elements information placed
on the screen layout

Note: A module pool program can be created either with or without TOP
include program.
TOP include program can be used for declaring global variables, subroutine
definitions and module definitions.
A TOP include program must end with ‘TOP’.
A Module pool program cannot be executed directly; it needs to be
associated with a transaction code.

Procedure for developing Module pool Programs:

1. Create a module pool program in object navigator (SE80) (with top

include-recommended)
2. Create the initial screen using screen painter tool and provide the
description and choose the type of screen in ‘Attributes’ tab
3. Design the screen layout with different elements (textfields, i/o fields,
checkboxes,radiobuttons,table control….) and also set the appropriate
properties for each of the elements
4. Implement the events in the flowlogic by defining the corresponding
modules
5. Repeat the steps 2,3,4 for each of the screens
6. Create the t-code for the module pool program by associating with the
initial screen of the transaction

Events in Dialog programming:

1. PBO 2. PAI 3. POV 4. POH

PBO (Process before output): This event functionality is similar to ‘At

Selection-screen output’ event in case of selection screen. This event is
triggered in the following cases:
a) Whenever the screen is displayed for the first time
b) After PAI event
This event can be handled for the following cases:
1. To initialize the screen elements with the default values
2. To Refresh the screen appearance after the user interaction in
the runtime

PAI (Process after Input): This event functionality is similar to ‘At selection-
screen’ event in case of selection-screen. This event is triggered in the
following cases:
a) When the user presses enter key in the input field
b) When the user selects/deselects a checkbox or when the user
selects a radio button
c) When the user selects a value in the dropdown list box
d) When the user scrolls in the table control
 e) When the user clicks on the pushbutton
This event can be handled to provide an action whenever a user
performs an action in/on a screen element in the runtime

POV (Process on value-request): This event functionality is similar to ‘At

selection-screen on value-request’ event in case of selection-screen. This
event is triggered in the following case:
a) When the user presses f4 key in the input field
This event can be handled to provide custom F4 values whenever a user
presses F4 key in the screen input field.

POH (Process on help-request): This event functionality is similar to ‘At

selection-screen on help-request’ event in case of selection-screen. This
event is triggered in the following case:
a) When the user presses f1 key in/on the screen element.

This event can be handled to provide custom F1 help whenever a user

presses F1 key in/on the screen element.

Note: Whenever we need to refer to the screen element inside the

program, we need to declare a variable with the same name and type as
that of screen element.

TABSTRIP CONTROL: A tabstrip control is a collection of TAB Buttons. Each

Tab button should be associated with a subscreen. A subscreen cannot be
placed directly on top of normal screen; it should be placed on top of a
subscreen area. We can use same / different subscreen areas for each tab.
A Subscreen area is a collection of subscreens.

Note: Whenever a normal screen/subscreen layout contains tabstrip

control, it should be declared explicitly by using ‘controls’ keyword.,
otherwise it leads to runtime error ‘control not found’.
The datatype for tabstrip control is ‘tabstrip’.

Syntax for Declaring Tabstrip control:

Controls <tabstrip name> type tabstrip.

Note: By Default, The first tab will be active in the Tabstrip control. We can
use the property ‘ACTIVETAB’ of tabstrip control to activate a specific tab
button in tabstrip control. Each Tab should be associated with a subscreen.
Since Subscreen cannot be placed on top of normal screen, we need to
place subscreen area in each tab and then in the runtime, the subscreen
will sit on TOP OF subscreen area. We can use same/different subscreen
area’s FOR each tab. The no. of calls to ‘CALL SUBSCREEN’ statement
depends on the no. of subscreen areas.

Note: Subscreens should be called from the flowlogic section.

Syntax for calling subscreens:

Call subscreen <subscreen area> including <subscreen program name>

<subscreen no>.

TABLE CONTROL:

It is used for displaying the data in the form of rows and columns.

Note: Whenever a screen / subscreen contains table control component

and when we do syntax check, it gives error as ‘loop endloop’ is required in
both PBO and PAI.

In order to avoid this error in the design time, initially provide loop and
endloop in both PBO and PAI events.
 Note: Whenever a screen/subscreen layout contains table control, it should
be declared explicitly by using ‘controls’ keyword. The data type for table
control is ‘tableview’. If it not declared, it leads to runtime error ‘control
not found’.

Syntax for declaring Table control:

Controls <table control name> type tableview using screen <screen no>.

By default, Table control vertical scrolling property is disabled. To enable it,

we need to set the ‘LINES’ property of table control.

Validating Module pool transactions:

1. Automatic Field validations: In this, the validations are performed by SAP

itself based on the properties of the screen field (transaction field) set at
screen level(frontend) or properties of the field maintained at dictionary
level (database level). In this, the validation messages are provided by SAP
itself.

Validation messages:
1. If mandatory field value is not entered  message will be provided by
SAP  fill in all the required fields
2. If invalid country key / language key / units of measurement … is
entered  message will be provided by SAP  Invalid values (entry
doesn’t exist in …..)
3. If invalid date is entered  message will be provided by SAP  invalid
date

Eg:- Mandatory fields, Invalid values, Invalid date format

2. Flow logic validations: In this, the validations are performed by SAP itself
based on the values maintained for the field at the flow logic level. In this,
the validation messages are provided by SAP itself.

Flowlogic section:
Eg: field lfa1-land1 values (‘AF’,’AR’,’IN’)
Field mara-mtart values (‘COUP’,’FGTR’,’ROH’)

Eg:- field emp-empsal values between 10000 and 20000

Note: If any of the screen field fails the flow logic validations, the other
fields on the screen will be disabled and doesn’t allow the user to input the
values in the other fields.
This can be avoided by grouping the logically related fields using chain-
endchain statement.
Eg:-
Flowlogic section:

Chain.
Field lfa1-lifnr.
Field lfa1-land1 values (‘AF’,’AR’,’IN’).
Endchain.

chain.
field mara-matnr.
field mara-mtart values ('COUP','FGTR','ROH').
endchain.

3. Module pool validations: These validations are used for performing field
specific validations. In this, the validation messages must be provided by
developer itself.

Syntax:

Flowlogic section:
Field <field name> module <module name>.

Note: Define the module with validation logic and validation message in any
of the include programs.

At Exit-command module

Note: If a screen field fails any of the above validations, the user cannot exit
the transaction unless the validation is correct or in some cases user may
require to forcefully exit the transactions. For forceful exit, we need to
consider a button whose functionality should be similar to that of cancel
button. For this, we need to set an additional property for the button i.e
FCTTYPE to ‘E’ (function type to exit command) along with the function
code. Apart from this additional property, there should be corresponding
‘at exit-command’ module in the PAI event. As part of this module
definition, we need to implement the logic to exit the transaction
forcefully. This ‘at exit-command’ module is executed only when the user
clicks on the button whose function type is set to ‘E’.

Syntax for at exit-command:

PAI event:

Module <module name> at exit-command.

As part of module definition, implement the logic to exit the transaction

(leave program).