When assigning values to step loop fields,
you must specify the number of the loop line in parentheses after the field name (for example,
BDCDATA-FNAM = 'FELDX(5)' addresses the step loop field FELDX from the fifth line of the step loop).
The same applies to table control fields.
When generating and running batch input sessions that contain screens with variable step loops, you must always use the standard screen size.
In batch input, fields in subscreens are specified under the name of the calling screen. If a screen contains several subscreens, the field names in the subscreens must be unique.
Example: If the screen SAPTEST1 0100 calls the subscreen SAPTEST2 0200, the field SFLIGHT-CARRID of the subscreen SAPTEST2 0200 must get its value in batch input. For the batch input program, the field belongs to the calling screen, i.e. to SAPTEST1 0100.
As of Release 3.0, the technical information for a field also includes the name of the calling screen in the batch input field description, if the field concerned is a subscreen field.
You set function codes by assigning the desired function code value to the batch input field BDC_OKCODE (BDCDATA-FNAM = 'BDC_OKCODE'. BDCDATA-FVAL = 'UPDA'.).
In batch input, you set radio buttons and checkboxes by assigning 'X' to the field. The radio buttons in a group that are not supposed to be set do not have to contain values. If you inadvertently set several radio buttons in a group, the system only sets the last one when generating the session.
You treat pushbuttons like function codes. This means assigning the appropriate function code for the pushbutton to the field 'BDC_OKCODE'. Exception: If on a screen, the cursor is on a different pushbutton, the function code for this pushbutton applies. Here, the entered function code is overwritten (for example, confirmation dialog boxes). In such cases, the cursor must be positioned (see below).
You place the cursor on a field by assigning the name of the relevant field to the batch input field BDC_CURSOR.
Example: Suppose you want to position the cursor in the confirmation dialog box on the "No" function. In the function module POPUP_TO_CONFIRM_STEP (function group SPO1), screen SAPLSPO1 0100, the name of the pushbutton is SPOP-OPTION2; the field BDC_CURSOR must therefore contain 'SPOP-OPTION2' (BDCDATA-FNAM = 'BDC_CURSOR'. BDCDATA-FVAL = 'SPOP-OPTION2'.).
When you change a transaction, the batch input programs must be also be modified as follows:
In online processing, the authorizations of the user starting the session are checked. In background
processing, the system checks the authorizations of the user specified in the session generation program.
The user whose authorizations are checked in background processing is displayed in the session overview in the column "Authorization".
It may be that a particular user's session can be processed online but not in the background and vice versa. If an authorization check fails in background processing, you get the
error message 390(00) which reads "Processing session ** in background (SUBMIT error, see SYSLOG)".
If the behavior of a transaction in the background differs from its behavior online (read SY-BATCH), batch input sessions that contain this transaction may lead to errors in background processing; online, no errors occur.
Batch input sessions containing transactions that include list processing (this means all
report transactions) can only be processed online.
When processing these sessions in the background, batch input terminates with the error message 344(00) which reads "Batch input data for
screen SAPLSPRI 0100 does not exist" and the session then has the status "Incorrect".
In completely inactive screens, the cursor is always positioned on a field in online processing. In
the background, there is no screen output. As a result, the cursor is not positioned and problems can occur when processing the screen.
When processing a session with inactive screens in the background, batch input terminates with the error
message 344(00) which reads "Batch input data for screen XXXXXXXX nnnn does not exist" and the session then has the status "Incorrect".
You can only leave a warning dialog (message type "W") by pressing ENTER. For batch input, this means that screens with warning dialogs must each be included twice in the screen sequence.
When generating a batch input session, the system uses the date and decimal display format relevant for the user currently logged on.
When processing a session online, the system uses the display format relevant for the user currently logged on. When processing a session in the background, it uses the display format of the user for whom the authorization check is performed.
This means that if the user generating a session has a different display format from the user processing the session (online!), errors can occur. If the user generating a session has a different display format from the user for whom the authorization check is performed (in the background!), errors can occur when processing the session.
If you choose "Back", "Exit" or "Cancel" when processing a batch input session online, the current transaction terminates and the processing resumes with the next transaction in the session. This is because the batch input processor interprets "Back", "Exit" and "Cancel" as valid actions for the transaction being processed. At the end, the session is flagged as "Processed".
To exit a transaction in batch input, you should use the batch input commands /BDEL (delete transaction), /N (next transaction) and /BEND (cancel (batch input)). When a batch input session has been cancelled with /BEND, the status of the session is set to "Incorrect".
SET/GET parameters are not supported in batch input. With the multiplicity of transactions in batch input, it is not acceptable for one transaction to be able to determine the environment of the next transaction.
If you select the option "Extended log" when processing a batch input session in the background, the I, S and W messages of the transactions are written to the log. If A and E messages are output, batch input terminates.
The behavior of the individual message types is as follows:
In batch input (but not with CALL TRANSACTION USING), updates are generally synchronous, i.e. batch input waits for a reply from the update program.
If problems occur when updating, this is logged with the
error message "Update error". The long
text of this message contains the return code value of the update program. The most frequently occurring return code values are:
2 ,, Unable to insert update header
3 ,, Error when reading update header
4 ,, Update work process crash
5 ,, Update commit failed
6 ,, Error when reading VB MOD
7 ,, Error when updating VB MOD
8 ,, No main memory for update program
9 ,, Error message in update mode resulting from application
10 ,, Unable to load screen due to lack of memory space
11 ,, Incorrect update mode
12 ,, Update request locked in status RUN
13 ,, Update request locked in Status DELETE
14 ,, Incorrect update parameter
15 ,, No update parameters exist
16 ,, DEADLOCK during update
17 ,, No update server active
18 ,, No list of active update servers exists
You can analyze and, if necessary, resubmit incorrect updates with the Transaction SM13.
Caution: If a transaction in a session is flagged as incorrect as a result of an update error, the data still exists in the session and you can process the session again. However, if you proceed and the incorrect update requests are also resubmitted, this results in duplicate records. For this reason, you should only resubmit sessions manually in exceptional cases!
If the system crashes while a session is being processed, the status ("in process") is not changed. To complete the processing, you must first release the session (by choosing Session → Release to overview). When the session is processed again, any transactions already processed are not processed again.
Transactions which behave differently in the background from online (read SY-BATCH) cannot necessarily be processed in batch input, since sessions processed in the background can result in errors.
Transactions with the following features are not always batch input capable:
You can use the program RSBDCREO to reorganize log files and delete any sessions that have already been processed.
Batch Input Folders