ABAP Keyword Documentation →  ABAP − Reference →  Calling and leaving program units →  Calling Programs →  Calling Transactions 

CALL TRANSACTION

Quick Reference

Other versions: 7.31 | 7.40 | 7.54

Syntax Forms

Simple transaction call

1. CALL TRANSACTION ta WITH|WITHOUT AUTHORITY-CHECK [AND SKIP FIRST SCREEN].

Transaction call using batch input table

2. CALL TRANSACTION ta WITH|WITHOUT AUTHORITY-CHECK
                      USING bdc_tab { {[MODE mode] [UPDATE upd]}
                                    |  [OPTIONS FROM opt] }
                                       [MESSAGES INTO itab].

Effect

The statement CALL TRANSACTION calls the transaction whose transaction code is contained in the data object ta. The calling program and its data are preserved. After the transaction call, the program execution of the calling program resumes after the statement CALL TRANSACTION. The data object ta must be character-like, flat and contain the transaction code in uppercase letters. The following can be specified for ta:

• Literal or constant
  

If the data object ta is specified as a text field literal or as a constant, it is evaluated as a statically specified object by tools such as the extended program check or the where-used list.

• Variable
  

If the data object ta is specified as a variable, it is specified only dynamically and the content is not evaluated statically.

When the statement is executed, ta is not evaluated until runtime (in both cases). If the transaction specified in ta cannot be found, a non-handleable exception is raised.

• In the first variant, the display of the initial screen can be suppressed.
• In the second variant, the transaction is executed using a batch input table.
  

In both variants, an authorization check can be performed on the called transaction.

When the transaction is called, the ABAP program associated with the transaction code is loaded in a new internal session of the current call sequence. The session of the calling program and the current SAP LUW are preserved. The called program runs in its own SAP LUW.

• If the called transaction is a dialog transaction, the event LOAD-OF-PROGRAM is raised after the ABAP program is loaded and the dynpro defined as the initial dynpro of the transaction is called. The initial dynpro is the first dynpro of a dynpro sequence. The transaction is finished when the dynpro sequence is ended by encountering the next dynpro with dynpro number 0 or when the program is exited using the statement LEAVE PROGRAM.
• If the called transaction is an OO transaction, the event LOAD-OF-PROGRAM is raised and the method associated with the transaction code is called when any program is loaded (except class pools). If the method is an instance method, an object of the associated class is generated implicitly and referenced by the runtime environment. The transaction is finished when the method is finished or when the program is exited using the statement LEAVE PROGRAM.
  

Notes

• CALL TRANSACTION does not end the current database LUW. A database commit or database rollback in the called program works in exactly the same way as in the current program.
• The statement CALL TRANSACTION opens a new SAP LUW but it does not open a new database LUW. This means that a database rollback in this SAP LUW can roll back all registration entries made by the statements CALL FUNCTION IN UPDATE TASK or CALL FUNCTION IN BACKGROUND TASK in the tables VB... or ARFCSSTATE and ARFCSDATA. Under certain circumstances, the statement ROLLBACK WORK in the called program can also affect the interrupted SAP LUW. To prevent this, an explicit database commit must be executed before the program is called. This problem does not occur in local updates.
• The number of internal sessions in a call sequence is restricted to nine. If this is exceeded by CALL TRANSACTION, the program terminates and the entire call sequence is deleted.
  

Security Note

If the name of a program unit is specified dynamically when it is called, and this name is passed to a program from outside, the result is a serious security risk. Any names passed to a program from outside must be checked thoroughly before being used in calls. The system class CL_ABAP_DYN_PRG, for example, can be used to do this. See Dynamic Calls.

Example

Calls the transaction DEMO_TRANSACTION in the executable example program DEMO_CALL_TRANSACTION_SPA_GPA.

TRY. 
    CALL TRANSACTION 'DEMO_TRANSACTION' WITH AUTHORITY-CHECK. 
  CATCH cx_sy_authorization_error. 
    ... 
ENDTRY. 

Executable Examples

Transaction Call - Examples

Exceptions

Handleable Exceptions

CX_SY_AUTHORIZATION_ERROR

• Cause: No authorization for this transaction.
  Runtime error: CALL_TRANSACTION_NO_AUTH
  

Non-Handleable Exceptions

• Cause: Transaction not found.
  Runtime error: CALL_TRANSACTION_NOT_FOUND
• Cause: Transaction is an area menu and cannot be called.
  Runtime error: CALL_TRANSACTION_IS_MENU
• Cause: Transaction is locked.
  Runtime error: CALL_TRANSACTION_LOCKED
• Cause: Error in internal memory management.
  Runtime error: CALL_TRANSACTION_MSG_NO_PAGING
• Cause: Recursive call of a transaction using the addition USING.
  Runtime error: CALL_TRANSACTION_USING_NESTED

Continue

CALL TRANSACTION - standard

CALL TRANSACTION - USING

Transaction Call - Examples