Module Pool Programming

Introduction to MPP
A module pool is a collection of screens, flow logic, menu bars and ABAP code
that when linked together build an application.

Through MPP there is a two way communication with the database.

Typically the transaction code that calls the application will refer to the module pool and the initial screen number.

These are the type M programs in SAP.

Also referred to as Dialog Programs as they cannot be executed in background.

Reports Vs Dialog Programs

Reports

Dialog Programs

A dialog program allows you

to work interactively with the
system and to change the
A report is a program that
contents of the database
typically reads and analyzes
tables. Each dialog program
data in database tables without
has a certain sequence of
changing the database.
screens that are processed
by the system one after the
other.
For executing dialog
A report could run directly as
programs we need to
well as by creating a transaction
create a z transaction.
Reports are type E
(Executable) SAP ABAP
Programs

Dialog Programs are type M

(Module) SAPPrograms

The screen sequence is

controlled by events, which
occur in a fixed order.

We can program screens to

appear in any sequence we
want

Dialog Program Components

SAP Transaction

The transaction code starts a screen sequence.

Transaction codes could be created in the Repository Browser in the ABAP Workbench or using Transaction SE93.

A transaction code is linked to an ABAP program and an initial screen.

We can start a screen sequence from any ABAP program using the CALL SCREEN statement.

Screens

Each dialog in an SAP system is controlled by one or more screens.

You create screens using the Screen Painter in the ABAP Workbench through transaction SE51

Each screen belongs to an ABAP program.

These screens consist of a screen mask or layout and its flow logic. The screen has a layout that determines
the positions of input/output fields and other graphical elements such as checkboxes and radio buttons. A flow logic
determines the logical processing within screen.

Flow Logic

Process Before Output After it has processed all of the modules in the PBO processing block, the system copies
the contents of the fields in the ABAP work area to their corresponding fields in the screen work.

Process After Input(PAI) Before it processes the first module in the PAI processing block, the system copies the
contents of the fields in the screen work area to their corresponding fields in the ABAP work area.

Process on help request (POH) It is processed when F1 key is pressed. It is used to provide the documentation
help to the user.

Process on value request (POV) It is processed when F4 key is pressed. It is used to provide the value input
help to the user for entering data on screen.

ABAP Program

Each screen and GUI status in the R/3 System belongs to one ABAP program.

The ABAP program contains the dialog modules that are called by the screen flow logic, and also process the user
input from the GUI status.

ABAP programs that use screens are also known as dialog programs.

In a module pool (type M program); the first processing block to be called is always a dialog module. However,
you can also use screens in other ABAP programs, such as executable programs or function modules. The first processing
block is then called differently; for example, by the runtime environment or a procedure call. The screen sequence is then
started using the CALL SCREEN statement.

GUI Status
Each screen has a GUI status. This controls the menu bars, standard toolbar, and application toolbar, with which the user
can choose functions in the application. Like screens, GUI statuses are independent components of an ABAP program. You
create them in the ABAP Workbench using the Menu Painter(SE41) .

Dynpro

A screen together with its Flow logic is called a Dynpro (Dynamic Program since the screen flow logic influences
the program flow).

Each dynpro controls exactly one step of your Dialog Program.

The screens belonging to a program are numbered. The screen flow sequence can be either linear or cyclic. From
within a screen chain, you can even call another screen chain and, after processing it, return to the original chain. You can
also override the statically-defined next screen from within the dialog modules of the ABAP program.

ABAP Module Pool

On a PBO or PAI event a Dynpro calls an ABAP dialog program. Collection of such programs is called the ABAP
module pool.
For example modules called at the PAI event are used to check the user input and to trigger appropriate dialog steps,
such as the update task.

All Dynpro to be called from within one transaction refer to a common module pool.

User Input Checking

Using FIELD Statement: If you want to check input values in the module pool and start dialog in the event of a
negative result, you use the FIELD statement with the addition MODULE.If the module results in an error(E) or warning(W)
message, the screen is redisplayed without processing the PBO modules. The message text is displayed and only the field
being checked by this module becomes ready for input again.
Eg. FIELD MATNR MODULE user_command_0100

Using Chain Statement: If you send a warning or error message from a module <mod> that you called using a
FIELD statement as follows:
CHAIN.
FIELD: <f1>, <f 2>,...
MODULE <mod1>.
FIELD: <g1>, <g 2>,...
MODULE <mod2>....
ENDCHAIN.
All of the fields on the screen that belong to the processing chain (all of the fields listed in the field statements) are made
ready for input again. Other fields are not ready for input. Whenever the MODULE statement appears within a processing
chain, even if there is only one FIELD attached to it, all of the fields in the chain (not only the affected field) are made ready
for input again, allowing the user to enter new values. If the fields in the processing chain are only checked once, the PAI
processing continues directly after the FIELD statement, and the preceding modules are not called again.

SAP Standards for MPP

o

All MPP program names should start with SAPMZ

o
o
o
o

Include TOP:- Include type program where all the data declaration is made.
Include 001:- Include where all the PBO Modules are declared.
Include I01 :- Include where all the PAI Modules are declared.
Include F01 :- Include where all the Form routines are declared.

Leaving a Screen from a Program

In a program, you can use one of the two following ABAP statements to leave a screen:
LEAVE SCREEN.
or
LEAVE TO SCREEN <next screen>.
The LEAVE SCREEN statement ends the current screen and calls the subsequent screen. The next screen is either the
static next screen or a dynamic next screen. In the second case, you must override the static next screen using the SET
SCREEN statement before the LEAVE SCREEN statement.

SET SCREEN <next screen number>.

LEAVE SCREEN.
The LEAVE TO SCREEN statement exits the current screen and calls the dynamic next screen, which you specify as part of
the statement. The LEAVE TO SCREEN statement is no more than a contraction of the two statements These
statementsdo not end the screen sequence. They merely branch to another screen in the same sequence. The screen
sequence only ends when you leave to next screen 0.
Call Screen:- This statement calls the dynpro with the dynpro number specified in dynnr. For dynnr, a data object of type n
and length 4 is expected. The call starts a new dynpro sequence, which is embedded into the current dynpro sequence. The
dynpro with dynpro number dynnr is the initial dynpro of the dynpro sequence. In a dynpro sequence started by a transaction
code, you can nest up to 50 other dynpro sequences.
Syntax
CALL SCREEN dynnr
[STARTING AT col1 lin1
[ENDING AT col2 lin2]].