Module pool programming for ABAP Beginners

• 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

  • All MPP program names should start with SAPMZ

  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]].

   

  • —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.