Professional Documents
Culture Documents
The SAP System offers two primary methods for transferring data into the System
from other SAP Systems and non-SAP Systems. These two methods are collectively c
alled "batch input" or "batch data communication."
basic technique for data transfer with batch input.
Both batch input methods work by carrying out normal SAP transactions, just as a
user would. However, batch-input can execute the transactions automatically and
is therefore suitable for entering large amounts of data that are already avail
able in electronic form.
The batch input technique offers these advantages for transferring data:
The procedure:
1. Analyze the data that is to be transferred to the SAP System.
Goal: Determine how your existing data should be mapped to the SAP data structur
e.
Method: You'll need to determine the structure of the data that is to be transfe
rred into the system. Using the SAP data structure that you generate in step 2,
you'll need to determine how the data to be transferred must be mapped to the SA
P structure. You'll also need to determine whether any data type or data length
conversions are required.
For more information, please see DATA CONVERSIONS(6).
2. Generate SAP data structures for incorporation into your data export program.
Method: Use the data structure generation function of the ABAP/4 dictionary to g
enerate data structures for SAP tables in any of several programming languages.
If you are using one of SAP's standard batch input programs, then use of this fu
nction is required. The standard batch input programs generally require that you
use a special pre-defined data structure.
For more information, please see GENERATING AN SAP DATA STRUCTURE(5).
If you're writing your own batch input procedure, then you will need to determin
e the data structure on your own. You'll need to analyze the SAP transactions to
find the names of the fields that the transaction requires. For more informatio
n, please see ANALYSING SAP TRANSACTIONS(4).
3. Code your data transfer program. You can write the program in ABAP/4 or as an
external program. You'll find more information in WRITING A DATA TRANSFER PROGR
AM(3).
4. Export the data that is to be transferred to a sequential file.
Requirements:
The file must use the logical format required by the batch-input program that wi
ll import the file (step 6).
Reading and interpreting the file is much easier if you write it in ASCII or EBC
DIC
(character) format rather than, for example, writing numeric data in hexadecimal
format.
Character format is required by the pre-defined SAP batch input programs.
5. If necessary, code the ABAP/4 batch input program that will read in the data
to be transferred from your file.
SAP supplies ready-to-run batch-input programs for most of the SAP applications.
For more information on writing your own program, see WRITING A BATCH INPUT PROG
RAM : PROCEDURE IN OVERVIEW(10).
6. Process the data and add it to the SAP System. You can do this either by:
GENERATING A BATCH-INPUT SESSION(A) ; or
by processing data directly in your batch-input program with the ABAP/4 statemen
t
CALL TRANSACTION USING (19).
7. Check that all data has been successfully processed.
Method: Analyze the batch input processing log. If you are using CALL TRANSACTIO
N USING, then you will need to analyze the processing messages collected by your
program.
You'll find more information on running and analyzing sessions and logs in MANAG
ING BATCH-INPUT SESSIONS(B).
8. Correct and re-process erroneous data.
Method: You can use the batch-input management function to process erroneous tra
nsactions interactively. You can correct data during this interactive processing
.
One of the two recommended ways to process batch input data is to store the data
in a batch input session. This session can then be run in the SAP System to ent
er the batch input data into the system.
In general, preparing a session is the best and most comfortable way to process
batch input data. However, you may wish to use the alternate method, CALL TRANSA
CTION USING, if your batch input sessions cannot be run quickly enough. For more
information on choosing the best batch input method, see SELECTING A BATCH-INPU
T METHOD(11).
Creating, Filling, and Closing a Batch Input Session
To create a session, program the following procedure using the following BDC_ fu
nction modules:
1. Open the batch input session using function module BDC_OPEN_GROUP (15) .
2. For each transaction in the session:
a. Fill the BDCDATA structure with values for all screens and fields that must b
e
processed in the transaction. For more information, please see USING THE
BATCH-INPUT DATA STRUCTURE (12).
b. Transfer the transaction to the session with BDC_INSERT (16) .
3. Close the batch input session with BDC_CLOSE_GROUP (17).
The following topics describe these function modules. See SAMPLE BATCH INPUT PRO
GRAM(22) for an example of how the function modules are used.
---------------------------------------------------------------
B.MANAGING BATCH-INPUT SESSION.
Batch input sessions enter data non-interactively into an R/3 System. Batch inpu
t is typically used to transfer data from non-R/3 Systems to R/3 Systems or to t
ransfer data between R/3 Systems.
This section describes how to manage batch input sessions.
To reach the main menu of the batch input system, select System --> Services -->
Batch input.
Overview and Concepts
a) Task Overview: Batch Input
b) Batch Input: Concepts
Working with Batch Input Sessions
c) Processing Sessions Automatically
d) Selecting Sessions
e) Running Sessions
f) Correcting a Session
g) Deleting Sessions
h) Locking and Unlocking Sessions
i) Releasing and Restarting an Interrupted Session
Information and Analysis
j) Displaying Queue Management Information
k) Displaying Session Logs
l) Reorganizing the Log File
m) Analyzing Sessions
a) Task Overview: Batch Input.
With the functions of the batch input management system, you can do the followin
g:
Start batch input sessions to enter data into an R/3 System.
For debugging sessions that contain errors, the batch input system offers two mo
des for running sessions interactively.
Schedule the background program that automatically submits sessions for processi
ng in
the background.
Lock a session until a specified date.
Locking a session prevents it from being run.
Delete batch input sessions.
Release a session for re-execution if it has been aborted by a system failure or
shutdown while being created or executed.
Analyze a batch input session before or after it has run.
The analysis function lets you display data entered in the transactions in a ses
sion. You can:
display the screens called by the session with the session data filled in.
display listings of input fields by field name, with the session data for each f
ield.
Display the log produced by a batch input session.
Functionally:
For help in generating sessions, please see the Basis Programming Interfaces man
ual.
b) Batch Input: Concepts:
Processing Sessions
A batch input session is a set of one or more calls to transactions along with t
he data to be processed by the transactions. The system normally executes the tr
ansactions in a session non-interactively, allowing rapid entry of bulk data int
o an R/3 System.
A session simulates on-line entry of transactions and data. It calls transaction
s and enters data using most of the facilities that are available to interactive
users.
For example, the data that a session enters into transaction screens is subject
to the same consistency checking as in normal interactive operation. Further, ba
tch input sessions are subject to the user-based authorization checking that is
performed by the system.
Generating Sessions
To transfer data with batch-input, the system that is sending the data uses a da
ta transfer interface provided by an R/3 application program in the receiving sy
stem. The interface program in the application then produces a batch input sessi
on.
The interface program in an application is an ABAP/4 program that sets up the tr
ansaction calls and data that make up a session. If the batch input session cont
ains data from an external source, the program also reformats the data to meet t
he requirements of the input fields in which the data is to be entered. Usually,
such programs are provided by the R/3 applications. For more information, pleas
e see the documentation of the R/3 applications.
Authorizations
When a session is generated, a client and user are associated with it. If the se
ssion is run in background-processing mode, the system uses this user for author
ization checking as the session runs. This authorization testing applies whether
you sent the job for batch execution or the session was started by a background
job.
Sessions that you process in one of the interactive modes are run with your auth
orizations. The interactive modes are described later in this section.
c) Processing Sessions Automatically:
In most systems, sessions are started non-interactively with a background job th
at periodically checks for and starts any sessions that have not yet been run. R
unning sessions interactively is usually reserved for testing sessions or correc
ting sessions.
To start batch input sessions automatically, schedule the ABAP/4 program RSBDCSU
B for repeated execution. The program schedules sessions for immediate execution
in the background processing system.
With RSBDCSUB, you can use all of the selection criteria offered on the batch in
put main menu to select sessions to run:
session name
date and time of generation
status: ready to run or held in the queue because of errors
d) Selecting Sessions:
To reach the main menu for managing batch input sessions, select System --> Serv
ice -->
Batch input. On the main menu, you can select sessions using any or all of the f
ollowing criteria:
session name
date on which the session was generated (entered into the session queue)
session status
You can also select from one of two actions:
To display the session queue, select Session --> Overview.
You can start, analyze, or delete sessions in the queue.
To display session log files, select Session --> Logs.
All sessions generate a log when they are run. From the list of session logs, yo
u can take further actions, such as analyzing a session.
The Session Queue
The information in the session queue includes the following:
Date and Time: The date and time when a session was generated (entered in the
session queue).
Locked: If a session is locked, this column shows the date upon which the system
releases the session. A locked session cannot be started.
Created by: The user who generated the session.
Tran. and Screen: The number of transactions and screens, respectively, that rem
ain to be processed in a session.
Auth. user: The user under whose authorizations the session will be run if it is
submitted for batch execution.
You can display statistics on the transactions in any session by marking the ses
sion and using the Statistics function.
Session Sorting and Status
Sessions in the session queue are sorted by date and time of generation and are
grouped in different lists according to their status.
possible statuses are as follows:
not yet processed
The Tran. and Screen fields in the display show how many transactions and screen
s,
respectively, the session contains.
held in the session queue because of errors in transactions (Errors in sessions)
Transactions that contained errors are aborted; all correct transactions are pro
cessed.
The Tran. and Screen fields in the session display show how many incorrect
transactions were found in the session.
You can restart a session and correct the erroneous transactions with one of the
interactive execution modes offered by the batch input system. For more informa
tion, please see Correcting a Session(f).
processed
For further information on a session that has been successfully run, you can dis
play the log generated by the session. All completed sessions generate a log. Yo
u cannot run a completed session a second time.
Only sessions that were generated with the KEEP option are held in the queue aft
er
processing. Other sessions are deleted after they are successfully completed.
in generation
You will usually see this status only if you happen to display the queue while a
session is being generated (entered into the session queue).
You can also encounter this status if a system failure has interrupted the gener
ation of a session. If you suspect that a session has been interrupted, please s
ee Releasing and Restarting an Interrupted Session(i) for more information.
in process
You will usually see this status only if you happen to display the queue while a
session is being run.
You can also encounter this status if a system failure has interrupted the execu
tion of a session. If you suspect that a session has been interrupted, please se
e Releasing and Restarting an Interrupted Session(i) for more information.
e) Running Sessions:
Running a batch input session executes the transactions in the session and enter
s data into an R/3 System.
To start a session, select Session ® Overview from the main batch input screen. Th
en mark the session(s) that you wish to start and select Session ® Process or ® Proc
ess in batch.
You can start any session in the not yet processed list that is not locked. With
Process/foreground or mode, you can also re-start transactions that have the st
atus Incorrect. Sessions with the status Processed cannot be run again.
Run Modes
There are three ways to run a session:
f) Correcting a Session:
When a session is run in background-processing mode, the system marks transactio
ns that contain errors as incorrect. All other transactions in the session are c
ompleted. The session itself is kept in the session queue in the Errors section
of the list.
A transaction contains an error if it generates an error message of type E (erro
r) or type A (abnormal termination). Messages of other types are ignored and do
not affect the execution of a session.
You can correct and re-execute the incorrect transactions in an "Errors" session
. There are two ways to do so:
1. Re-run the session in display-all or error-display mode. These modes offer th
e following advantages:
The system skips transactions that were successfully completed. Only incorrect t
ransactions or transactions that have not been executed are run.
You can change inputs and add missing screens interactively as incorrect transac
tions run.
The following topic provides more information on using display-all mode or error
-display mode to correct a transaction.
2. As an alternative, you can analyze the session to determine what the error wa
s. With the analysis displays, you can check the screen that contained the error
and the values that were entered in it. You can then correct the program that g
enerated the session and regenerate the session.
You must ensure that the new session does not include transactions that were suc
cessfully completed. Otherwise, the updates made by the transactions will be per
formed again.
Using Display-All Mode
When you use display-all mode to re-start a session that contains an incorrect t
ransaction, the system skips to the first screen of the incorrect transaction. C
ompleted transactions are not re-executed.
options when you run a session interactively.
To correct a transaction, you can:
use the ENTER key to step through the screens recorded in the session
As in normal operation, pressing the ENTER key starts a dialog step. As long as
you simply press ENTER, the system processes the screens and data recorded in th
e session.
change or add values in any screen
When you press ENTER, the system processes the data as altered by you.
branch off from the transaction flow recorded in the session
You can use any function that you wish within the transaction that is currently
running. You can, for example, branch off to enter data on a screen that was omi
tted from the session.
To resume executing the session, return to the screen that was expected by the s
ession.
It holds the data for the screen recorded in the session until you have returned
to that screen. It then resumes normal execution of the session.
Interrupting a Session
You can interrupt the interactive execution of a session by entering the /bend O
K code on any screen. /bend terminates the transaction currently being executed
in the session and marks the transaction with the status Incorrect. The session
is kept in the queue and is displayed in the Errors in sessions section of the l
ist.
You can use /bend when testing sessions. For example, you may wish to run the fi
rst two transactions of a large session in display-all mode to make sure that th
e session has been generated correctly.
If the transactions are correct, you can then terminate the run with /bend and t
hen submit the session for background execution. The transactions that have alre
ady been run will not be run again.
Deleting a Transaction
You can delete a transaction from a session during interactive execution by ente
ring the /bdel OK code. The transaction is removed from the session. The deleted
transaction cannot be run even if you restart the session, and you cannot take
back the deletion.
The transaction is, however, available for analysis if the session was generated
with the KEEP option set. The transaction is marked with the status Deleted in
the analysis display. The deletion also is recorded in the log generated by the
session.
g) Deleting Sessions:
You can delete any session from the session queue. Deleting a session discards t
he session. If the session has already been run, you also delete the session log
.
Normally, sessions are deleted from the session queue automatically when they ar
e completed. However, if a session was generated with the KEEP option, it is kep
t in the session queue. You must explicitly delete the session when you no longe
r need it.
A session is also kept in the queue if it contained an error or was broken off w
ith the /bend OK code. Such a session is deleted when you finish processing it,
unless it was generated with the KEEP option.
To delete a session from the session queue, mark the sessions to be deleted and
select Edit --> Delete.
h) Locking and Unlocking Sessions:
You can lock sessions in the session queue by marking the sessions and selecting
Edit ® Lock.
Locking a session prevents a session from being started until after the date rec
orded in the lock. For example, a session locked until the eleventh of November
can be started only after that date.
You may wish to lock a session for such reasons as
holding a session until a specified date
preventing a session that contains errors from being re-started
preventing a session that requires a special resource, such as printer forms or
a specific tape, from being started unintentionally.
You can unlock a session by changing the lock date to the present date or by ent
ering a space as the lock date.
caution
Release an active session only if you are sure that it has been interrupted and
is no longer running.. Sessions also have the status Active while they are runni
ng.
caution
Restarting after abnormal termination during generation: You can start a session
that was interrupted while it was being generated. The session is guaranteed to
contain only complete transactions and to be runnable.
However, there is no guarantee that the session contains all of the transactions
that were to be included in it. You may therefore wish to delete and regenerate
such a session.
6) DATA CONVERSIONS:
Use the field descriptions that you obtained in Analyzing SAP Transactions(4) or
Generating an SAP Data Structure(5) to determine the following:
which fields can be taken over directly from your existing data. That is, there
is a direct match between an existing data field and the corresponding SAP data
field.
for which fields a conversion procedure is necessary for mapping your existing d
ata to the requirements of the SAP System.
CoNverting Data from Old Format to SAP Format
Your program must format batch input values just as an on-line user would when t
yping them in. In particular:
The data must be character format.
No piece of data may be longer than its target SAP field.
If the data is shorter than the target field, you must left-justify it within th
e SAP field (pad it with blanks at the right end).
(7) INITIALIZING AN SAP DATA STRUCTURE:
Standard SAP batch input programs require that every field in a data structure c
ontains either:
a value; or
a special NODATA marker, which indicates that the no batch input data is require
d for the field.
If you are writing your own data transfer program, you should therefore initiali
ze all of the fields in your batch input data structure with the NODATA characte
r. The NODATA character must occupy the first position in the field, as shown in
the figure below.
By default, the NODATA character is the forward slash. To initialize a field to
NODATA, you must write this character as the first character in the field value.
If a batch input program finds NODATA in a field, then the program allows the fi
eld to default to its standard value in the SAP transaction that contains the fi
eld.
Setting the NODATA marker: You can freely select another character as the NODATA
marker. Define the new character in the batch input program that reads the data
in the BGR00-NODATA field:
Data: like bgr00.
-NODATA = ''.
GENERATING A SEQUENTIAL FILE:
If you are transferring data from a non-SAP System, then you will probably need
to use a file as the transfer medium for the data. (For data transfer between SA
P Systems, you may be able to use RFC or CPI-C to process data directly in the t
arget SAP System.)
The file that you generate should have the following characteristics:
All data should be in character format. This is required by the standard SAP bat
ch input programs.
Data must have the logical structure expected by the batch input program.
For a standard SAP batch input program, this requirement means that you have gen
erated the data structure defined for the batch input program. For more informat
ion, see Generating an SAP Data Structure(5).
You'll find sample code for reading from and writing to a sequential file in Sam
ple Program: Data Transfer(9) .
EXAMPLE:
REPORT BITFER.
* SAP structures for batch input processing:
TABLES: BGR00, BKN00, BKNA1.
* Structure of existing data to be transferred:
DATA: BEGIN OF OLDREC,
TELE1(10) TYPE C,
CUSTNR(8) TYPE C,
TITLE(2) TYPE C,
NAME1(30) TYPE C,
END OF OLDREC.
* Auxiliary structure for initializing fields:
DATA: BEGIN OF AUXREC.
INCLUDE STRUCTURE BKNA1.
DATA: END OF AUXREC.
* SAP fields for converted data:
DATA: CUSTNR LIKE BKN00-KUNNR,
NAME1 LIKE BKNA1-NAME1,
TELE1 LIKE BKNA1-TELF1.
* For initializing fields:
DATA: N TYPE I.
FIELD-SYMBOLS .
* File and session names, NODATA character:
PARAMETERS:
OLDFILE(20) DEFAULT '/tmp/oldfile' LOWER CASE,
SAPFILE(20) DEFAULT '/tmp/sapfile' LOWER CASE,
ERRFILE(20) DEFAULT '/tmp/errfile' LOWER CASE,
SESSION(20) DEFAULT 'ADDRDAT' LOWER CASE,
NODATA DEFAULT '/' LOWER CASE.
START-OF-SELECTION.
OPEN DATASET: OLDFILE FOR INPUT IN TEXT MODE,
SAPFILE FOR OUTPUT IN TEXT MODE,
ERRFILE FOR OUTPUT IN TEXT MODE.
* Open batch input session as first SAPFILE entry:
* program:
MOVE: 'O' TO BGR00-STYPE,
SESSION TO BGR00-GROUP,
SY-MANDT TO BGR00-MANDT,
SY-UNAME TO BGR00-USNAM,
NODATA TO BGR00-NODATA.
TRANSFER BGR00 TO SAPFILE.
* Initialize data fields with NODATA:
DO.
ADD 1 TO N.
ASSIGN COMPONENT N OF STRUCTURE AUXREC TO .
IF SY-SUBRC NE 0. EXIT. ENDIF.
MOVE BGR00-NODATA TO .
ENDDO.
MOVE AUXREC TO BKNA1.
* Read and convert existing data:
DO.
" Read data record:
READ DATASET OLDFILE INTO OLDREC.
IF SY-SUBRC NE 0. EXIT. ENDIF.
" Check data and transfer only certain records:
IF OLDREC-CUSTNR(5) NE 'AABBC'
OR OLDREC-CUSTNR(6) EQ 'AABBCD'
OR OLDREC-TELE1 EQ SPACE.
TRANSFER OLDREC TO ERRFILE.
* TEXT-001: 'Data not transferred for customer:'
WRITE: / TEXT-001, OLDREC-CUSTNR.
ELSE.
" Convert the customer number to SAP convention:
IF OLDREC-CUSTNR+5(1) = 'C'.
IF OLDREC-CUSTNR+5(1) = 'D'.
ENDIF.
" Convert abbreviations to full words:
CASE OLDREC-TITLE.
WHEN 'Co'. BKNA1-TITLE = 'Company'.
WHEN 'Corp'. BKNA1-TITLE = 'Corporation'.
WHEN OTHERS. BKNA1-TITLE = NODATA.
ENDCASE.
" Convert records from old format to SAP format:
MOVE: OLDREC-CUSTNR TO CUSTNR,
OLDREC-NAME1 TO NAME1,
OLDREC-TELE1 TO TELE1.
" Fill SAP structures:
MOVE: '1' TO BKNOO-STYPE,
'XD02' TO BKNOO-TCODE,
CUSTNR TO BKNOO-CKUNNR.
MOVE: '2' TO BKNA1-STYPE,
'BKNA1' TO BKNA1-TBNAM,
'TELE1 TO BKNA1-TELF1,
NODATA TO BNKA1-SENDE.
" Transfer data to SAPFILE:
TRANSFER: BKNOO TO SAPFILE,
BKNA1 TO SAPFILE.
* TEXT-02: 'Data was transferred for customer:'
WRITE: / TEXT-002, OLDREC-CUSTNR, BKNOO-CUSTNR.
ENDIF.
ENDDO.
CLOSE DATASET: OLDFILE, SAPFILE, ERRFILE.
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. E
ach screen that is processed in the course of a transaction must be identified w
ith 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 v
alue that is to be entered into a field. These records use the FNAM and FVAL fie
lds 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 exec
ute 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 spec
ified 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 CAL
L TRANSACTION USING, then the transaction is specified directly in this statemen
t.
The following table shows what the contents of a BDCDATA structure might look li
ke. 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 th
is 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 th
e 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-sensitiv
e. 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 Tra
nsactions(4) for more information.
Data formatting requirements: Please see Data Conversions(6) for more informatio
n.
--------------------------------------------------------------------------------
-----------------------
13) PROGRAMMING TECHNIQUES :
ENTERING DATA AND EXECUTING
FUNCTIONS:
a)Sample Code: Filling the BDCDATA Structure
b)Identifying a Screen
c)Entering a Value in a Field
d)Executing a Function
e)Entering Values in Loop Fields
f)Positioning the Cursor
g)Ending a Transaction
a)Sample Code: Filling the BDCDATA Structure:
The following form routine shows how the BDCDATA structure should be filled. Bui
ld the structure line by line using MOVE and APPEND statements. Before building
each line, reset the header line of the internal table with the CLEAR statement.
Special techniques, such as placing the cursor, are not shown in this example.
Example:
Assume in this example that the BDCDATA structure has been declared as BDCDAT in
the ABAP/4 program:
FORM Fill-BDC-Table
REFRESH BDCDAT
" Start new DYNPRO
CLEAR BDCDAT
MOVE: TO BDCDAT-PROGRAM.
TO BDCDAT-DYNPRO.
'X' TO BDCDAT-DYNBEGIN.
APPEND BDCDAT.
" Enter fields and values for DYNPRO
CLEAR BDCDAT.
MOVE: TO BDCDAT-FNAM.
TO BDCDAT-FVAL.
APPEND BDCDAT.
CLEAR BDCDAT.
MOVE: TO BDCDAT-FNAM.
TO BDCDAT-FVAL.
APPEND BDCDAT.
...
...
" Start next DYNPRO
CLEAR BDCDAT.
MOVE: TO BDCDAT-PROGRAM.
TO BDCDAT-DYNPRO.
'X' TO BDCDAT-DYNBEGIN.
APPEND BDCDAT.
ENDFORM.
b) Identifying a Screen:
The first record for each screen must contain information that identifies the sc
reen: program name, screen name and a start-of-screen indicator. You record this
information in the PROGRAM, DYNPRO, and DYNBEGIN fields of the BDCDATA structur
e.
This sample BDCDATA starts a screen. The record specifies the program and screen
identifiers. With BDCDATA-DYNBEGIN, the record shows that batch input data for
a new screen is starting:
Example:
BDCDATA-PROGRAM = 'sapms38m'.
BDCDATA-DYNPRO = '0100'.
BDCDATA-DYNBEGIN = 'x'.
APPEND BDCDATA.
c) Entering a Value in a Field:
After the dynpro-start record, you must add a record for each field that is to r
eceive a value. You need fill only the FNAM and FVAL fields.
This sample BDCDATA enters a value into a field. The FNAM field identifies the t
arget field by its table and field names. FVAL specifies the value that is to be
entered:
Example:
BDCDATA-FNAM = 'RS38M-FUNC_EDIT'.
BDCDATA-FVAL = 'x'.
APPEND BDCDATA.
d)Executing a Function:
You can execute a function in a transaction by entering the function code or fun
ction key number in the command field of an SAP session. You use the FNAM and FV
AL fields to enter this information, just as you would for normal screen fields.
The command field is identified by a special name in batch input, BDC_OKCODE. Th
is name is constant and always identifies the command field.
This sample record would execute the save function. It uses the function key ass
ignment of save, which is F11. A function key number must be prefixed with the /
(slash) character:
Example:
BDCDATA-FNAM = 'BDC_OKCODE'.
BDCDATA-FVAL = '/11'.
This sample record also executes save, but uses the function code instead of the
function key assignment. All functions, whether they are displayed in menus or
as buttons, are identified by function codes. A function code must be prefixed w
ith the = character.
Example:
BDCDATA-FNAM = 'BDC_OKCODE'.
BDCDATA-FVAL = '=UPDA'.
g)Ending a Transaction:
You can successfully complete processing of a transaction in batch input in eith
er of two ways:
leave the transaction and return to the SAP main menu.
trigger an update of the database.
Ending a Transaction
Example:
Returning to the SAP main menu: From the text input screen in the ABAP/4 editor,
for example, the following BDCDATA records are necessary to leave the transacti
on:
BDCDATA-PROGRAM = 'SAPMSEDT'. "Leave text input field
BDCDATA-DYNPRO = '2310'.
BDCDATA-DYNBEGIN = 'X'.
BDCDATA-FNAM = 'BDC_OKCODE'.
BDCDATA-FVAL = '/3'. "Back function key
BDCDATA-PROGRAM = 'SAPMS38M'. "Leave ABAP/4 editor
BDCDATA-DYNPRO = '0100'.
BDCDATA-DYNBEGIN = 'X'.
BDCDATA-FNAM = 'BDC_OKCODE'.
BDCDATA-FVAL = '/15'. "Quit function key
--------------------------------------------------------------------------------
-------
(14) CREATING BATCH INPUT SESSIONS:
One of the two recommended ways to process batch input data is to store the data
in a batch input session. This session can then be run in the SAP System to ent
er the batch input data into the system.
In general, preparing a session is the best and most comfortable way to process
batch input data.
However, you may wish to use the alternate method, CALL TRANSACTION USING, if yo
ur batch input sessions cannot be run quickly enough. For more information on ch
oosing the best batch input method, see Selecting a Batch-Input Method(11) .
Creating, Filling, and Closing a Batch Input Session
To create a session, program the following procedure using the following BDC_ fu
nction modules:
1. Open the batch input session using function module BDC_OPEN_GROUP(15) .
2. For each transaction in the session:
a. Fill the BDCDATA structure with values for all screens and fields that must b
e processed in the transaction. For more information, please see Using the Batch
Input Data Structure(12).
b. Transfer the transaction to the session with BDC_INSERT(16) .
3. Close the batch input session with BDC_CLOSE_GROUP(17).
The following topics describe these function modules. See Sample Batch Input Pro
gram(22) for an example of how the function modules are used.
GROUP
Name of the session that is to be created. May be up to 12 characters long.
Default: None. You must specify a session name.
HOLDDATE
Lock date. The session is locked and may not be processed until after the date t
hat you specify.Only a system administrator with the LOCK authorization for the
authorization object Batch Input Authorizations can unlock and run a session bef
ore this date.
Format: YYYYMMDD (8 digits).
Default: No lock date, session can be processed immediately. A lock date is opti
onal.
KEEP
Retain session after successful processing. Set this option to the value X to ha
ve a session kept after it has been successfully processed. A session that is ke
pt remains in the input/output queue until an administrator deletes it.
Sessions that contain errors in transactions are kept even if KEEP is not set.
Default: If not set, then sessions that are successfully processed are deleted.
Only the batch input log is kept.
USER
Authorizations user for background processing. This is the user name that is use
d for checking authorizations if a session is started in background processing.
The user must be authorized for all of the transactions and functions that are t
o be executed in a session.Otherwise, transactions will be terminated with "no a
uthorization" errors.
The user can be of type dialog or background. Dialog users are normal interactiv
e users in the SAP System. Background users are user master records that are spe
cially defined for providing authorizations for background processing jobs.
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 mor
e comfortable if you use "classical" batch input processing by way of batch inpu
t 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 Ba
tch-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 req
uirements for filling the BDCDATA structure are the same as for "classical" batc
h input using sessions. For more information, please see Using the Batch Input D
ata Structure(12).
2. With a CALL TRANSACTION USING statement, call the transaction and pass the BD
CDATA 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. Thi
s 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 n
ot. Control returns to your program as soon as transaction processing is finishe
d. (Database updates however, may have taken place or may have not have taken pl
ace, depending on the value of the UPDATE parameter.)
E Display errors only. The transaction goes into display mode as soon as an erro
r 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 shou
ld 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 t
o be completed. It simply passes the updates to the SAP update service.Asynchron
ous processing therefore usually results in faster execution of your batch input
program.
Asynchronous processing is NOT recommended for processing any larger amount of d
ata. 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 upda
te of the database or not.
If you use asynchronous updating, then you will need to use the update managemen
t facility (transaction SM12) to check whether updates have been terminated abno
rmally 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 b
e 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 muc
h 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 key
word documentation of SET UPDATE TASK LOCAL for more information.)
The Messages Parameter
The MESSAGES specification indicates that all system messages issued during a CA
LL TRANSACTION USING are written into the internal table . The internal table mu
st have the structure BDCMSGCOLL.
Example
You can have system messages issued by transaction SE38 (bottom of example) coll
ected 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 t
he 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 fi
elds shown below; their contents are automatically written into the message tabl
e. You can loop over the message table to write out any messages that were enter
ed into it.
--------------------------------------------------------------------------------
------------
Error Analysis and Restart Capability
Unlike "classical" batch input processing using sessions, CALL TRANSACTION USING
processing does not provide any special handling for incorrect transactions. Th
ere is no restart capability for transactions that contain errors or produce upd
ate failures.
You can handle incorrect transactions by using update mode S (synchronous updati
ng) and checking the return code from CALL TRANSACTION USING. If the return code
is anything other than 0, then you should do the following:
The MODE parameter in the CALL statement is explained in Using CALL TRANSACTION
USING for Batch Input(19).
Example
CALL DIALOG 'DIALOG1' USING BDCDATA MODE 'E'.
--------------------------------------------------------------------------------
-------------------------------------