Académique Documents
Professionnel Documents
Culture Documents
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.
Typically the transaction code that calls the application will refer to the module pool and the initial screen number.
Reports
Dialog Programs
SAP Transaction
Transaction codes could be created in the Repository Browser in the ABAP Workbench or using Transaction SE93.
We can start a screen sequence from any ABAP program using the CALL SCREEN statement.
Screens
You create screens using the Screen Painter in the ABAP Workbench through transaction SE51
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).
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.
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.
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.
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.