Skip to content

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

CALL TRANSACTION

Short Reference

Other versions: 7.31 | 7.40 | 7.54

Syntax


CALL TRANSACTION ta { [AND SKIP FIRST SCREEN] 
     
              | [USING bdc_tab [bdc_options]] }.

Extras

1. ... AND SKIP FIRST SCREEN

2. ... USING bdc_tab [bdc_options]

Effect

The statement CALL TRANSACTION calls the transaction whose transaction code is contained in data object ta. The data object ta must be character-like and contain the transaction code in uppercase letters. If the transaction specified in ta cannot be found, a non-handleable exception is raised. The additions suppress the display of the initial screen and allow the transaction to be executed using a batch input table.

CALL TRANSACTION retains the calling program and its data, and, after exiting the called transaction, processing is resumed in the calling program after the call.

When the transaction is called, the ABAP program associated with the transaction code is loaded in a new internal session. 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 triggered after the ABAP programs 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 LEAVE PROGRAM statement.
  • If the called transaction is an OO transaction, then when loading all programs (except class pools), the event LOAD-OF-PROGRAM is triggered and the method associated with the transaction code is called. 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 LEAVE PROGRAM statement.

After the end of the transaction call, program execution of the calling program resumes after the CALL TRANSACTION statement.

The statement CALL TRANSACTION checks whether the current user is authorized to run the called transaction by using the authorization object S_TCODE. This is only done if the current transaction code and the called transaction code are entered as a pair in the columns TCODE and CALLED of the database table TCDCOUPLES and if the database field OKFLAG of this row has the value "X". If this is not the case, no check takes place.


Notes

  • If no authorization check is performed for CALL TRANSACTION and no check is performed in the called program, a check can be run in the called program by calling the function module AUTHORITY_CHECK_TCODE. This function module checks the authorization object S_TCODE, if the database field OKFLAG in TCDCOUPLES has the value "X" or is empty. If the field has the value "N", the function module does not perform a check. If the authorization is to be checked regardless of the table entries, the statement AUTHORITY-CHECK needs to be used.
  • The entries in the database table TCDCOUPLES can be defined in transaction SE97. The entry in the column MAINTFLAG controls the program behavior if the authorization is missing.
  • The standard behavior described here for the authorization check can be overridden by the hidden profile parameter auth/check/calltransaction. This profile parameter is not provided as standard but it can be created manually. The following table shows the value combinations - value in OKFLAG in TCDCOUPLES (first column) and value of existing profile parameter (first row) - for which an authorization check is performed.

     |  0  1  2  3
------------------
"X"  |  -  x  x  x
"N"  |  -  x  -  -
" "  |  -  x  -  x
The last row also describes the behavior for when TCDCOUPLES does not contain a corresponding entry. Value 2 for the profile parameter is the standard behavior. If the profile parameter is available, it influences the AUTHORITY_CHECK_TCODE function module.

Addition 1

... AND SKIP FIRST SCREEN

Effect

This addition suppresses the display of a screen of the initial dynpro of a called dialog transaction. The addition AND SKIP FIRST SCREEN suppresses the first screen only under these prerequisites:

  • On the initial dynpro, the dynpro number must not be specified as a static next dynpro in Screen Painter.
  • All mandatory input fields of the initial dynpro must be filled completely and with the correct values by the SPA/GPA parameters.

If these prerequisites are met, the screen of the dynpro is displayed that is specified in Screen Painter as the next dynpro of the initial dynpro.


Example

If the static next dynpro of the initial dynpro of the called dialog transaction FLIGHT_TA is not the initial dynpro itself, then its screen is suppressed, because its input fields are filled using the SPA/GPA parameters CAR and CON.

DATA: carrid TYPE spfli-carrid,
      connid TYPE spfli-connid.

...

SET PARAMETER ID: 'CAR' FIELD carrid,
                  'CON' FIELD connid.

CALL TRANSACTION 'FLIGHT_TA' AND SKIP FIRST SCREEN.

Addition 2

... USING bdc_tab [bdc_options]

Effect

This add-on enables the transaction to be executed using a batch input table. This requires an internal table bdc_tab of row type BDCDATA to be passed from ABAP Dictionary to a dialog transaction. The additions bdc_options control the processing. When a transaction with addition USING is called, the system field sy-binpt is set to value "X" in the called program; while this transaction is running, no other transaction can be called with this addition.

A batch input table bdc_tab is the program's internal representation of a subset of a batch input session and must be filled accordingly. The structure BDCDATA has the components shown in the table below.

Component Meaning
PROGRAM Name of the program of the called transaction
DYNPRO Number of the dynpro to be processed
DYNBEGIN Flag for the beginning of a new dynpro (possible values are "X" and " ")
FNAM Name of a dynpro field to be filled or batch input control statement, for example to position the cursor
FVAL Value to be passed to the dynpro field or to the control statement

Using the content of the internal table bdc_tab, any number of screens of the called transaction can be provided with input and user actions.

System Fields

sy-subrc Meaning
0 The processing of the called transaction was successful.
< 1000 Error in the called transaction. If a message was sent within the transaction, it can be received using the addition MESSAGES.
1001 Processing error.


Note

Calling a transaction using a batch input table is not the same as executing batch input sessions in batch input. There is no exact dividing line between the two, however, since batch input-based frameworks, such as CATT and batch input managment, sometimes also execute the statement CALL TRANSACTION USING internally. In this way, they can use certain bdc_options not available in genuine batch input.

Exceptions


Non-Catchable 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 with addition USING.
    Runtime Error: CALL_TRANSACTION_USING_NESTED

Continue

CALL TRANSACTION - bdc_options

CALL TRANSACTION - Batch Input Table

Transaction Call - Examples