Entering content frame

Procedure documentation Using CALL TRANSACTION USING for Data Transfer Locate the document in its SAP Library structure

Processing batch input data with CALL TRANSACTION USING is the faster of the two recommended data transfer methods. In this method, legacy data is processed inline in your data transfer program.

For more information, see choosing a data transfer method.

Syntax:

CALL TRANSACTION <tcode>

 USING <bdc_tab>

 MODE  <mode>

 UPDATE  <update>

 

<tcode> : Transaction code

<bdc_tab> : Internal table of structure BDCDATA.

<mode> : Display mode:

A

Display all

E

Display errors only

N

No display

 

<update> : Update mode:

S

Synchronous

A

Asynchronous

L

Local update

 

A program that uses CALL TRANSACTION USING to process legacy data should execute the following steps:

  1. Prepare a BDCDATA structure for the transaction that you wish to run.
  1. With a CALL TRANSACTION USING statement, call the transaction and prepare the BDCDATA structure. For example:

CALL TRANSACTION 'TFCA' USING BDCDATA
MODE 'A'
UPDATE 'S'.
MESSAGES INTO MESSTAB.

IF SY-SUBRC <> 0.

 <Error_handling>.

ENDIF.

The MODE Parameter

You can use the MODE parameter to specify whether data transfer processing should be displayed as it happens. You can choose between three modes:

A Display all. All screens and the data that goes in them appear when you run your program.

N No display. All screens are processed invisibly, regardless of whether there are errors or not. Control returns to your program as soon as transaction processing is finished.

E Display errors only. The transaction goes into display mode as soon as an error in one of the screens is detected. You can then correct the error.

The display modes are the same as those that are available for processing batch input sessions.

The UPDATE Parameter

You use the UPDATE parameter to specify how updates produced by a transaction should be processed. You can select between these modes:

A Asynchronous updating. In this mode, the called transaction does not wait for any updates it produces to be completed. It simply passes the updates to the SAP update service. Asynchronous processing therefore usually results in faster execution of your data transfer program.

Asynchronous processing is NOT recommended for processing any larger amount of data. This is because the called transaction receives no completion message from the update module in asynchronous updating. The calling data transfer program, in turn, cannot determine whether a called transaction ended with a successful update of the database or not.

If you use asynchronous updating, then you will need to use the update management facility (Transaction SM12) to check whether updates have been terminated abnormally during session processing. Error analysis and recovery is less convenient than with synchronous updating.

S Synchronous updating. In this mode, the called transaction waits for any updates that it produces to be completed. Execution is slower than with asynchronous updating because called transactions wait for updating to be completed. However, the called transaction is able to return any update error message that occurs to your program. It is much easier for you to analyze and recover from errors.

L Local updating. If you update data locally, the update of the database will not be processed in a separate process, but in the process of the calling program. (See the ABAP keyword documentation on SET UPDATE TASK LOCAL for more information.)

The MESSAGES Parameter

The MESSAGES specification indicates that all system messages issued during a CALL TRANSACTION USING are written into the internal table <MESSTAB> . The internal table must have the structure BDCMSGCOLL .

Example

You can record the messages issued by Transaction TFCA in table MESSTAB with the following coding:

(This example uses a flight connection that does not exist to trigger an error in the transaction.)

DATA: BEGIN OF BDCDATA OCCURS 100.
INCLUDE STRUCTURE BDCDATA.
DATA: END OF BDCDATA.
DATA: BEGIN OF MESSTAB OCCURS 10.
INCLUDE STRUCTURE BDCMSGCOLL.
DATA: END OF MESSTAB.
BDCDATA-PROGRAM = 'SAPMTFCA'.
BDCDATA-DYNPRO = '0100'.
BDCDATA-DYNBEGIN = 'X'.
APPEND BDCDATA.
CLEAR BDCDATA.
BDCDATA-FNAM = 'SFLIGHT-CARRID'.
BDCDATA-FVAL = 'XX'.
APPEND BDCDATA.
BDCDATA-FNAM = 'SFLIGHT-CONNID'.
BDCDATA-FVAL = '0400'.
APPEND BDCDATA.
CALL TRANSACTION 'TFCA' USING BDCDATA MODE 'N'
MESSAGES INTO MESSTAB.
LOOP AT MESSTAB.
WRITE: / MESSTAB-TCODE,
MESSTAB-DYNAME,
MESSTAB-DYNUMB,
MESSTAB-MSGTYP,
MESSTAB-MSGSPRA,
MESSTAB-MSGID,
MESSTAB-MSGNR.
ENDLOOP.
 The following figures show the return codes from CALL TRANSACTION USING and the system fields that contain message information from the called transaction. As the return code chart shows, return codes above 1000 are reserved for data transfer. If you use the MESSAGES INTO <table> option, then you do not need to query the system fields shown below; their contents are automatically written into the message table. You can loop over the message table to write out any messages that were entered into it.

Return codes:

Value

Explanation

0

Successful

<=1000

Error in dialog program

> 1000

Batch input error

 

System fields:

Name:

Explanation:

SY-MSGID

Message-ID

SY-MSGTY

Message type (E,I,W,S,A,X)

SY-MSGNO

Message number

SY-MSGV1

Message variable 1

SY-MSGV2

Message variable 2

SY-MSGV3

Message variable 3

SY-MSGV4

Message variable 4

 

Error Analysis and Restart Capability

Unlike batch input methods using sessions, CALL TRANSACTION USING processing does not provide any special handling for incorrect transactions. There is no restart capability for transactions that contain errors or produce update failures.

You can handle incorrect transactions by using update mode S (synchronous updating) and checking the return code from CALL TRANSACTION USING. If the return code is anything other than 0, then you should do the following:

 

 

 Leaving content frame