Show TOC

Calling Modules UnconditionallyLocate this document in the navigation structure


In the PAI event, the PAI modules are called in the sequence in which they occur in the screen flow logic, after the automatic field checks . This means that the input on the screen must satisfy the automatic checks before the first module can be called. In particular, all required fields must be filled, and any checks against value lists or check tables defined for the field in the ABAP Dictionary must be successful.

In some cases, the user may have to enter a considerable amount of data merely in order to be able to leave the screen. To prevent this, special function codes can be combined with a special module call. The corresponding module is called independently of the user inputs.

Type E Function Codes

The function codes for screens and the GUI status can be given type E. For this purpose, set the Function type attribute in the Screen Painter to E for the screen elements of the screen concerned. For GUI status functions, choose Start of the navigation path Goto Next navigation step Object Lists Next navigation step Function list End of the navigation path in the Menu Painter, select the required function codes, and enter E for the FunctionType .

If the user chooses a screen element or a user interface element with a function code of type E, the system bypasses the automatic field checks and calls a special module in the screen flow logic. If the special module call does not exist, the system resumes normal PAI processing, that is, the automatic field checks take place after all.

As a rule, type E functions should allow the user to leave the screen. Consequently, the function codes for the icons F3, Shift+F3, and F12 in the toolbar for the GUI status usually have type E.

Calling a Module for Type E Function Codes

When the user chooses a function with type E, the screen flow logic jumps directly to the following statement:


Regardless of where it occurs in the screen flow logic, this statement is executed immediately, and before the automatic checks for the field contents on the screen. Before the module mod is executed, only the contents of the OK code field are transported to the ABAP field with the same name. However, no other screen fields are transported. If you have more than one MODULE statement with the AT EXIT- COMMAND addition, only the first is executed. If there are no MODULE statements with the AT EXIT - COMMAND statement, normal PAI processing resumes.

If the user chooses a function whose function code does not have type E, the MODULE <mod> AT EXIT-COMMAND statement is not executed.

Modules for Type E Function Codes

The MODULE... AT EXIT-COMMAND statement is normally used to leave the current screen without the automatic input checks taking place. You should therefore program it to contain an appropriate variant of the LEAVE statement, to leave the current screen, the call chain, or the entire program, as appropriate. If the module does not leave the screen, normal PAI processing resumes after it has finished -that is, the automatic field checks take place, and the normal PAI modules are called, with data being transported from the screen back to the program according to the sequence defined in the FIELDS statements.

Unconditional module call



PROGRAM demo_dynpro_at_exit_command.
DATA: ok_code TYPE sy-ucomm,
save_ok LIKE ok_code,
input1(20) TYPE c, input2(20) TYPE c.
MODULE init_screen_0100 OUTPUT.
MESSAGE i888(sabapdocu) WITH text-001 ok_code input1 input2.
IF ok_code = 'CANCEL'.
CLEAR ok_code.
MESSAGE i888(sabapdocu) WITH text-002 ok_code input1 input2.
IF ok_code = 'BACK' OR ok_code = 'EXIT'.
CLEAR: ok_code, input1, input2.
MODULE execute1 INPUT.
MESSAGE i888(sabapdocu) WITH text-003 ok_code input1 input2.
save_ok = ok_code.
CLEAR ok_code.
MODULE execute2 INPUT.
MESSAGE i888(sabapdocu) WITH text-004 ok_code input1 input2.
IF save_ok = 'EXECUTE'.
MESSAGE s888(sabapdocu) WITH text-005.


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

The screen fields input1 to input2 are assigned to the input fields. The input fields are marked in their attributes as required fields. The function codes of the pushbuttons are EXECUTE and CANCEL. CANCEL has function type E.

In the GUI status STATUS_100, the F3 and F12 icons are activated with the function codes BACK and CANCEL respectively. Both have function type E. Function key F8 is still assigned to the EXECUTE function code. EXECUTE does not have function type E.

The screen flow logic is as follows:


MODULE init_screen_0100.
MODULE execute1.
MODULE execute2.



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

  • If the user chooses Execute without filling out the obligatory fields, the automatic field check displays an error message.

  • If the user fills out the obligatory fields and then chooses Execute , all of the screen fields are transported to the program, and the modules execute1 and execute2 are called.

  • If the user chooses Cancel , the OK_CODE field is transported and the cancel module is called, regardless of whether the user filled out the obligatory fields. The program is exited at this point.

  • If the user chooses Back , the OK_CODE field is transported and the cancel module is called, regardless of whether the user filled out the obligatory fields. However, the program does not terminate, since the function code is BACK. Instead, the automatic field checks are performed. If the obligatory fields are filled, the modules execute1 and execute2 are called.

The back module is never called. Two module calls with AT EXIT-COMMAND do not make any sense in the screen flow logic. In the above example, the function code BACK should also be processed in the cancel module. Then the position of the module statement with AT EXIT-COMMAND is irrelevant.