Module Pool Programming
Module Pool Programming
TRANSACTION , In R/3 system is an operation that lets the user to make necessary
Changes to the database in a consistant way. The entire R/3 system is nothing but set of
business transactions. The data transfer from old system to SAP R/3 database or
modifying data Or deleting data is done through transactions Only.
For SAP system, TRANSACTION is nothing but sequence of steps called as dialog
steps( So that this is also Called Dialog Programming) and for user it is sequence of
screens which appears one after the other to accept the data which is to be Created in the
Database.
• Interactive phase in this step user enters the data on to the screen, which needs to be
inserted or deleted or modified. These 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
tables. Actual updation of database table takes place in this phase.
Note : Each transactions should be associated with a transaction code. And all these
codes are stored in table called TSTC.
PBO (Process Before Output) – Before the screen is displayed, the PBO event is
processed. It used to transfer default values from Program to Screen .
PAI (Process After Input) – When the user interacts with the screen, the PAI event is
processed i.e through user interaction After prividing the Screen Input.
POH (Process On Help Request) - are triggered when the user requests field help (F1).
You can program the appropriate coding in the corresponding event blocks.
POV (Process On Value Request) - are triggered when the user requests possible values
help (F4).
The R/3 system is multi user system and many users access same information at the same
time. 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
situation, R/3 system has provided logical unit of work is defined as a locking
mechanism to protect transaction integrity. Of course, these are other measures, which
ensures data integrity like check table I.e. foreign key relationship.
ii) (Update transaction ) SAP LUW - One SAP LUW can have several databases 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.
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.
Note : Automatic field checks are repeated each time the user enters the data.
Page 2 of 24 Prepared By : Ganapati Adimulam
eMAX Technologies,AmeerPet,Hyderabad
Ph : +91 40 65976727.
Module Pool Programming
We Never Compromise in Quality. Would You ?
_______________________________________________________________________
_
Consider the case where you want user to enter only ‘1000’ and ‘2000’ for T001-
BUKRS.
Hence need of additional validation and can be done in flow logic by using following
statement.
SYNTAX.
PAI.
FIELD T001-BUKRS (‘1000’ , ‘2000’).
PAI.
FIELD T001-BUKRS 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 entered value is wrong then that field is enabled for user to enter.
MODULE VALIDATE_BUKRS.
SELECT * FROM T001 UP TO 1 ROWS
WHERE BUKRS = T001-BUKRS.
IF SY-SUBRC <> 0.
MESSAGE E009.
ENDIF.
ENDMODULE.
NOTE : Having the Module Call in the Flow Logic and the Definition of
Module in the ABAP/4(Module Pool) Program.
If you want to ensure that more than one field is ready for input for an error dialog, you
must list all of the relevant fields in the FIELD statement, and include both that and the
MODULE statement in a CHAIN … ENDCHAIN block.
SYNTAX
CHAIN.
Field T001- BUTXT values (‘Emax Technologies’, ‘iMAX Tech’).
Field T001- BUKRS values between ‘1000’ and ‘2000’.
ENDCHAIN.
In this case if the user enters wrong value only for BUKRS ,both the fields i.e., BUKRS
and BUTXT are enabled as they are grouped together in the CHAIN statement.
Note : Usually logically related fields are grouped together with CHAIN …
ENDCHAIN statement.
6.Explain How to Provide the List Box / Drop Down to Input field ?
EXPORTING
ID = <INPUT FIELD NAME>
Page 4 of 24 Prepared By : Ganapati Adimulam
eMAX Technologies,AmeerPet,Hyderabad
Ph : +91 40 65976727.
Module Pool Programming
We Never Compromise in Quality. Would You ?
_______________________________________________________________________
_
VALUES = IT_VALUES.
7.How to turn the Input Field into Mandatory and also how to accept the
Password (Display the Password as ****) ?
The Input is
Mandatory
8.Naming Convention For Module Pool Program and what are the Default
INCLUDE Programs Created and the Purpose of Each INCLUDE?
Naming Standards :
The Module Pool Program has type M. When you create a type M program in the Repository
Browser, the ABAP Workbench automatically organizes the program code into a series of include
programs. If your ABAP program observes the naming convention SAPMZ<name>, the hierarchy
tree in the Repository Browser allows you to create the following include programs:
• Global fields: Global data declarations in the include MZ<name>TOP. This data is
visible in all modules within the program.
• PBO module: Dialog modules in the includes MZ<name>O<nn>, which are called
before a screen is displayed.
Subroutines: Subroutines within the program, stored in the includes MZ<name>F<nn>. These
can be called from anywhere in the program.
A subscreen is a screen within the screen and which can called in the Subscreen Area of
the Normal Screen.
To call subscreen, from your flow logic you need to include the statement both in
PAI and PBO.
SYNTAX.
PBO.
CALL SUBSCREEN <area> INCLUDING <prg name> <screen number>.
PAI.
Note : 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.
Screen layout: Positions of the text, fields, pushbuttons and so on for a screen
Screen Attributes: Number of the screen, number of the subsequent screen, and others
11.Can we use flow logic control key words in ABAP/4 and vice-versa?
NO.
The flow control of a dynpro consists of a few statements that syntactically ressemble
ABAP/4 statements .However ,we cannot use flow control keywords in ABAP/4 and
vice-versa.
We can always define the flow logic in the flow logic editor of the Screen Painter, using
only the following keywords:
Keyword Description
CALL Calls a subscreen.
CHAIN Starts a processing chain.
ENDCHAIN Ends a processing chain.
ENDLOOP Ends loop processing.
FIELD Refers to a field. You can combine this with the
MODULE and SELECT keywords.
LOOP Starts loop processing.
MODIFY Modifies a table.
MODULE Identifies a processing module.
ON Used with FIELD assignments.
PROCESS Defines a processing event.
SELECT Checks an entry against a table.
VALUES Defines allowed input values.
A GUI status is a subset of the interface elements used for a certain screen.
-Title bar.
-Menu bar.
To create and edit GUI status and GUI title,we use the Menu Painter(SE41).
14.How does the interaction between the Dynpro and the ABAP/4 Modules takes
place?
ABAP/4 processing of each screen .For each screen,the system executes the flow logic
that contains the corresponding ABAP/4 processing.The controls passes from screen flow
logic to ABAP/4 code and back.
For each screen the system executes the flow logic which contains corresponding events
and then the control is passed to Module Pool Program. Module Pool Program handles
the code for this events and again passes back control to the flow logic and finally to
screen. Unlike 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.
Note: Data will be transferred only for the fields which has the common Names in both
Screen and Module Pool Program Automatically.
Note : The Function Code is also available through the System Variable
SY-UCOMM.
The ABAP/4 module is called only if a field contains the Value other than the initial
Value.This initial Value is determined by the filed’s Dta Type: blanks for character
Fields,Zeroes for numerics. If the user changes the Fields Value back to its initial
value,ON INPUT does not trigger a call.
The ABAP/4 Module is called only if the user has entered the value in the field value
since the last screen display .The Value is treated as change, Even if the User simply
types in the value that was already there .In general ,the ON REQUEST condition is
triggered through any Form of ” MANUAL INPUT’.
The ABAP/4 module is called if any one of the fields in the chain contains a value
other than its initial value(blank or nulls).
ON CHAIN-REQUEST
This condition functions just like ON REQUEST, but the ABAP/4 module is
called if any one of the fields in the chain changes value
19.What is AT EXIT-COMMAND ?
Page 12 of 24 Prepared By : Ganapati Adimulam
eMAX Technologies,AmeerPet,Hyderabad
Ph : +91 40 65976727.
Module Pool Programming
We Never Compromise in Quality. Would You ?
_______________________________________________________________________
_
AT EXIT-COMMAND lets you call a module before the system executes the automatic
fields checks.
Code for AT EXIT-COMMAND in flow logic and in module pool program can be
written as follows.
In flow logic,
MODULE EXIT.
Case okcode.
When ‘EXIT’.
Leave to screen 0. ENDMODULE.
To achieve this kind of functionality, the pushbutton or menu item should be assigned a
function type ‘E’(Exit). It tells the system to process this particular module before
carrying out any field checks.
With SET SCREEN the current screen simply specifies the next screen in the chain ,
control branches to this next screen as soon as the current screen has been processed .
Return from next screen to current screen is not automatic .It does not interrupt
processing of the current screen. If we want to branch to the next screen without
finishing the current one,use LEAVE SCREEN.
With CALL SCREEN , the current (calling) chain is suspended , and a next screen
(screen chain) is called .The called can then return to the suspended chain with the
statement LEAVE SCREEN TO SCREEN 0 .Sometime we might want to let an user
call a pop up screen from the main application screen to let him enter secondary
information.After they have completed their enteries, the users should be able to close the
Page 13 of 24 Prepared By : Ganapati Adimulam
eMAX Technologies,AmeerPet,Hyderabad
Ph : +91 40 65976727.
Module Pool Programming
We Never Compromise in Quality. Would You ?
_______________________________________________________________________
_
popup and return directly to the place where they left off in the main screen.Here comes
CALL SCREEN into picture .
21.What happens if only one of the commands SET SCREEN and LEAVE SCREEN
is used without using the other?
If we use SET SCREEN without LEAVE SCREEN, the program finishes processing for
the current screen before branching to <scr no>. If we use LEAVE SCREEN without a
SET SCREEN before it, the current screen process will be terminated and branch directly
to the screen specified as the default next-screen in the screen attribute.
In “calling mode”, the special screen number 0 (LEAVE TO SCREEN 0) causes the
system to jump back to the previous call level. That is, if you have called a screen
sequence with CALL SCREEN leaving to screen 0 terminates the sequence and returns to
the calling screen. If you have not called a screen sequence, LEAVE TO SCREEN 0
terminates the transaction.
Suppressing of entire screens is possible with this command. This command allows us to
perform screen processing “in the background”. The system carries out all PBO and PAI
logic, but does not display the screen to the user. Suppresing screens is useful when we
are branching to list-mode from a transaction dialog step.
SUPPRESS DIALOG.
Effect
However, flow control continues normally and dialog resumes on the next screen.
Note
25.What are the differences between TABLE CONTROLS and STEP LOOPS?
TABLE CONTROLS are simply enhanced STEP LOOPS that display with the look and
feel of a table widget in a desktop application. But from a programming standpoint,
TABLE CONTROLS and STEP LOOPS are almost exactly the same. One major
difference between STEP LOOPS and TABLE CONTROLS is in STEP LOOPS their
table rows can span more than one time on the screen. By contrast the rows in a TABLE
CONTROLS are always single lines, but can be very long. (Table control rows are
scrollable). The structure of table control is different from step loops. A step loop, as a
screen object, is simply a series of field rows that appear as a repeating block. A table
control, as a screen object consists of: I) table fields (displayed in the screen ) ii) a control
structure that governs the table display and what the user can do with it.
26.Why do we need to code a LOOP statement in both the PBO and PAI events for
each table Control in the screen?
We need to code a LOOP statement in both PBO and PAI events for each table in the
screen. This is because the LOOP statement causes the screen fields to be copied back
and forth between the ABAP/4 program(Internal Table) and the screen field(Table
Control). For this reason, at least an empty LOOP….ENDLOOP must be there.
The field SY-STEPL refers to the index of the screen table row that is currently being
processed. The system variable SY-STEPL only has a meaning within the
LOOP….ENDLOOP processing. Outside the loop, it has no valid value.
Leave to List-processing statement is used to produce a list from a module pool. Leave
to list processing statement allows to switch from dialog-mode to list-mode within a
dialog program.
If we don’t use Suppress-Dialog ,the next screen will be displayed but as empty, when
the user presses ENTER, the standard list output is displayed.
A program asks the system to perform a certain task, and then either waits or doesn’t wait
for the task to finish. In synchronous processing, the program waits: control returns to
the program only when the task has been completed. In asynchronous processing, the
program does not wait: the system returns control after merely logging the request for
execution.
34.In what ways we can get the context sensitive F1 help on a field?
All ABAP programs can also access the SAP memory. This is a memory area to which all
sessions within a SAPgui have access. You can use SAP memory either to pass data from one
program to another within a session, or to pass data from one session to another. Application
programs that use SAP memory must do so using SPA/GPA parameters (also known as
SET/GET parameters). These parameters are often used to preassign values to input fields. You
can set them individually for users, or globally according to the flow of an application
SPA/GPA parameters are field values saved globally in memory. There are two ways to
use SPA/GPA parmeters:
SPA/GPA parameters are values that the system stores in the global, user-specific SAP memory.
SAP memory allows you to pass values between programs. A user can access the values stored
in the SAP memory during one terminal session for all parallel sessions. Each SPA/GPA
parameter is identified by a 20-character code.
ABAP programs can access the parameters using the SET PARAMETER and GET
PARAMETER statements.
This statement saves the contents of field <f> under the ID <pid> in the SAP memory.
This statement fills the value stored under the ID <pid> into the variable <f>. If the system
does not find a value for <pid> in the SAP memory, it sets SY-SUBRC to 4, otherwise to 0.
When you call programs, you can use SPA/GPA parameters with no additional programming
overhead if, for example, you need to fill obligatory fields on the initial screen of the called
program. The system simply transfers the values from the parameters into the input fields of the
called program.
If you want to set SPA/GPA parameters before a program call, you need to know which
parameters are linked to which fields on the initial screen. A simple way of doing this is to start
the program that you want to call, place the cursor on the input fields, and choose F1 followed by
Technical info. The Parameter ID field contains the name of the corresponding SPA/GPA
parameter. Alternatively, you can look at the screen definition in the Screen Painter.
SPA/GPA :
No Checkboxes are
displayed as the
w/SelColumn is not
Selected
Checkboxes are
displayed as the
w/SelColumn is
Selected
ABAP Memory is a Memory area in the internal session (roll area) of an ABAP program.
Data within this area is retained within a sequence of program calls, allowing you to pass
data between programs that call one another.
The memory area of each session contains an area called ABAP memory. ABAP
memory is available to all internal sessions.
ABAP programs can use the EXPORT and IMPORT statements to access it.
To pass data to a program which you are calling, the data needs to be placed in
ABAP memory before the call is made. The internal session of the called program
then replaces that of the calling program.
This allows you to pass data from one module to another over several levels of the program
hierarchy. For example, you can pass data
and so on.
Syntax : EXPORT <f1> [FROM <g 1>] <f 2> [FROM <g 2>] ... TO MEMORY ID <key>.
This statement stores the data objects specified in the list as a cluster in memory. If you
do not use the option FROM <f i >, the data object <f i > is saved under its own name. If
you use the FROM <g i > option, the data objet <g i > is saved under the name <f i >. The
name <key> identifies the cluster in memory. It may be up to 32 characters long.
To read data objects from ABAP memory into an ABAP program, use the following
statement:
Syntax : IMPORT <f1> [TO <g 1>] <f 2> [TO <g 2>] ... FROM MEMORY ID <key>.
This statement reads the data objects specified in the list from a cluster in memory. If you
do not use the TO <g i > option, the data object <f i > in memory is assigned to the data
object in the program with the same name. If you do use the option, the data object <f i >
is read from memory into the field <g i >. The name <key> identifies the cluster in
memory. It may be up to 32 characters long.
Need to handle the First,Last,Next and Previous Pages in the Table Control.
CASE CODE.
FLIGHTS-TOP_LINE = 1.
I = FLIGHTS-TOP_LINE + LINE_COUNT.
J = FLIGHTS-LINES - LINE_COUNT + 1.
IF J LE 0. J = 1. ENDIF.
IF I LE J. FLIGHTS-TOP_LINE = I.
ELSE. FLIGHTS-TOP_LINE = J.
ENDIF.
ENDCASE.