topic Re: when to use module pool in Application Development and Automation Discussions

when to use module pool

Former Member — Thu, 20 Mar 2008 12:39:30 GMT

Hi experts,

could any one give me inf abt module pool i.e. when to use and what are the main benefits by using that.

Thanks in advance.

Krishna

Re: when to use module pool

Former Member — Thu, 20 Mar 2008 13:41:27 GMT

Hi Krishna,

What is module pool program in simple words

Module pools are programs that provide a user fairly good and continuous interaction with the system..take the example of standard transactions in modules like SD,MM..etc...

eg: Sales Order creation ->VA01/02/03 -> program SAPMV45A

is a module pool program..here first screen we enter some data,press some buttons it will take you to another screen and session involves a lot of interaction until you save the data with correct validations.

Module pools..where are they used?

Generally module pools are used when user decides to adda process/scenario that involved multiple screens and/or complex processing logic and validations

eg: consider the creation of sales order in standard screen itself..it is a basic process/step in itself and forms a part of the entire sales module

We can also have module pools that stand independently but in the end they focus on satisfying a user's business process

Main Benifits

You can provide a variety of screen interfaces like tabstrips,ALVs,table controls,pop-ups...and at the same time support complex functionality of the user

Pls revert if you need any specific clarifications

Reward if helpful

Regards

Byju

Re: when to use module pool

Former Member — Mon, 24 Mar 2008 12:11:45 GMT

Hi Byju Edamana,

Thanks a lot for u r reply. Could u pls give some inf abt chain , endchain , pbo and pai.

Regards,

Krishna

Re: when to use module pool

Former Member — Mon, 24 Mar 2008 12:42:46 GMT

Here is a coding example


PROCESS BEFORE OUTPUT.
* MODULE STATUS_0105.
  MODULE init_0105.
*
PROCESS AFTER INPUT.

  CHAIN.
    field zlmref-kunnr.

    MODULE check_customer_number.
  ENDCHAIN.

  CHAIN.
    FIELD: ZLMREF-STATE.

    MODULE edit_state_0105.
  ENDCHAIN.


  CHAIN.
    FIELD: refphone1-area,
           refphone1-pref,
           refphone1-sufx.

    MODULE refphone1_nbrs_0105.
  ENDCHAIN.

  CHAIN.
    FIELD: refphone2-area,
           refphone2-pref,
           refphone2-sufx.

    MODULE refphone2_nbrs_0105.
  ENDCHAIN.

  MODULE user_command_0105.

All of the fields listed in teh CHAIN/ENDCHAIN will be open for input if there is an error, all other fields will be output only.

Example of an edit module


*&---------------------------------------------------------------------*
*&      Module  edit_state_0105  INPUT
*&---------------------------------------------------------------------*
MODULE edit_state_0105 INPUT.
  CHECK rb_rt_none NE 'X'.
  CHECK zlmref-state NE space.

  PERFORM edit_state USING  zlmref-state.
ENDMODULE.                 " edit_state_0105  INPUT

*&---------------------------------------------------------------------*
*&      Form  edit_state
*&---------------------------------------------------------------------*
FORM edit_state USING    p_state.

  CHECK mode NE c_display.

  SELECT SINGLE * FROM t005s
    WHERE land1 = 'US'
      AND bland = p_state.

  CHECK NOT sy-subrc = 0.
  MESSAGE e084.

ENDFORM.                    " edit_state

Re: when to use module pool

Former Member — Tue, 25 Mar 2008 05:12:38 GMT

Hi,

ABAP/4 Module Pool

In the Object Browser, the module pool code belongs to one of the following categories:

Global fields: data declarations that can be used by all modules in the module pool

PBO modules: modules that are called before displaying the screen

PAI modules: modules that are called in response to the user input

Subroutines: subroutines that can be called from any position within the module pool

By default, the system divides a module pool into one or several include programs. An include program can contain several modules of the same type (only PBO modules or only PAI modules). The main program then consists of a sequence of INCLUDE statements that link the modules to the module pool:

*&----

*& Module pool SAPMTZ10

*&----

*& Display data of Table SPFLI

*&----

Global data

INCLUDE MTZ10TOP.

PAI modules

INCLUDE MTZ10I01.

PBO modules

INCLUDE MTZ10O01.

In the ABAP/4 editor, you can display the code hidden behind the INCLUDE statements by choosing Edit ---> More functions ---> EXPAND include. With all INCLUDE statements expanded, the module pool looks like this:

*&----

*& Module pool SAPMTZ10

*& FUNCTION: Display data from Table SPFLI

*&----

*----

INCLUDE MTZ10TOP (This is the TOP include:
the TOP module contains global data declarations)

*----

PROGRAM SAPMTZ10.

TABLES: SPFLI.

DATA OK_CODE(4).

*----

INCLUDE MTZ10I01 (This is a PAI include.)

*----

*&----

*& Module USER_COMMAND_0100 INPUT

*&----

Retrieve data from SPFLI or leave transaction

*----

MODULE USER_COMMAND_0100 INPUT.

CASE OK_CODE.

WHEN 'SHOW'.

CLEAR OK_CODE.

SELECT SINGLE * FROM SPFLI WHERE CARRID = SPFLI-CARRID

AND CONNID = SPFLI-CONNID.

WHEN SPACE.

WHEN OTHERS.

CLEAR OK_CODE.

SET SCREEN 0.

LEAVE SCREEN.

ENDCASE.

ENDMODULE.

*----

INCLUDE MTZ10O01 (This is a PBO include.)

*----

*&----

*& Module STATUS_0100

*&----

Specify GUI status and title for screen 100

*----

MODULE STATUS_0100.

SET PF-STATUS 'TZ0100'.

SET TITLEBAR '100'.

ENDMODULE.

You use the ABAP/4 Dictionary to store frequently used data declarations centrally. Objects defined in the Dictionary are known throughout the system. Active Dictionary definitions can be accessed by any application. Data defined in the Dictionary can be included in a screen or used by an ABAP/4 program. You declare global data in the TOP module of the transaction, using the TABLES, STRUCTURE, LIKE statements and others. Transaction TZ10 accesses the Dictionary definition of Table SPFLI to provide the desired flight data display. If the TOP include contains the TABLES: SPFLI declaration, all modules in the module pool can access the table fields of Table SPFLI.

The PAI module USER_COMMAND_0100 checks which pushbutton the user activated (CASE OK_CODE). The Display pushbutton in Transaction TZ10 has the function code 'SHOW'. The program then tries to select those records in the SPFLI database that correspond to the data the user entered. The WHERE condition determines matching records by comparing the fields SPFLI-CARRID and SPFLI-CONNID with the database key fields CARRID and CONNID. As soon as a matching record is found, the database transfers all accompanying SPFLI fields to the program table.

When the screen is displayed again, the complete information appears in the output fields of the screen. The system automatically displays these fields, since the ABAP/4 field names SPFLI-CARRID and SPFLI-CONNID are the same as the screen field names.

In the PBO module STATUS_0100 of Transaction TZ10, the screen 100 receives a GUI status (using SET PF-STATUS) and a GUI title (using SET TITLEBAR):

SET PF-STATUS 'TZ0100'.

SET TITLEBAR '100'.

A GUI status is a subset of the interface elements used for a certain screen. The status comprises those elements that are currently needed by the transaction. The GUI status for a transaction may be composed of several elements.

The GUI title is the screen title displayed in the title bar of the window. In contrast to the GUI status that can be used for several screens, a GUI title belongs to one screen.

To create and edit GUI status and GUI title, you use the Menu Painter. To start the Menu Painter, create a GUI status or GUI title in an object list in the Object Browser (or double-click on an existing status or title).

with regards,

sowjanyagosala

Re: when to use module pool

Former Member — Tue, 25 Mar 2008 09:12:15 GMT

If your ABAP program requires a user dialog then dialog programming is required.

A user dialog is any form of interaction between the user and the program :

Entering data

Choosing a menu item

Clicking a button

Clicking or double clicking an entry

It is also used when we need to navigate back and forth between screens

Programs which are partially or wholly user dialog driven CAN NOT BE EXECUTED IN BACKGROUND. They are therefore referred to as Dialog programs.

Dialog programming skills are useful for developing bolt on functionality and for performing enhancements in standard R/3 applications.

Dialog programs are created with type as ‘M’ – Module Pool. They cannot be executed independently and must be attached to at least one transaction code in which you specify an initial screen.

Why Dialog Programming

Most of Business applications now a days require manual input of data that must be available at a later time.

Interface between system and user should be as comfortable and friendly as possible.

Logical coherence of the data and correct processing should also be guaranteed.

Reports:

As you have previously explored, a report is a program that typically reads and analyzes data in database tables without changing the database.

Dialog Programs:

A dialog program allows you to work interactively with the system and to change the contents of the database tables. Each dialog program has a certain sequence of screens that are processed by the system one after the other.

From the view of a user, a dialog step consists of receiving a screen for entering data, then after the users clicks a button or selects a menu entry, processing is started. From the view of the SAP system, the screen is prepared and sent. After this, the user receives it and fills it out. Then the system analyzes and processes the data contained on the screen after receiving it from the user.

A dialog program must offer:

a user-friendly user interface

format and consistency checks for the data entered by the user

easy correction of input errors

access to data by storing it in the database.

Thanks and regards

palak behal

reward if helpful

Re: when to use module pool

Former Member — Thu, 27 Mar 2008 05:28:09 GMT

Thanks alot for u r clarrification...