If you call a transaction from within a program by using CALL TRANSACTION '<TCODE>', the system can execute the transaction without user dialog (that is, in the background). For this purpose, you need to create an internal table in the batch-input format (see the online documentation for CALL TRANSACTION) using the USING addition. This table contains the values for the dynpros and the function code to navigate between the dynpros. For the call with “N” (do not display), you must specify the MODE parameter.

 

Other values for the MODE parameter are "A" (display = default), "E" (only display if error), and "P" (display debugger at break point).

 

You can overwrite the default update mode for the transaction by using the call parameter UPDATE, which is usually asynchronous. In this context, the default update mode is the mode that is coded in the called transaction. Therefore, by calling a transaction that has a coded "A" mode, you can overrule that by calling CALL TRANSACTION <> MODE "S".

 

If UPDATE = ’S’ , the system continues processing the calling program only when the update process triggered by the called transaction is completed. The system field sy-subrc returns the update status. Use UPDATE = ‘S’ if processing of the transaction that is called later is dependent on the successful execution of the present transaction.

 

For more information, refer to the keyword documentation in ABAP Editor for the term CALL TRANSACTION.

 

 

SAP LUWs in Asynchronous Function Calls

A function module that you call asynchronously creates its own SAP LUW and runs in a separate session.

 

The system briefly interrupts the processing of the calling program. The system continues processing after the function module is triggered; therefore, registered CALL FUNCTION in the UPDATE TASK and subroutines that have been called with the ON COMMIT addition are retained.

 

Note: The asynchronous call of a function module triggers an implicit database commit. Inline changes processed in the calling program up to that point will be committed in the database.

 

 

Implementation of Different Program Calls

Any program called by SUBMIT <program> AND RETURN or CALL TRANSACTION '<TCODE>' has its own SAP LUW. You can use these programs to perform nested (complex) LUW processing.

 

Function modules and methods are executed within the LUW of the calling program. Therefore, they are suitable for building up a complex (nested) LUW (for example, report calls various BAPIs = function modules within one LUW, one COMMIT WORK works for calling report and all BAPIs).

 

Use asynchronously called function modules to perform tasks that can be processed in parallel. An asynchronously called function module runs in a new main session, and therefore has its own SAP memory. Use the function module interface to perform data transfer.

 

For example, in a program, you want to call up a display transaction that is displayed in a separate window (amodal). You need to use the statement CALL TRANSACTION '<TCODE>'. Start a new mode by using CF <> STARTING new task and transfer the data by using the function module interface. Then, call the transaction from within the function module. The data transfer from the function module to the called transaction can be done by using SAP memory, ABAP memory, or using the BDC itab within the CALL TRANSACTION statement.

 

 

SAP Lock Mechanism in Complex LUW Processing

If a type “E” lock is set in the program for a data record, further locks of type “E” set in the same program can be included in a function module that was called synchronously or in a called method. This process is called accumulation of a lock.

 

However, you cannot set additional locks to the existing ones from within a program that you have called using SUBMIT <program> AND RETURN or CALL TRANSACTION '<TCODE>' . Any lock attempts from such calls will be rejected with the exception FOREIGN_LOCK as this additional lock request comes from a new LUW.