topic Re: Modlue programming guide! in Application Development and Automation Discussions

Modlue programming guide!

Former Member — Tue, 04 Mar 2008 09:59:24 GMT

Need some help in module pool programming guide !

Re: Modlue programming guide!

Former Member — Tue, 04 Mar 2008 10:01:09 GMT

Hi,

MODULE POOL PROGRAMMING (MPP):

These are type M programs in SAP.
These programs cannot be executed directly.
Transaction Codes (Tcodes) are used to execute MPP programs.
Graphical Screen PAinter is the tool used to create GUI in MPP (SE51).
MPP programs are created using the transaction code SE80.
MPP programs should start with the naming convention SAPMZ or SAPMY.

EVENTS ASSOCIATED WITH SELECTION-SCREEN:

INITIALIZATION

AT SELECTION-SCREEN

START-OF-SELECTION

TOP-OF-PAGE

END-OF-PAGE

END-OF-SELECTION.

EVENTS ASSOCIATED WITH MPP:

1. PROCESS BEFORE OUTPUT (PBO) - Used to specify initial attributes for the screen.

2. PROCESS AFTER INPUT (PAI) - Used to specify

event functionalities for the components of the screen.

COMPONENTS OF MPP PROGRAM:

1. ATTRIBUTES - It holds description about the screen.

2. FLOW LOGIC - This is an editor for MPP programs to specify event functionality for the screen components.

3. ELEMENT LIST - This provides description about the components created in the screen.

TYPES OF SCREEN IN MPP:

1. NORMAL SCREEN - A screen which has maximizing, minimizing and closing options

is referred to as normal screen.

2. SUBSCREEN - A screen within a normal screen with either of above three options

is referred to as subscreen.

3. MODAL DIALOG BOX - A screen with only closing option which is used to provide

information to the end user is referred to as modal dialog box.

NAVIGATIONS TO CREATE A SIMPLE MPP PROGRAM:

SE80 -> Select Program from the dropdown list -> SPecify program name starting with SAPMZ or SAPMY (eg. SAPMYFIRSTMPP) -> Press Enter -> Click on Yes to Create object -> Opens another dialog box -> Click on Continue to create Top Include File for the program -> Opens another dialog box specifying TOP INCLUDE FILE name (MYFIRSTMPPTOP) -> Click on Continue -> Opens Program Attributes screen -> Enter short description -> The default program type is M -> Save under a package -> Assign Request number -> A folder with specified program name(SAPMYFIRSTMPP) is created with Top Include File.

To create a screen, right click on program name -> Create -> SCreen -> Opens dialog box

-> Specify Screen number (100) -> Continue -> Opens an interface -> Enter short description

-> Select Screen type as Normal -> Click on LAYOUT pushbutton from appn. toolbar

-> Opens Graphical Screen painter -> Drag and drop two input fields, two pushbuttons and

two text fields -> Double click on each component to specify attributes as follows:

INPUT FIELDS: IO1, IO2

FIRST PUSHBUTTON : PB1, PRINT, PRINT

SECOND PUSHBUTTON : PB2, EXIT, EXIT

TEXT FIELDS : LB1 (ENTER NAME), LB2 (ENTER CITY)

-> Save -> Click on Flowlogic Pushbutton from appn. toolbar -> Opens Flow Logic editor

with two events (PA1 and PBO).

To specify event functionalities for screen components,

decomment PAI Module name (USER_COMMAND_0100)

-> Double click on module name -> Click on Yes to create object -> Opens an interface

-> Select Program name from the list -> Continue -> Click on Yes to save the editor

-> Opens PAI module and specify following code:

CASE SY-UCOMM.

WHEN 'PRINT'.

LEAVE TO LIST-PROCESSING.

WRITE 😕 IO1, IO2.

WHEN 'EXIT'.

LEAVE PROGRAM.

ENDCASE.

In TOP INCLUDE FILE, declare input fields as follows:

DATA : IO1(20), IO2(20).

Save -> Activate -> Right click on Program name -> Activate (to activate all inactive objects).

To execute MPP program, right click on program name -> Create -> Transaction

-> Opens an interface -> Specify Tcode starting with Z or Y (zfirstmpp) -> Enter short description -> Continue -> Specify Main program name (SAPMYFIRSTMPP) and initial Screen number (100) -> Save under a package -> Assign a request number -> Execute.

TOP INCLUDE FILE is an area to declare variables for the program, and the variables declared here becomes globally accessed.

SCREEN VALIDATION USING MPP:

SCREEN is a predefined structure used to make MPP screen validations dynamically. SCREEN has following components:

GROUP1

INVISIBLE

REQUIRED

INPUT

OUTPUT

INTENSIFIED

IF SCREEN-INVISIBLE = 0 - Sets the input field values as visible.

SCREEN-INVISIBLE = 1 - Sets the input field as password field.

SCREEN-REQUIRED = 0 - Not a mandatory field.

SCREEN-REQUIRED = 1 - Sets input field as mandatory one.

Eg. code to perform validation dynamically for a login screen:

1. Create an MPP program.

2. Create a Normal Screen like initial login screen.

3. Assign IO1, IO2 to group GR1, IO3 to GR2.

4. In Top Include file, declare variables.

5. In PBO, specify following code:

LOOP AT SCREEN.

IF SCREEN-GROUP1 = 'GR1'.

SCREEN-REQUIRED = '1'.

ENDIF.

IF SCREEN-GROUP1 = 'GR2'.

SCREEN-INVISIBLE = '1'.

ENDIF.

MODIFY SCREEN. * to update the changes made to the predefined structure.

ENDLOOP.

6. In PAI, specify following code:

CASE SY-UCOMM.

WHEN 'LOGIN'.

CALL TRANSACTION 'SE38'.

WHEN 'EXIT'.

LEAVE PROGRAM.

ENDCASE.

7. Create a Tcode -> Activate all -> Execute.

INSERTING RECORDS FROM MPP SCREEN INTO DATABASE TABLE:

1. Create an MPP program.

2. In Top Include File, declare an internal table as follows:

DATA IT_KNA1 LIKE KNA1 OCCURS 0 WITH HEADER LINE.

-> Save -> Activate.

3. Create a screen -> In Screen Painter, click DICTIONARY/PROGRAM FIELDS (F6)

pushbutton from appn. toolbar -> Opens an interface

-> Specify internal table name -> Click on GET FROM PROGRAM pushbutton

-> Select required fields -> Continue -> Paste on Screen Painter

-> Create two pushbuttons (INSERT, EXIT) -> Save -> Flow logic.

4. In PAI, specify following code:

CASE SY-UCOMM.

WHEN 'INSERT'.

INSERT INTO KNA1 VALUES IT_KNA1.

IF SY-SUBRC = 0.

MESSAGE S000(ZMSG).

ELSE.

MESSAGE W001(ZMSG).

ENDIF.

WHEN 'EXIT'.

*LEAVE PROGRAM.

SET SCREEN 0.

ENDCASE.

5. Create a Tcode -> Activate all -> Execute.

LIST OF VALUES:

Adding dropdown facility to the input fields is called as LIST OF VALUES.

VRM is a predefined type group which has the following structure and internal table:

VRM_VALUE is a structure with the components KEY and TEXT.

VRM_VALUES is an internal table declared for the above structure without header line.

The above type group is used to fetch values from the internal table declared with user-defined records and insert into the input field in the screen.

'VRM_SET_VALUES' is a function module used to carry the records from the internal table and populate in the input field.

NAVIGATIONS TO CREATE DROPDOWN FACILITY FOR INPUT BOX:

1. Create MPP program.

2. Create a screen.

3. Add a input box -> Double click -> Specify name (IO1) -> Select LISTBOX from the dropdown list -> A dropdown facility is added for the input field in the screen.

4. Create two pushbuttons (PRINT, EXIT).

5. In Top Include File, specify following code:

TYPE-POOLS VRM.

DATA IO1(20).

DATA A TYPE I.

DATA ITAB TYPE VRM_VALUES. * To create an internal table of an existing type

DATA WA LIKE LINE OF ITAB. * To create a temporary structure of sameline type of internal table.

6. In PBO, specify following code:

IF A = 0.

WA-KEY = 'ABAP'.

WA-TEXT = 'ADVANCED PROGRAMMING'.

APPEND WA TO ITAB.

WA-KEY = 'BW'.

WA-TEXT = 'BUSINESS WAREHOUSING'.

APPEND WA TO ITAB.

WA-KEY = 'EP'.

WA-TEXT = 'ENTERPRISE PORTAL'.

APPEND WA TO ITAB.

CALL FUNCTION 'VRM_SET_VALUES'

EXPORTING

ID = 'IO1'

VALUES = ITAB.

A = 1.

ENDIF.

7. In PAI, specify following:

CASE SY-UCOMM.

WHEN 'PRINT'.

LEAVE TO LIST-PROCESSING.

WRITE 😕 IO1.

WHEN 'EXIT'.

LEAVE PROGRAM.

ENDCASE.

8. Create a Tcode -> Activate all -> Execute.

CREATING TABSTRIPS IN MPP:

In a normal screen, we can add only maximum of 40 components.

To make a screen hold more than 40 components, we can use tabstrip controls.

NAVIGATIONS TO CREATE TABSTRIP CONTROL:

1. Create an MPP program.

2. Create a normal screen (100)

-> Add Tabstrip Control component from toolbar

-> By default, a tabstrip control is created with 2 tab buttons

-> Double click on tabstrip control

-> Specify name (TBSTR) in Attributes box

-> Click on First tab button

-> Add Subscreen Area from toolbar to first tab button

-> Double click on subscreen area

-> Specify name (SUB1)

-> Click on Second tab button

-> Repeat same process for adding subscreen area (SUB2)

-> Double click on First tab button

-> Specify attributes (TAB1,FIRST,TAB1)

-> Double click on Second tab button

-> Specify attributes (TAB2, SECOND, TAB2)

-> SAve

-> Flowlogic.

3. Create two subscreens (10, 20) -> Add required components in each subscreen.

4. In Top Include File, specify following code:

DATA : IO1(10), IO2(10), IO3(10), IO4(10).

CONTROLS TBSTR TYPE TABSTRIP.

DATA A LIKE SY-DYNNR.

'CONTROLS' statement is used to allocate a memory area for the tabstrip created in the normal screen. 'TABSTRIP' itself is a data type for the tabstrip control. Whenever a tabstrip is created, SAP creates an object called 'ACTIVETAB' which is used to call the corresponding subscreens for each tab button in PAI.

5. In Flowlogic editor, write following code to initiate the subscreens to the corresponding subscreen areas of each tab button when the main screen is called:

PROCESS BEFORE OUTPUT.

MODULE STATUS_0100.

CALL SUBSCREEN SUB1 INCLUDING 'SAPMZTABSTRIP' '10'.

CALL SUBSCREEN SUB2 INCLUDING 'SAPMZTABSTRIP' '20'.

PROCESS AFTER INPUT.

MODULE USER_COMMAND_0100.

CALL SUBSCREEN SUB1.

CALL SUBSCREEN SUB2.

6. In PAI, specify following code for click events on each tab button:

CASE SY-UCOMM.

WHEN 'TAB1'.

A = '10'. * calls specified subscreen during PAI

TBSTR-ACTIVETAB = 'TAB1'. * makes entire tab button in active status

WHEN 'TAB2'.

A = '20'.

TBSTR-ACTIVETAB = 'TAB2'.

WHEN 'DISPLAY'.

LEAVE TO LIST-PROCESSING.

WRITE 😕 IO1, IO2, IO3, IO4.

WHEN 'EXIT'.

LEAVE PROGRAM.

ENDCASE.

7. Create a Tcode -> Activate all -> Execute.

TABLE CONTROLS:

Table Control component is used to view the internal table contents in the screen.

Navigations to create Table control component:

1. Create an MPP program.

2. In Top include File, declare variables as follows:

DATA ITAB LIKE KNA1 OCCURS 0 WITH HEADER LINE.

DATA ITAB1 LIKE KNA1 OCCURS 0 WITH HEADER LINE.

CONTROLS TBCL TYPE TABLEVIEW USING SCREEN 100.

DATA CUR TYPE I VALUE 5.

-> Save -> Activate.

3. Create a Screen (100) -> Select Table control component from toolbar -> Double Click and specify name (TBCL) -> Press F6 and specify internal table name (ITAB) -> Select required fields -> Paste on the Table control -> To separate the fields, use Separators option in Table control Attributes -> Specify labels if necessary -> Create pushbuttons (FETCH, MODIFY, PRINT, EXIT) -> Save -> Flowlogic.

4. In PAI module, specify following code:

CASE SY-UCOMM.

WHEN 'FETCH'.

SELECT * FROM KNA1 INTO TABLE ITAB.

TBCL-LINES = SY-DBCNT. * To create Vertical Scrollbar

WHEN 'EXIT'.

LEAVE PROGRAM.

WHEN 'PRINT'.

GET CURSOR LINE CUR.

READ TABLE ITAB INDEX CUR.

LEAVE TO LIST-PROCESSING.

WRITE 😕 ITAB-KUNNR, ITAB-NAME1, ITAB-ORT01, ITAB-LAND1.

WHEN 'MODIFY'.

LOOP AT ITAB1.

MODIFY KNA1 FROM ITAB1.

IF SY-SUBRC = 0.

MESSAGE S002(ZMSG).

ELSE.

MESSAGE E003(ZMSG).

ENDIF.

ENDLOOP.

SELECT * FROM KNA1 INTO TABLE ITAB.

TBCL-LINES = SY-DBCNT.

ENDCASE.

5. In FlowLogic editor, specify following step loops:

PROCESS BEFORE OUTPUT.

MODULE STATUS_0100.

LOOP AT ITAB CURSOR CUR WITH CONTROL TBCL.

ENDLOOP.

PROCESS AFTER INPUT.

MODULE USER_COMMAND_0100.

LOOP AT ITAB.

MODULE NEW. * New module to move records from ITAB to ITAB1. Double click on Module Name (New) to create a new one.

ENDLOOP.

6. Specify following code in the NEW module:

MODULE NEW INPUT.

APPEND ITAB TO ITAB1.

ENDMODULE.

7. Create a Tcode -> Activate all -> Execute.

USING TABLE CONTROL WIZARD:

This is a predefined SAP-specific component to create table control using predefined navigations.

1. Create an executable program (Z_TABLEWIZARD) in SE38 editor. Write the following code:

CALL SCREEN 200.

-> Save -> Activate.

2. Goto SE51 -> Specify program name created earlier (Z_TABLEWIZARD) -> Specify Screen number (200) -> Layout -> Select Table Control (Wizard) component from toolbar -> Opens Table control Wizard -> Follow the navigations -> Save and Activate the table control.

3. Execute the program (Z_TABLEWIZARD).

Regards,

Priya.

Re: Modlue programming guide!

Former Member — Tue, 04 Mar 2008 10:01:53 GMT

Hi,

simple and easy way to understand Module pool...with step by step procedure:

MODULE POOL PROGRAMMING:

These are type M programs in SAP.
MPP programs should start with the naming convention SAPMZ or SAPMY.
MPP programs are used to create and assign a user-defined screen to the Transaction Code.
Each screen created in MPP is assigned a screen number. This screen number is assigned to a Tcode.
MPP programs cannot be executed directly. Tcodes are used to execute these programs.

EVENTS IN MPP:

PROCESS BEFORE OUTPUT (PBO)

PROCESS AFTER INPUT (PAI)

PROCESS ON VALUE REQUEST - To provide F4 functionality to MPP program screen i/p fields.

PROCESS ON HELP REQUEST - To provide F1 functionality to MPP program screen components.

Navigations to create a simple MPP program:

SE80 -> Select Program from drop-down list -> Specify program name starting with SAPMZ or SAPMY -> Press Enter -> Click on Yes to create object -> Create Top Include File by clicking on Continue icon in pop-up screens -> Save under a package -> Assign a request number -> MPP program with specified name is created with Top include File.

To create screen, Right click on program name -> Select Create -> Screen -> Opens Screen Description page -> Enter short description for screen -> Select screen type as NORMAL -> Click on LAYOUT pushbutton from application toolbar -> Opens Screen Painter -> Drag and drop two input fields from toolbar -> Likewise, create two pushbuttons -> Double click on each component -> Opens Attributes box -> Specify attributes for each screen component -> For pushbutton, specify FCT code -> Save the screen -> Click on Flowlogic pushbutton from application toolbar -> Opens Flow logic editor to create event functionalities for screen components -> Decomment PAI module -> Double click on PAI module name -> Click on Yes to create PAI module object -> Opens PAI module -> Specify the following code within module-endmodule statements:

CASE SY-UCOMM.

WHEN 'DISPLAY'.

LEAVE TO LIST-PROCESSING.

WRITE 😕 IO1, IO2.

WHEN 'EXIT'.

LEAVE PROGRAM.

ENDCASE.

-> Save.

Now double click on 'Includes' Folder (TOP INCLUDE FILE) -> Declare variables for input fields as follows:

DATA : IO1(10), IO2(10).

Save -> Activate.

Now To create Transaction Code, right click on Main Program Name -> Create -> Transaction -> Opens an interface -> Enter Tcode name starting with Z or Y -> Enter short description -> Continue -> Opens interface -> Enter Main program name and Screen number to be called first -> Save under a package -> Assign a request number.

Activate all the objects of MPP program by right clicking on Main program Name -> Click on Activate -> Raises 'Objects Activated' message.

To execute the MPP program, specify Tcode name in the Command Prompt area -> Press Enter.

MPP SCREEN VALIDATIONS:

Eg. code to make field validations in MPP program:

Using screen painter, design a screen consisting of four input fields for client, username, password and language as we have in login screen of SAP.

Assign the first two input fields to one group called GR1, the third input field to a group GR2.

Create two pushbuttons and assign FCT codes.

In the TOP INCLUDE FILE, declare following variables:

PROGRAM SAPMYSCREENVALID.

DATA : IO1(3), IO2(8), IO3(8), IO4(2).

DATA A TYPE I.

Save -> Activate.

In Flow logic editor, decomment PAI MODULE, double click on module name, and inside the module, write the following code:

module USER_COMMAND_0200 input.

case sy-ucomm.

WHEN 'LOGIN'.

CALL TRANSACTION 'SE38'.

WHEN 'EXIT'.

LEAVE PROGRAM.

ENDCASE.

endmodule. " USER_COMMAND_0200 INPUT

Save -> Activate.

In PBO module, write the following code to assign default input field attributes:

module STATUS_0200 output.

SET PF-STATUS 'xxxxxxxx'.
SET TITLEBAR 'xxx'.

IF A = 0.

MESSAGE S010(ZMSG).

LOOP AT SCREEN.

IF SCREEN-GROUP1 = 'GR1'.

SCREEN-REQUIRED = '1'.

ENDIF.

IF SCREEN-GROUP1 = 'GR2'.

SCREEN-INVISIBLE = '1'.

ENDIF.

MODIFY SCREEN.

ENDLOOP.

A = 1.

ENDIF.

endmodule. " STATUS_0200 OUTPUT

Save -> Activate.

Create a Transaction Code -> Execute the program.

Regards,

Arunsri

Re: Modlue programming guide!

arpit_shah — Tue, 04 Mar 2008 10:02:10 GMT

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

and pls check following links

http://www.geocities.com/ZSAPcHAT

Re: Modlue programming guide!

Former Member — Tue, 04 Mar 2008 10:07:00 GMT

Module Pool Programming

This component though is not attached to the screen painter, plays important role in transaction. Normally, for reports, on line executable programs are written but for transaction, Module Pool Programs are written. The module pool program contains only modules to handle various events associated with screen and data declaration statements.

System divides the module pool program into several include program. These are global field, PBO modules, and PAI modules. It is entirely user’s decision whether to use these modules or write directly into main program.

Creation of Module Pool Program

You can create module pool program either through

Object browser

System automatically creates the module pool program and for these program which are created through object browser, system creates the include modules.

ABAP/4 editor

It is similar to normal program creation. Type of program should be given ‘M’ and is not created by system.

Communication between Dynpro and Module Program

For each screen, the system executes the flow logic, which contains corresponding events. The control is passed to Module Pool Program. Module Pool Program handles the code for these events and again passes back control to the flow logic and finally to screen. Unlike on line program, in this case, the control remains with flow logic. The switching of control between flow logic and module pool program and back is common process when user executes transaction.

Creation of a Complete Transaction

Steps involved to create a complete transaction

• Create module pool program.

• From screen painter create screens.

• Write flow logic for each screen.

• Write code for all the events in module pool program.

• Check for any error in screen and flow logic.

• Generate each and every component of screen i.e. flow logic and screen.

• Single screen can be tested using Screen Painter.

• Create transaction code through object browser.

• Generate the transaction code.

• User can execute the transaction by entering the transaction code in the command field.

Handling Function Code

The function code or OKCODE is the last field of Field list. Function code can be handled as follows:

During the Designing of the screen, a function code is assigned to pushbutton.

• In field list, developer needs to specify OKCODE as last field.

• In module program it is a global field and can be evaluated in the PAI event.

• A function code is treated in the same way, regardless it comes from pushbutton, menu item or any other GUI element.

A complete example for transaction is shown below:

If you have a screen like the one below:

When the user clicks on the Display button, you want to display details of sflight, with corresponding carrid and connid (which is entered by the user).

Module pool program to handle this particular screen is as follows:

Program YVTEST7.

TABLES: SFLIGHT.

DATA: OKCODE (4).

MODULE INPUT1 INPUT,

CASE OKCODE.

WHEN ‘DISP’.

SELECT * FROM SFLIGHT

WHERE CARRID = SFLIGHT – CARRID AND

CONNID = SFLIGHT – CONNID.

ENDSELECT.

LEAVE TO SCREEN 200.

WHEN ‘EXIT’. LEAVE TO SCREEN 0.

ENDCASE.

ENDMODULE. “INPUT1 INPUT

MODULE USER_COMMAND_0200 INPUT.

CASE OKCODE.

WHEN ‘BACK’. LEAVE TO SCREEN 100.

ENDCASE.

ENDMODULE. “USER_COMMAND_0200 INPUT

When the user clicks on display, control is transferred to screen no. 200 on which you display sflight details & on the same screen, when user clicks on BACK button, he comes back to main screen.

Flow logic for screen 100 is as follows:

PROCESS AFTER INPUT.

MODULE INPUT.

Flow logic for screen 200

PROCESS AFTER INPUT.

USER_COMMAND_0200.

MODULES: Modules are handled in module pool program.

You need to write flow logic for screen 200 and design screen 200.

In case of transaction transfer of data from program to screen is automatic i.e. you need not transfer the data from program to screen explicitly. The fields, which you define in the screen receives the data from program and displays the same.

The Field Checks

As already mentioned Transaction is the only method, which SAP recommends to update the database tables. Data entered in the database table should be valid and correct. Data entered is validated at each and every point. ABAP/4 offers various methods to validate data and those are as follows:

• Automatic field checks

• Checks performed in the flow logic

• Checks performed in the ABAP/4 module pool program

Automatic Field Checks

These checks are based on the field information stored in the dictionary. These checks are performed by the system automatically when the user enters the data for the screen field. System performs these checks before PAI event is triggered. Types of field checks performed by system are as follows:

• Required input

While designing the screen, for particular screen field if you click the Req. Entry checkbox, the field becomes mandatory. When the transaction is executed if user leaves this particular field blank, the system displays error message. User cannot proceed until the user enters some data.

• Proper Data Format

Each field has its own data format whether it is table field or screen field. Whenever data is entered, system checks for the proper format of the data. For example date. Each user has its own format for date, which is defined in the user master record. If the date defined in the user master record is in the format DD/MM/YYYY, if the user enters the date, say, in YY/DD/MM, the user displays the error message. System also checks for the value of month or days. For example if month entered is greater than twelve then the error message is displayed.

• Valid Value for the Field

In data dictionary two tables are related by Primary key-Foreign key relationship. Whenever the user enters the data, the system checks for the check table values. Also in Domain, if you have fixed values, then the system checks for these values.

Automatic field checks are repeated each time the user enters the data.

About at Exit – Command

Automatic field checks can be avoided by AT EXIT-COMMAND, which works exactly the same way as Cancel works on application tools bar. In the R/3 screen, if you want to quit the processing of that particular screen without entering the mandatory fields, user can click the Cancel button. Same functionality can be incorporated in the user-defined transaction by using AT EXIT-COMMAND. This module can be called before the system executes the automatic field checks and it goes without saying that before PAI event. Code for AT EXIT-COMMAND in flow logic and in module pool program can be written as follows:

In Flow Logic

Process After Input.

Module exit AT EXIT-COMMAND.

In module pool program.

Module exit.

Case okcode.

When ‘Exit’.

Leave to screen 0.

To achieve this kind of functionality a pushbutton or menu item should be assigned a function type ‘E’. It tells the system to process this particular module before carrying out any field checks.

Flow Logic Validations

Consider the case where you want user to enter only ‘LH’ and ‘SQ’ for sflight-carrid. In this case, you are restricting value of a screen field. This cannot be achieved by automatic field check. Hence there is a need of additional validation. It can be done in flow logic by using following statement:

Field -

Values

Syntax

PAI.

Field sflight-carrid values (‘LH’).

For multiple values

PAI.

Field sflight-carrid values (‘LH’ ‘SQ’).

Field sflight-price values (between 1000 and 2000).

In this case when the user enters the value, PAI is triggered and field is checked for that particular value. If the value entered happens to be wrong, that field is enabled for user to enter. If you have multiple Field statements in your flow logic, it is sequential execution.

Consider the following case:

PAI.

Module assign.

Field sflight-carrid values (‘LH’ ‘SQ’).

In ABAP/4

Module assign.

Data: carrid1 like sflight-carrid.

Carrid1 = sflight-carrid.

Endmodule.

In this case, Sflight-carrid is used in the flow logic before the field statement. The system will give invalid value or some previous value as the field sflight-carrid is used in module before it is checked i.e., field statement is after the module in which sflight-carrid is being used. The field is not available to the system unless it executes the field statement. Field statement transfers the values to the program and is done only once. If you don’t have Field statement in your flow logic, transfer of values takes place in PAI event.

Consider one more case where you have multiple field statement.

PAI.

Field Sflight-carrid values (‘LH’).

Field Sflight-connid values (‘0400’ ‘0500’).

In this case if the user enters only carrid wrong, then this particular field is enabled and rest of the fields are disabled for user to input. Many times if the user enters wrong value for one field, then you might want to give option to user to enter all the fields, which is not possible by using Field statement only. This functionality can be achieved by CHAIN – ENDCHAIN.

Syntax

Chain.

Field sflight-carrid value (‘LH’).

Field sflight-connid values (between ‘200’ and ‘500’).

Endchain.

Field sflight-price values (‘100’ ‘1000’).

In this case, if the user enters wrong value only for carrid, both the fields i.e. carrid and connid are enabled as they are grouped together in the Chain statement. The field price will be disabled for input. Usually, logically related fields are grouped together with Chain-Endchain statement.

Module Pool Program Validations

Checking fields ABAP/4 program includes

• Field statement in flow logic.

• Module statement in ABAP/4 module pool Program.

Syntax

PAI.

Field sflight-carrid module <name>.

This module can be handled in the main program i.e. module pool program.

In ABAP/4 program

Module Check.

Select single * from sflight where carrid = sflight-carrid.

If sy-subrc ne 0.

Message e001.

Endif.

In this case, field sflight-carrid is checked in the table for its existence.

Dynamically Calling the Screens

About Displaying Next Screen

Transaction is a sequence of screens, which are displayed one after the other. The next screen displayed depends upon the attributes of first screen. In attributes you need to give Next Screen number i.e. if next screen displayed should be 200 screen, then this number should be given in next Screen attributes. These are static attributes of the screen. By default, if nothing is specified in the program, the system branches out to the screen number, which is specified in the attribute screen.

In this case, if user selects MARA pushbutton, then fields from Mara table are displayed. When the user clicks on the MARD, then the fields from MARD table are displayed. Depending upon users selection, the screen is branched out and this has to be done during runtime. This functionality can be achieved by dynamically calling the screen in module pool program.

The screen can branch out to new screen depending upon user selection. Following command in module pool program can do this:

• SET SCREEM

• CALL SCREEN

• LEAVE TO SCREEN <NUMBER>

All these commands override the specifications given in the attributes. This overriding is temporary. The values stored in the attribute are not changed.

Set Screen

Syntax

Set screen <number>.

In module pool program

Case okcode.

When ‘DISP’.

Set screen 200.

When ‘LIST’.

Set screen 300.

Endcase.

In this case, the entire processing of current screen takes place and then the system branches out to next screen. If you want to branch out to the next screen without processing the current screen, LEAVE SCREEN should be used along with the SET SCREEN.

For Example:

Case okcode..

When ‘DISP’.

Set screen 200.

Leave Screen.

When ‘LIST’.

Set screen 300.

Leave Screen.

Endcase.

When SET SCREEN is used, control cannot be transferred to the main screen or previous screen, unless you write code for the same.

Call Screen

Usually used for pop up screens. Many times, there is a need for user to enter additional information or secondary information on another screen or pop up screen. Once the user enters the data, he should be able to go back to main screen or to the screen where he started. This is not possible by using SET SCREEN. CALL SCREEN achieves this functionality.

Syntax

Call Screen 200.

Will simply call a screen number 200 from a main screen. Once the screen is displayed the user can enter all the data and return to the main screen by clicking BACK button.

To call screen as pop up screen the syntax is

Call screen starting at <col.no.> <line no>

Ending at <col no> <line no>.

In this case window will be popped as window and user can close it by using BACK button.

Leave to screen

To SET a new screen without processing current screen, you need to use the following two statements together:

SET SCREEN 200.

LEAVE SCREEN.

Or a Single statement

LEAVE TO SCREEN 200.