BDC 8

(18) PROCESSING BATCH INPUT SESSIONS:

When you create a batch input session, it remains in the batch input queue until it is explicitly started. Session processing can be started in two ways:

An on-line user can start the session using the batch input menu options. (To access the batch input options, choose System-->Services-->Batch Input.)

You can submit the background job RSBDCSUB to start a session in background processing. If several sessions have the same name, RSBDCSUB starts them all.

It's possible to coordinate the generation and execution of a session in the background processing system.

You can, for example, schedule both the batch input program and RSBDCSUB in the background. If you designate the batch input job as the predecessor for RSBDCSUB, then RSBDCSUB will be started automatically when the batch input job successfully completes.

Alternatively, you can schedule both the batch input program and RSBDCSUB as job steps in a single background job. In this case, however, RSBDCSUB is started even if the batch input program should terminate abnormally.

For detailed information about processing batch input sessions, see MANAGING BATCH INPUT SESSIONS(B) in the System Services guide. You'll find this guide in the Basis library, system administration section, on the SAP documentation CD-ROM.


(19) USING CALL TRANSACTION USING FOR BATCH INPUT:


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

Error recovery, restarting, and management of batch input processing are all more comfortable if you use "classical" batch input processing by way of batch input sessions. CALL TRANSACTION USING is therefore recommended only if batch input sessions do not run fast enough to meet your requirements.

For more information on choosing a batch input method, please see Selecting a Batch-Input Method(11) .


A program that uses CALL TRANSACTION USING to submit batch input should perform the following steps:

1. Prepare a BDCDATA structure for the transaction that you wish to run. The requirements for filling the BDCDATA structure are the same as for "classical" batch input using sessions. For more information, please see Using the Batch Input Data Structure(12).

2. With a CALL TRANSACTION USING statement, call the transaction and pass the BDCDATA structure to it as batch input. For example:

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

The Mode Parameter

The MODE parameter lets you specify whether the batch input processing should be displayed to you as it happens. You can choose between three modes:

A Display everything.
All screens and the data that goes in them appear when you run your program. This is the default setting for MODE in CALL TRANSACTION USING.

N Display nothing.
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. (Database updates however, may have taken place or may have not have taken place, depending on the value of the UPDATE parameter.)

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

The UPDATE parameter lets you 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 batch input 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 batch input 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's 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. (Refer to the keyword documentation of 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 . The internal table must have the structure BDCMSGCOLL.

Example

You can have system messages issued by transaction SE38 (bottom of example) collected in table MESSTAB with the following coding:
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.

DATA REPORT(8).

BDCDATA-PROGRAM = 'SAPMS38M'.
BDCDATA-DYNPRO = '0100'.
BDCDATA-DYNBEGIN = 'X'.
APPEND BDCDATA.
CLEAR BDCDATA.
BDCDATA-FNAM = 'RS38M-PROGRAMM'.
BDCDATA-FVAL = REPORT.
APPEND BDCDATA.
...
CALL TRANSACTION 'SE38' USING BDCDATA MODE 'N'
MESSAGES INTO MESSTAB.

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 batch input.

If you use the MESSAGES INTO 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.