Calling Screen Sequences as Modules (SAP Library

Calling Screen Sequences as Modules

If you want to encapsulate a screen sequence with all of its flow logic and application logic, you must ensure that all of the screens in the sequence are linked to a single ABAP program. The ABAP program contains all of the dialog modules called by the screens in the sequence.

It is not currently possible to assign screens to a single procedure (subroutine, function module, or method) - they instead belong to the main program of the procedure.

When you call a new main program in order to use a screen sequence (for example, using CALL TRANSACTION), a new SAP LUW begins. This may be an undesired effect, especially when you are trying to modularize a transaction that updates the database.

An alternative to this is to use an external procedure, whose main program is linked to a screen sequence, and which contains the corresponding dialog modules. Procedures run in the same SAP LUW and internal session as their calling program.

Using Function Modules

Function modules and their function groups are often used to define and call screen sequences that you want to run in the same SAP LUW as their calling program.

To encapsulate a screen sequence in a function module, you use the CALL SCREEN statement in the function module source code. The called screen and all of its subsequent screens belong to the function group to which the function module belongs. The dialog modules that you call from the screen flow logic are defined in the main program of the function module. The Function Builder assists you in defining dialog modules by automatically creating the appropriate include programs.

A function group like the one above contains only one function module and one screen sequence. However, you can also have several function modules with several independent screen sequences in the same function group.

Using Dialog Modules

Dialog modules were the predecessors of function modules. They are now obsolete, and you should no longer create new ones. However, for the sake of completeness, this section contains a brief description of their structure and function.

Dialog modules are objects that, like transaction codes, are linked to a screen sequence in an ABAP program by means of an initial screen. When you call a dialog module, the system calls the corresponding ABAP program and the initial screen of the dialog module. Dialog modules can also have an interface. Before you can do this, you must have declared the parameters as global data in the ABAP program. Dialog modules are created and administered in the ABAP Workbench using a tool (Transaction SE35) similar to the Function Builder. You can assign more than one dialog module to the same ABAP program.

You call dialog modules using the CALL DIALOG statement:

CALL DIALOG <dialog>
            [AND SKIP FIRST SCREEN]
            [EXPORTING f₁ FROM a₁.... f_n FROM a_n]
            [IMPORTING f₁ TO a₁.... f_n TO a_n]
            [USING itab].

CALL DIALOG has the same syntax as CALL TRANSACTION. You can also pass values to the global data of the called program using the interface.

Although a dialog module occupies a new internal session, it runs in the same SAP LUW as the calling program. However, since they open a new session, they are less efficient than function modules in performance terms. Nevertheless, they are the only means of switching internal session without starting a new SAP LUW. You can only run an entire transaction within the SAP LUW of a calling program by linking the initial screen of the transaction with a dialog module.

If you want to run screen sequences and dialog modules in the SAP LUW of the calling program and as a transaction in their own SAP LUW, you must ensure that all database update tasks can be executed without compromising data integrity. The following special conditions apply:

Dialog modules inherit locks set by the calling program.

If the screen sequence is called as a dialog module, the system assumes that a lock for a particular object already exists. When you start the screen sequence as a transaction, you must set your own locks. To find out at runtime if a program is running as a called program, use the system variable SY-CALLD.

Dialog modules inherit update keys from the calling program.

When the screen sequence is running as a dialog module, the system partly ignores COMMIT and ROLLBACK WORK statements.

In the called program, the statements COMMIT WORK and ROLLBACK WORK lead to database commits or database rollbacks. However, procedures registered with CALL FUNCTION IN UPDATE TASK and PERFORM ON [COMMIT|ROLLBACK] are not executed till the corresponding statements in the calling program.

Update function modules called using the IN UPDATE TASK addition are not started if the screen sequence is running as a dialog module.

You must ensure that any function modules called with IN UPDATE TASK can be delayed until the next COMMIT WORK in the calling program.

PERFORM ON COMMIT routines are not executed in the dialog module.

You must ensure that any subroutines called using ON COMMIT can be delayed until the next COMMIT WORK in the calling program. Remember that the global data of the dialog module is destroyed along with the internal session when control returns to the calling program. Consequently, subroutines called using PERFORM ON COMMIT must not use this global data.

If you want to run the screen sequence as a transaction, you must ensure that the input parameters of the interface contain reasonable default values.