Get Example source ABAP code based on a different SAP table
SECRET
Special Features of Batch Input Sessions
Special Features when Generating Batch Input Sessions
Step loop fields, table control fields When providing step loop fields with values, the number of the step loop line must be specified in parentheses after the field name. (BDCDATA-FNAM = 'FELDX(5)' identifies the step loop field FELDX from the fifth line of the step loop.) The same applies to table control fields.
Dynpros with variable step loops When batch input sessions that contain dynpros with variable step loops are created and run, the standard dynpro size must always be used.
Fields in subscreens In batch input, fields in subscreens are specified under the name of the calling screen. If a dynpro contains multiple subscreens, the field names in the subscreens must be unique. Example: The dynpro SAPTEST1 0100 calls the subscreen SAPTEST2 0200. The field SFLIGHT-CARRID of the subscreen SAPTEST2 0200 is to be provided with values in batch input. For the batch input program, the field is part of the calling dynpro, namely SAPTEST1 0100. The technical information for a field also includes the name of the calling dynpro in the batch input field description, if the field concerned is a subscreen field.
Function codes Function codes are set by assigning the required function code value to the batch input field BDC_OKCODE (BDCDATA-FNAM = 'BDC_OKCODE'. BDCDATA-FVAL = 'UPDA'.).
Radio buttons, checkboxes, and pushbuttons In batch input, radio buttons and checkboxes are set 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 multiple radio buttons are set inadvertently in a group, the system only sets the last one when generating the session. Pushbuttons are handled like function codes. This means assigning the appropriate function code for the pushbutton to the field 'BDC_OKCODE'. Exception:If, on a dynpro, the cursor is on a different pushbutton, the function code for this pushbutton applies. This overwrites the entered function code (example: Confirmation Dialog Box). In cases like this, the cursor must be positioned (see below).
Positioning the cursor The cursor is placed on a field by assigning the name of the relevant field to the batch input field BDC_CURSOR. Example: Cursor in the confirmation dialog box is to be set to the 'No' function. In the function module POPUP_TO_CONFIRM_STEP (function group SPO1), dynpro 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'.).
Changes to transactions When a transaction is changed, the batch input programs must be also be modified in the following cases:
Mandatory fields added/deleted
Field names/properties changed
Function codes/function key numbers changed
Dynpro order changed
Special Features when Processing a Batch Input Session
Differences between online and background processing
Authorization Check 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, the error message 390(00) is displayed which reads 'Processing session ** in background (SUBMIT error, see SYSLOG)'.
Different Background and Online Behavior of Application Transaction 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.
List Processing 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 dynpro SAPLSPRI 0100 does not exist' and the session then has the status 'With errors'.
Cursor Position In completely inactive dynpros, 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 dynpro. When processing a session with inactive dynpros 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 'With errors'.
Warning Dialog A warning dialog (message type 'W') can only be exited by pressing ENTER. For batch input, this means that dynpros with warning dialogs must each be included twice in the dynpro sequence.
User-specific formats (date, decimal format) 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.
'Back', 'Exit' and 'Cancel' If choose 'Back', 'Exit', or 'Cancel' is chosen 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, the batch input commands /BDEL (delete transaction), /N (next transaction), and /BEND (cancel (batch input)) should be used. When a batch input session has been canceled with /BEND, the status of the session is set to 'With errors'.
SET/GET parametersSET/GET parameters are not supported in batch input. With the many different transactions in batch input, it is not acceptable for one transaction to be able to determine the environment of the next transaction.
Messages If the option 'Extended log' is selected 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 displayed, batch input terminates. The behavior of the individual message types is as follows:
A message (Abend)
Online and background: Batch input is terminated and the session has the status 'With errors'.
E message (Error)
Online: The screen that contains the message is displayed and the input with the error must be corrected.
Background: Batch input is terminated and the session has the status 'Incorrect'.
I message (Info), S message (Success), W message (Warning)
Online: With 'Process visible', the message is displayedin the status bar; with 'Display only errors', the message is not displayed.
Background: If desired (see above), the message is written to the log.
Update In batch input (but not with CALL TRANSACTION USING), updates are generally synchronous, meaning that 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 update table 7 Error when updating update table 8 No main memory for update program 9 Error message in update mode resulting from application 10 Unable to load dynpro due to lack of memory 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 Updates with errors can be analyzed and, if necessary, resubmitted using the transaction SM13. Warning: If a transaction in a session is flagged as having errors as a result of an update error, the data still exists in the session and the session can be processed again. However, the session runs again and the update requests with the errors are also resubmitted, this produces duplicate records. For this reason, sessions should be resubmitted manually only in exceptional cases.
System crash If the system crashes while a session is being processed, the status ('in process') is not changed. To complete the processing, the session must first be released (by choosing Session -> Release to overview ). When the session is processed again, any transactions already processed are not processed again.
What Does Not Batch-Input-Capable Mean? 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:
Interactive list processing (sessions cannot be processed in the background)
Another transaction is started within batch input
Deletion of a session with /i
Log Reorganization The log files can be reorganized using the program RSBDCREO. Processed folders can also be deleted using RSBDCREO.
Batch Input Authorizations
S_BDC_ALL, authorization for all batch input activities
S_BDC_ABTC, processing of sessions in the background
S_BDC_AONL, processing of sessions online
S_BDC_ANAL, analysis of sessions/logs
S_BDC_DELE, deletion of sessions/ logs
S_BDC_FREE, release of sessions
S_BDC_LOCK, locking/unlocking of sessions
S_BDC_REOG, reorganization of logs and processed sessions
