module pool

[Former Member]

need the detailsof module pool programming

[Former Member]

Unlike report, interface, and conversion development which generally entails the creation of one autonomous program which can be executed independently of other objects, dialog program development entails development of multiple objects, none of which can be executed on its own. Instead, all objects are linked hierarchically to the main program and are executed in a sequence dictated by the program.

Dialog programs are composed of the following main components:

Screens

Module pool

Subroutines

Menus/GUI statuses

Transaction codes

Screens are made up of the following components:

Screen attributes

Screen layout/screen elements

Fields

Flow logic

Flow logic is comprised of two events:

The process before output (PBO) event invokes any processing which is to occur before the screen is displayed to the user.

The process after input (PAI) event invokes any processing which is to occur after the user has completed interaction with the screen by invoking any one of the possible functions (I.E. Save, back, enter, etc.).

[Former Member]

The module pool consists of modularized ABAP/4 syntax which is placed inside include programs belonging to the dialog program.

These modules are invoked when called upon by flow logic.

Processing of flow logic and ABAP/4 modules is handled by different processors in the SAP system.

Flow logic is processed by the dialog processor while all ABAP/4 is processed by the ABAP/4 processor.

The ABAP/4 module pool consists of the following components:

The main program which will contain a series of include programs. Customer dialog programs should begin with SAPMZ or SAPMY.

Global data declarations in the form of a top include program. The program is named with the last five characters of the main program followed by ‘TOP’ (for TOP include). All data declarations will be placed within this program during development.

For modularization purposes, remaining ABAP/4 is developed using the following structure of include programs:

A PBO module include program is created to hold modules invoked by the PBO event of any of the screens in the dialog program. A PAI module include program is created to hold modules invoked by the PAI event of any of the screens in the dialog program. The proper naming convention uses the last five characters of the main program followed by either ‘O’ for PBO modules or ‘I’ for PAI modules, ending with a sequential number beginning with ‘01’. All PBO and PAI modules are placed inside their respective include program until the need for further modularization arises at which point a new include can be created using the next number in the sequence.

If further modularization is required a forms include program is created for subroutines name with the last 5 characters of the main program followed by ‘F’ for forms followed by a sequential number beginning with ‘01’.

[Former Member]

Developing a Simple Dialog Program :

1) create the main program

2) create top include

3) create first screen

Define attributes

Define graphical user interface

Assign field attributes via field list

Define flow logic using dialog flow logic syntax

4) create follow up screens

(Same steps as first screen)

5) create ABAP/4 processing logic (modules, sub-routines, etc.)

Choose (create if necessary) the PBO include which will contain the ABAP/4 modules

Write PBO modules (ABAP/4)

Choose (create if necessary) the PAI include which will contain the ABAP/4 modules

Write PAI modules (ABAP/4)

Create any required subroutines (create include programs if necessary)

6) define ABAP/4 global data

TOP include

Names must be identical to names used in screens!

7) create menus (if necessary, not yet discussed)

😎 create transaction

• Steps 5 and 6 can be transposed and often occur together.

Assign the type ‘M’ (default) for module pool. Unlike type ‘1’ programs (reports, some utility programs, etc.), Type ‘M’ programs cannot be executed directly. They must first have a transaction code assigned to them (discussed later).

After saving the main program and leaving the program attributes screen (i.E. Choosing ‘back’ from the menu) you will again be prompted with the ‘create object catalog entry’ screen where a development class is assigned. This time the name of the TOP include program MZxxxTOP will be displayed. You must save from this screen or the TOP include program will not be created.

[Former Member]

After saving the TOP include, the object list is displayed from within the object browser.

The main program and the TOP include are displayed in a tree format.

All objects added to the dialog program will be displayed in this hierarchy.

Objects displayed here include: dictionary structures, global data, macros, PBO modules, PAI modules, subroutines, screens, GUI status, GUI title, transactions, and includes.

Although dictionary structures, global data, macros, PBO modules, PAI modules, and subroutines are displayed as independent objects belonging to the main program, they are actually objects defined within the include programs which are also listed. For example, if a PBO module is added to an include program for PBO modules, that module will be displayed underneath the main program under PBO modules and the include program containing that module will be displayed with the include programs.

Create the first screen, usually numbered ‘0100’, by positioning the cursor on the main program and choosing ‘create’, or by double clicking on the ‘program object types’ entry of the object browser.

The ‘program objects’ list is displayed with the various types of objects which can be created.

Choose the screen radio button, supply the screen number, and choose ‘create’ at the bottom left of the screen.

Assign the screen attributes. Provide a short description. Choose a screen type (default ‘normal’). Enter the follow-up screen to be processed after completion of current screen.

Save the screen attributes.

Choose the ‘full screen’ button from the top to define the screen layout (‘paint the screen’).

Elements are added to screens using screen painter. Two editors are available in screen painter, the alphanumeric screen painter and the graphical screen painter (as of v3.0 and requires windows 95, windows NT, or UNIX).

In the alphanumeric mode fields are input/OUPUT fields are represented by underlines ‘_’ and text fields are types on the screen. Additionally, graphical elements can be added to the screen (i.E. Group boxes, radio buttons, check boxes, icons, buttons, control tables, step loops) by placing a field on the screen, placing the cursor on the field and choosing ‘graphical element’.

With the graphical screen painter, screen elements are chosen from a graphical list of elements and are placed on the screen using the mouse. Screen fields and objects can then be manipulated in a ‘drag and drop’ fashion.

To add fields from the data dictionary, choose ‘dictionary/program fields’ from the GOTO menu.

As a general rule, screen fields should reference dictionary fields whenever possible.

Attributes must be defined for all screen fields.

Objects taken from the dictionary retain the attributes assigned in the data dictionary unless otherwise specified. These attributes include field name, length, type, etc. And are taken from the data element and data domain.

There are six field list views for defining field attributes. They are located in the menu path Goto > field list views and include: field types, text/templates, general attributes, display attributes, modification groups, and list/mc currencies.

Additionally, field attributes can be assigned and displayed by selecting the field and choosing ‘attributes’ from the screen painter or by choosing ‘field list’ from the flow logic portion of screen painter.

Field types

Tests/templates

General attributes

Display attribute

Modification groups

List/mc currencies

Flow logic is defined from the screen painter by choosing ‘flow’ from the screen painter, or by navigating to the desired screen from the object list.

Flow logic consists of a limited syntax which is different than ABAP/4. Its general purpose is to define the flow of execution of dialog programs.

Module statements are inserted in the flow logic to designate which ABAP/4 modules will be executed.

By double clicking on the module name, ‘forward navigation’ will create the empty ABAP/4 module for you in the appropriate include program.

PBO and PAI modules are developed in ABAP/4.

PBO module statements are followed by OUTPUT and PAI module statements are followed by INPUT.

PBO and PAI modules should be placed in separate include programs.

All ABAP/4 statements are placed between the MODULE and ENDMODULE statements.

[former_member188829]

Hi,

SAPMDEMO_TRANSACTION in SE80 Transaction

http://www.geocities.com/ZSAPcHAT

Message was edited by:

Vishnu Reddy

[Former Member]

Hi,

Pls check this thread :

Should be helpful to you.

Regards,

Lalit Kabra