Conditional Module Calls (SAP Library - ABAP Programming (BC-ABA))

Conditional Module Calls

Simple module calls are processed in the sequence in which they appear in the screen flow logic. However, the syntax of the screen language also allows you to make PAI module calls dependent on certain conditions. This is done by using the MODULE statement together with the FIELDstatement You can apply conditions to both single fields and groups of fields. Conditional module calls can help you to reduce the runtime of your program. Conditional module calls can also increase the performance, particularly with modules that communicate with database tables.

Conditions for Single Screen Fields

You can ensure that a PAI module is only called when a certain condition applies by using the following statement:

FIELD f MODULE mod ON INPUT|REQUEST|*-INPUT.

The additions have the following effects:

· ON INPUT

The module mod is only called only if the field is not blank. All fields are empty if they only contain spaces, except for the fields of the type STRG and SSTR. All fields are empty if they only contain spaces, except for the fields of the type STRG and SSTR.

· ON REQUEST

The module mod is only called if the user has entered something in the field. This includes cases when the user overwrites an existing value with the same value, or explicitly enters the initial value.

In general, the ON REQUESTcondition is triggered through any form of “manual input”. As well as user input, the following additional methods of entering values also call the module:

– The element attribute PARAMETER-ID (SPA/GPA parameters).

– The element attribute HOLD DATA

– CALL TRANSACTION...USING

– Automatic settings of particular global fields

· ON *-INPUT

The module mod is called if the user has entered a * in the first character of the field, and the field has the attribute *-entry in the Screen Painter. When the input field is passed to the program, the * is removed. * behaves like an initial field in the ON INPUTcondition.

The functions of the FIELD statement for controlling data transport also apply when you use MODULE.

Conditions for Multiple Screen Fields

To ensure that one or more PAI modules are only called when several screen fields meet a particular condition, you must combine the calls in the flow logic to form a processing chain. You define processing chains as follows:

CHAIN.
...
ENDCHAIN.

All flow logic statements between CHAIN and ENDCHAIN belong to a processing chain. The fields in the various FIELD statements are combined, and can be used in shared conditions.

CHAIN.
  FIELD: f₁, f₂,...
  MODULE mod1 ON CHAIN-INPUT|CHAIN-REQUEST.
  FIELD: g₁, g₂,...
  MODULE mod2 ON CHAIN-INPUT|CHAIN-REQUEST.
...
ENDCHAIN.

The additions ON and ON CHAIN-REQUEST work like the additions ON INPUT and ON REQUEST that you use for individual fields. The exception is that the module is called whenever at least one of the fields listed in a preceding FIELD statement within the procesing chain meets the condition. So mod1 is called when one of the fields f₁, f₂,... meets the condition. mod2 is called when one of the fields f₁, f₂,... or g₁, g₂,... meets the condition.

Within a processing chain, you can combine individual FIELD statements with a MODULE statement to set a condition for a single field within the chain:

The module mod1 is called when screen field f meets the specified condition for individual fields. mod2 is called when one of the fields f₁, f₂,... or f meets the condition. If you use the addition ON CHAIN-INPUT or ON CHAIN-REQUEST with FIELD f, the condition also applies to the entire chain and module mod1 and mod2 are both called.

In cases where you apply conditions to various combinations of screen fields, it is worth setting up a separate processing chain for each combination and calling different modules from within it.

The functions of the FIELD statement for controlling data transport also apply when you use processing chains. Within a processing chain, screen fields are not transported until the FIELD statement. Processing chains defined with CHAIN - ENDCHAIN also have another function for the FIELDS statements that they contain. This is described in the section on validity checks.

Calling Modules after Cursor Selection

You can specify that a module should only be called if the cursor is positioned on a particular screen element. To do this, use the statement

MODULE mod AT CURSOR-SELECTION.

The module mod is called whenever the function code of the user action is CS with function type S. If you use this statement, it is best to assign the function code CS to function key F2. This also assigns it to the mouse double-click.

The module is called in the sequence in which it occurs in the flow logic. It does not bypass the automatic input checks. Data is transported from screen fields in the order in which it is defined by the FIELD statements. The function code is empty, and neither sy-ucomm nor the OK_CODE field is affected. You can also combine this MODULE statement with the FIELD statement:

FIELD f MODULE mod AT CURSOR-SELECTION.

or, for more than one field:

CHAIN.
FIELD: f₁, f₂,...
MODULE mod AT CURSOR-SELECTION.
ENDCHAIN.

The module mod is only called if the cursor is positioned on an input/output field f or an input/output field f₁, f₂,... in the processing chain. You can only apply this statement to input/output fields.

The call hierarchy of the different combinations is as follows:

· If a MODULE... AT CURSOR-SELECTION statement is executed that was combined with FIELD, a statement without FIELD is not executed.

· If a statement using FIELD appears more than once for the same screen field f, only the first statement is executed.

· If a statement without FIELD occurs more than once, only the last statement is executed.

It is irrelevant whether the statements occur within a CHAIN ... ENDCHAIN block or not.

Example

Conditional module calls

PROGRAM demo_dynpro_on_condition.

DATA: ok_code TYPE sy-ucomm,
input1(20) TYPE c, input2(20) TYPE c, input3(20) TYPE c,
fld(20) TYPE c.

CALL SCREEN 100.

MODULE init_screen_100 OUTPUT.
SET PF-STATUS 'STATUS_100'.
ENDMODULE.

MODULE cancel INPUT.
LEAVE PROGRAM.
ENDMODULE.

MODULE cursor INPUT.
GET CURSOR FIELD fld.
MESSAGE i888(sabapdocu) WITH text-001 fld.
ENDMODULE.

MODULE module_1 INPUT.
MESSAGE i888(sabapdocu) WITH text-002.
ENDMODULE.

MODULE module_2 INPUT.
MESSAGE i888(sabapdocu) WITH text-003.
ENDMODULE.

MODULE module_* INPUT.
MESSAGE i888(sabapdocu) WITH text-004 input3.
ENDMODULE.

MODULE c1 INPUT.
MESSAGE i888(sabapdocu) WITH text-005 '1'.
ENDMODULE.

MODULE c2 INPUT.
MESSAGE i888(sabapdocu) WITH text-005 '2' text-006 '3'.
ENDMODULE.

The next screen (statically defined) for screen 100 is 100. It has the following layout:

This graphic is explained in the accompanying text

The screen fields input1, input2 and input3 are assigned to the input fields. The function code of the pushbutton is EXECUTE.

In the GUI status STATUS_100, the icon This graphic is explained in the accompanying text (F12) is active with function code CANCEL and function type E. The function key F2 is also active with function code CS and function type S. The F8 key is active with the function code EXECUTE and no special function type.

The screen flow logic is as follows:

PROCESS BEFORE OUTPUT.
MODULE init_screen_100.

PROCESS AFTER INPUT.
  MODULE cancel AT EXIT-COMMAND.
  CHAIN.
    FIELD: input1, input2.
    MODULE module_1 ON CHAIN-INPUT.
    FIELD  input3 MODULE module_* ON *-INPUT.
    MODULE module_2 ON CHAIN-REQUEST.
  ENDCHAIN.
  FIELD input1 MODULE c1 AT CURSOR-SELECTION.
  CHAIN.
    FIELD: input2, input3.
    MODULE c2 AT CURSOR-SELECTION.
  ENDCHAIN.
  MODULE cursor AT CURSOR-SELECTION.

The program uses information messages to show which modules are called following user interaction and which data is transported.

· Whenever one of the input fields 1 or 2 is not initial, the system calls the module module_1 for any user interaction.

· Whenever one of the three input fields is changed, the system calls the module module_2 for any user interaction.

· Whenever input field 3 contains a * entry, the system calls module module_*. for any user interaction.

· If the user chooses F2 or double-clicks a text field on the screen, the system calls the module cursor.

· If the user chooses F2 or double-clicks input field 1, the system calls the module c1.

· If the user chooses F2 or double-clicks input field 2 or 3, the system calls the module CURSOR. Module c2 is never executed, since the MODULE … AT CURSOR SELECTION statement occurs twice, and only the last is processed.