Get Example source ABAP code based on a different SAP table
ID CALL-TRANSACTION • CALL TRANSACTION ABAP Statement
CALL TRANSACTION Short Reference
ABAP_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$].
What does it do? 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 is resumed 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 static specification by tools such as the extended program check or the where-used list.
Variable BEGIN_SECTION ID CALL-TRANSACTION-DYNAMIC If the data object ta is specified as a variable, it is specified only dynamically, and the content is not evaluated statically. END_SECTION ID CALL-TRANSACTION-DYNAMIC When the statement is executed, ta is not evaluated until runtime in both cases. If the transaction specified in ta is not found, a uncatchable exception is raised.
In the first variant, the display of the initial dynpro can be suppressed.
In the second variant, the transaction is controlled by a batch input table. In both variants, an authorization check can be performed for the called transaction. When the transaction is called, the ABAP program linked to the transaction code is loaded in a new ABAP_ISESS of the current call sequence. The session of the calling program and the current SAP LUW are retained. 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, then, after all programs other than class pools are loaded, the event LOAD-OF-PROGRAM is raised and the method linked to the transaction code is called. If the method is an instance method, an object of the corresponding class is generated implicitly and referenced by the runtime framework. The transaction is finished when the method is finished or when the program is exited using the statement LEAVE PROGRAM.
Latest notes:
CALL TRANSACTION does not end the current database LUW. A database commit or database rollback in the called program has the same effect 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, in particular, 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. The statement ROLLBACK WORK in the called program may also affect the interrupted SAP LUW under certain circumstances. To prevent this, an explicit database commit must be executed before the program is called. This problem does not occur during local updates.
The number of ABAP_ISESSNS in a call sequence is restricted to nine. If this is exceeded by CALL TRANSACTION, the program is terminated and the entire call sequence is deleted. ABAP_HINT_END
