BDC 5

(11) SELECTING A BATCH-INPUT METHOD:

When you generate batch input in ABAP/4, you have three options for submitting the data to batch input processing. Only the first two methods can be recommended without reservation. The third method, by way of CALL DIALOG, is outmoded. CALL DIALOG Is less comfortable than the other methods. You should use it only if you must.


Create a session on the batch input queue.

Summary: Standard method. Offers management of sessions, support for playing back and correcting sessions that contain errors, and detailed logging.

Your program prepares the data and stores it in a batch input session. A session is a collection of transaction data for one or more transactions. Batch input sessions are maintained by the system in the batch input queue. You can process batch input sessions in the background processing system.

Your program must open a session in the queue before transferring data to it, and must close it again afterwards. All of these operations are performed by making function module calls from the ABAP/4 program.

The most important aspects of the session interface are:

Asynchronous processing
Transfers data for multiple transactions
Synchronous database update

During processing, no transaction is started until the previous transaction has been written to the database.

A batch input processing log is generated for each session
Sessions cannot be generated in parallel

The batch input program must not open a session until it has closed the preceding session.

Use the CALL TRANSACTION USING statement

Summary:

Offers faster processing of data than batch input sessions. Recommended if you're having problems getting data entered into your SAP System quickly enough. The playback, interactive correction, and logging facilities offered for batch input sessions are not available for CALL TRANSACTION USING.
Your program prepares the data and calls the desired transaction for immediate processing.

The most important aspects of the CALL TRANSACTION USING interface are:

Synchronous processing
Transfers data for a single transaction
Synchronous and asynchronous database updating both possible
The program specifies which kind of updating is desired.
Separate LUW for the transaction
The system performs a database commit immediately before and after the CALL TRANSACTION USING statement.
No batch input processing log is generated

Use the CALL DIALOG statement

Summary:

Not recommended if you can enter data by way of sessions or CALL TRANSACTION USING.
Your program prepares data for a sequence of dialog screens, and calls a dialog module for immediate processing.

The most important aspects of the CALL DIALOG interface are:

Synchronous processing
Transfers data for a sequence of dialog screens
No separate database update for the dialog
A database update occurs only when the calling program executes a commit operation.

Shares LUW with calling program
No batch input processing log is generated

(12) USING THE BATCH INPUT DATA STRUCTURE:

The batch input structure stores the data that is to be entered into SAP System and the actions that are necessary to process the data. You can think of the structure as storing the script that the SAP System is to follow in processing batch input data.

The batch input structure is used by all of the batch input methods. You can use the same structure for all types of batch input, regardless of whether you are creating a session in the batch input queue or using CALL TRANSACTION USING or CALL DIALOG.

The diagram below shows how to declare the structure in your ABAP/4 program and the fields contained in the structure.



BDCDATA Structure

Information structure: A BDCDATA structure can contain the batch input data for only a single run of a transaction. The typical processing loop in a program is therefore as follows:

Create a BDCDATA structure
Write the structure out to a session or process it with CALL TRANSACTION USING; and then

Create a BDCDATA structure for the next transaction that is to be processed.

Within a BDCDATA structure, data is organized by the screens in a transaction. Each screen that is processed in the course of a transaction must be identified with a BDCDATA record. This record uses the Program, Dynpro, and Dynbegin fields of the structure:

The screen identifier record is followed by a separate BDCDATA record for each value that is to be entered into a field. These records use the FNAM and FVAL fields of the BDCDATA structure. Values to be entered in a field can be any of the following:

data that is entered into screen fields
function codes that are entered into the command field. Such function codes execute functions in a transaction, such as Save.
cursor-positioning commands.

The transaction to which a BDCDATA structure refers is identified separately. If your program writes data to a batch input session, then the transaction is specified in the call to the BDC_INSERT function module. This function module writes a BDCDATA structure out to the session. If your program processes data with CALL TRANSACTION USING, then the transaction is specified directly in this statement.

The following table shows what the contents of a BDCDATA structure might look like. This BDCDATA structure would add a line to a report in transaction SE38, the ABAP/4 Editor:

BDCDATA Structure for Adding a Line to a Report (Transaction SE38)

PROGRAM DYNPRO DYNBEGIN FNAM FVAL
----------------- ------------- ----------------- -------------------------- ----------
SAPMS38M 0100 X
RS38M-PROGRAMM
RS38M-FUNC_EDIT X
BDC_OKCODE =CHAP (Change function code)
SAPMSEDT 2310 X
RSTXP-TDLINECOM(1) B-
SAPMSEDT 2310 X
BDC_CURSOR RSTXP- TDLINECOM(1)
RSTXP-TDLINE(1) BDC Test Text
BDC_OKCODE /11 (Save function key)
SAPMSEDT 2310 X
BDC_OKCODE /3 (Back function key)
SAPMS38M 0100 X
BDC_OKCODE /15 (Quit function key)

Fields: The fields in the BDCDATA structure are as follows:

PROGRAM

Name of the program. Length (8). The PROGRAM field is not case-sensitive. Set this field only in the first record for the screen.

DYNPRO

Number of the screen. Length (4). Set this field only in the first record for the screen.

DYNBEGIN

Indicates the first record for the screen. Length (1). Set this field to X only in the first record for the screen. (Reset to ' ' (blank) for all other records.)

FNAM

Name of a field in the screen. Length (35). The FNAM field is not case-sensitive.

FVAL

Value for the field named in FNAM. Length (132). The FVAL field is case-sensitive. Values assigned to this field are always padded on the right if they are less than 132 characters. Values must be in character format.

Finding function codes and program and field names: Please see Analyzing SAP Transactions(4) for more information.

Data formatting requirements: Please see Data Conversions(6) for more information.