Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

BDC DOCUMENTATION

former_member212002
Active Contributor
0 Kudos
1,464

Hello Experts,

where can i get the documentation for step by step learning of BDC.

i am new to abap and don't have any idea abt data transfer in bdc.

1 ACCEPTED SOLUTION

Former Member
0 Kudos
200

Hello Abhinab Mishra,

I am providing you with Url's.

Go through them...They will be useful....

http://www.sapbrainsonline.com/TUTORIALS/TECHNICAL/BDC_tutorial.html

http://abap-gallery.blogspot.com/2007/08/bdc-batch-data-communication-tutorial.html

I am also providing BDC Documentation for u, plz go through it. This is the bst info that you can get. So first go through it very carefully.

**********************************

BDC Documentation

***********************************************************

1) Batch Input Concepts

2) Transferring Data: Batch Input Procedure in Overview

DATA TRANSFER PROGRAMS

3) Writing a Data Transfer Program

4) Analyzing SAP Transactions

5) Generating an SAP Data Structure

6) Data Conversions

7) Initializing an SAP Data Structure

😎 Generating a Sequential File

9) Sample Program: Data Transfer

BATCH INPUT PROGRAMS

10) Writing a Batch Input Program: Procedure in Overview

11) Selecting a Batch-Input Method

12) Using the Batch Input Data Structure

13) Programming Techniques: Entering Data and Executing Functions

CREATING SESSIONS

14) Creating Batch Input Sessions

15) Creating a Session with BDC_OPEN_GROUP

16) Adding Data to a Session: BDC_INSERT

17) Closing a Session: BDC_CLOSE_GROUP

18) Processing Batch Input Sessions

CALL TRANSACTION USING

19) Using CALL TRANSACTION USING for Batch Input

20) Using CALL DIALOG with Batch Input

GENERAL INFORMATION AND SAMPLE PROGRAM

21) Direct Input

22) Sample Batch Input Program

23) Batch Input recording for transaction runs

24) Batch Input Authorizations

(1) BATCH INPUT CONCEPTS:

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 called "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 available in electronic form.

The batch input technique offers these advantages for transferring data:

• No manual interaction is required during data transfer. If the data to be transferred is already available in electronic form (on a tape, for example), then you can enter the data automatically into the SAP System using batch input.

• Batch input ensures data integrity. Batch input enters data into the SAP System using the same transactions that interactive users do. Batch input data is therefore submitted to all of the checks and controls that apply to data entered by normal interactive means.

The batch input methods.

There are several ways to process batch input data in the SAP System.

FIGURE(1)

Batch input processing methods.

The first processing method could be called "classical batch input." In it, an ABAP/4 program reads the external data that is to be entered in the SAP System and stores the data in a "batch-input session." A session stores the actions that are required to enter your data using normal SAP transactions.

When the program has finished generating the session, you can run the session to execute the SAP transactions in it. You can either explicitly start and monitor a session with the batch-input management function (System --> Services --> Batch input) or have the session run in the background processing system.

This method uses the function modules BDC_OPEN, BDC_INSERT, and BDC_CLOSE to generate sessions.

In the second method, your program uses the ABAP/4 CALL TRANSACTION USING statement to run an SAP transaction. Batch-input data does not have to be deposited in a session for later processing. Instead, the entire batch-input process takes place inline in your program.

There is a third batch-input method using the ABAP/4 CALL DIALOG statement. However, SAP recommends against using this method unless necessary. The CALL DIALOG method is now outdated and is more complex and less comfortable to use than the other techniques.

All three batch-input methods use a common data structure for holding the instructions and data for SAP transactions. This structure is defined as structure BDCDATA in the ABAP/4 Dictionary.

For help in selecting the method to use, please see SELECTING A BATCH-INPUT METHOS (11).

Typical uses of batch input.

Uses of batch input include the following:

• transferring data from another system when you install your SAP System

• regularly transferring data that is captured by a non-SAP system in your company into the SAP System. Assume, for example, that data collection in some areas of your company is still performed by a non-SAP system. You can still consolidate all of your data in the SAP System by exporting the data from the other system and reading it into the SAP System with batch input.

You can also use batch input to transfer data between two R/3 Systems. However, there are more direct methods for doing this, such as RFC (remote function calls).

application support for batch-input.

The SAP applications provide pre-programmed support for batch input transfers for many of SAP's business objects.

To implement one of the supported data transfers, you must often write the program that exports the data from your non-SAP System. This program, known as a "data transfer" program must map the data from the external system into the data structure required by the SAP batch input program.

Should you wish to write a transfer program that executes outside the SAP System, then the SAP applications provide definitions of the required data formats for the exports. From these definitions, you can generate code for the data structures to include in your export program. You can also write such programs in ABAP/4, which lets you take advantage of the comfort and conveniences of the SAP Development Workbench.

Once you have exported the data, you can then use a standard, pre-programmed SAP report to import the data. This program uses one of the batch input methods to process the data and add it to the SAP System.

You can find information on pre-defined batch-input programs in the SAP Customizing System. Choose Tools --> Customizing. Then display either your Enterprise IMG (Implementation Guide) projects or the SAP standard IMG. In the project display, use the Expand function to display all nodes in the project. You can then search for relevant topics with the keywords batch input and transfer.

(2) TRANSFERING DATA : BATCH INPUT PROCEDURE IN OVERVIEW.

Transferring data with batch input requires the steps shown in the illustration and list below.

Note that SAP standard batch-input programs take care of several of these steps for you. For more information, please see BATCH INPUT CONCEPTS (1).

FIGURE(2).

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 structure.

Method: You'll need to determine the structure of the data that is to be transferred 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 SAP 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 generate 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 function 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 determine 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 information, 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 PROGRAM(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 will import

the file (step 6).

- Reading and interpreting the file is much easier if you write it in ASCII or EBCDIC

(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 PROGRAM : 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 statement

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 TRANSACTION 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 MANAGING BATCH-INPUT SESSIONS(B).

8. Correct and re-process erroneous data.

Method: You can use the batch-input management function to process erroneous transactions interactively. You can correct data during this interactive processing.

A.GENERATING A BATCH-INPUT SESSION.

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 enter 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 your batch input sessions cannot be run quickly enough. For more information on choosing the best batch input method, see SELECTING A BATCH-INPUT METHOD(11).

FIGURE(3).

Creating, Filling, and Closing a Batch Input Session

To create a session, program the following procedure using the following BDC_ function 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 be

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 PROGRAM(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 input is typically used to transfer data from non-R/3 Systems to R/3 Systems or to transfer 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 following:

• Start batch input sessions to enter data into an R/3 System.

For debugging sessions that contain errors, the batch input system offers two modes for

running sessions interactively.

• Schedule the background program that automatically submits sessions for processing 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 session. 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 field.

• Display the log produced by a batch input session.

Functionally:

figure(4).

For help in generating sessions, please see the Basis Programming Interfaces manual.

b) Batch Input: Concepts:

Processing Sessions

A batch input session is a set of one or more calls to transactions along with the data to be processed by the transactions. The system normally executes the transactions in a session non-interactively, allowing rapid entry of bulk data into an R/3 System.

A session simulates on-line entry of transactions and data. It calls transactions 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, batch input sessions are subject to the user-based authorization checking that is performed by the system.

figure(5).

Generating Sessions

To transfer data with batch-input, the system that is sending the data uses a data transfer interface provided by an R/3 application program in the receiving system. The interface program in the application then produces a batch input session.

The interface program in an application is an ABAP/4 program that sets up the transaction calls and data that make up a session. If the batch input session contains data from an external source, the program also reformats the data to meet the 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, please see the documentation of the R/3 applications.

Authorizations

When a session is generated, a client and user are associated with it. If the session is run in background-processing mode, the system uses this user for authorization 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 authorizations. 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 that periodically checks for and starts any sessions that have not yet been run. Running sessions interactively is usually reserved for testing sessions or correcting sessions.

To start batch input sessions automatically, schedule the ABAP/4 program RSBDCSUB 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 input 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 --> Service -->

Batch input. On the main menu, you can select sessions using any or all of the following 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, you 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 remain 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 session 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.

figure(6).

Possible statuses are as follows:

• not yet processed

The Tran. and Screen fields in the display show how many transactions and screens,

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 processed.

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 information, please see Correcting a Session(f).

• processed

For further information on a session that has been successfully run, you can display the

log generated by the session. All completed sessions generate a log. You cannot run a

completed session a second time.

Only sessions that were generated with the KEEP option are held in the queue after

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 generation of a

session. If you suspect that a session has been interrupted, please see 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 execution of a

session. If you suspect that a session has been interrupted, please see 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 enters data into an R/3 System.

To start a session, select Session ® Overview from the main batch input screen. Then mark the session(s) that you wish to start and select Session ® Process or ® Process 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 status Incorrect. Sessions with the status Processed cannot be run again.

Run Modes

There are three ways to run a session:

figure(7).

•Process/foreground: You can interactively correct transactions that contained errors and step through transactions that have not yet been executed.

•Display errors only: This mode is like Process/foreground except that transactions that have not yet been run and which do not contain errors are run non-interactively.

If an error occurs, processing stops and the screen upon which the error occurred is displayed.

•Process in Batch: Use batch mode to schedule a session for immediate processing in the batch facility.

You receive control of your terminal again as soon as the session has been passed to the batch system.

Note that your session is automatically released for processing in the background processing system. You need not explicitly release the session for processing.

A completed session is handled in one of three ways:

- The system deletes a session from the queue when it has been successfully completed. You can check on the outcome of the session by displaying the session log file.

- If the KEEP option was set when the session was generated, then the system leaves a session in the queue, even if it was run successfully. The status is changed to Processed.

You cannot run the session a second time. You must manually delete it when you no longer need it.

- If a transaction in the session contained an error, the incorrect transaction is aborted. All other transactions are completed. The session remains in the queue and is held in the Errors section of the list. You can correct the session in one of the interactive modes and run it to completion.

A transaction contains an error if it issues a message of type E (error) or type A (abnormal termination). Other messages are ignored and do not affect the execution of a session..

A session also is held in the queue in the Errors list if the session was ended with the /bend OK code. Please see Correcting a Session(f).

For more information on correcting sessions with the display-all or error-display mode, please see Correcting a Session(f).

-

-


f) Correcting a Session:

When a session is run in background-processing mode, the system marks transactions that contain errors as incorrect. All other transactions in the session are completed. 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 (error) 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 the following advantages:

- The system skips transactions that were successfully completed. Only incorrect transactions or transactions that have not been executed are run.

- You can change inputs and add missing screens interactively as incorrect transactions 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 was. 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 generated the session and regenerate the session.

You must ensure that the new session does not include transactions that were successfully completed. Otherwise, the updates made by the transactions will be performed again.

Using Display-All Mode

When you use display-all mode to re-start a session that contains an incorrect transaction, the system skips to the first screen of the incorrect transaction. Completed transactions are not re-executed.

options when you run a session interactively.

figure(8).

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 the 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 omitted from the session.

To resume executing the session, return to the screen that was expected by the session.

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 OK 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 list.

You can use /bend when testing sessions. For example, you may wish to run the first two transactions of a large session in display-all mode to make sure that the session has been generated correctly.

If the transactions are correct, you can then terminate the run with /bend and then submit the session for background execution. The transactions that have already been run will not be run again.

Deleting a Transaction

You can delete a transaction from a session during interactive execution by entering 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.

figure(9).

-

-


g) Deleting Sessions:

You can delete any session from the session queue. Deleting a session discards the 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 are completed. However, if a session was generated with the KEEP option, it is kept in the session queue. You must explicitly delete the session when you no longer need it.

A session is also kept in the queue if it contained an error or was broken off with 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 recorded 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 entering a space as the lock date.

-

-


i) Releasing and Restarting an Interrupted Session:

If a system problem occurs while a session is being generated or is being run, the session is terminated abnormally. Typical causes of an abnormal termination might include shutdown of the R/3 System while a session is running or termination of a SAPGUI presentation process while a session is being run interactively.

In the session queue, a session that was terminated while it was being generated remains in the Being generated section of the list. A session that was terminated while it was running remains in the Active list.

You can recognize that a session has terminated abnormally because the status of the session does not change. If, for example, you find a session that was run the previous night still in the Active list, then it is likely that the session was interrupted.

If a session was to run in the background, you can check the status of the session's job in the background processing system. If the session was aborted, then the background job log contains the reason for the abnormal termination.

Before you can restart (or start) a session that terminated abnormally, you must release it. Releasing the aborted session sets its status to Being processed. Reset the status by marking the session or sessions and selecting Edit --> Release.

You can safely restart a session that was interrupted while it was being run. When you restart the session, all transactions that were successfully completed before the problem occurred will be skipped. The transaction that was executing when the problem occurred will be re-executed.

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 running.

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.

-

-


j) Displaying Queue Management Information:

Should you ever need to review the internal queue-management information on a particular entry, you can display this information by marking an entry and selecting Analysis --> Queue.

Not all of the queue management fields displayed are used by the batch input system; the queue management functions are used by other queues in the system as well. The fields that are used by the batch input system are as follows:

• Client: The client in which a session is to run.

• Groupid: The session name.

• QID: The internal ID of a session. The ID is used for queue management with System --> Services --> Queue.

• QSTATE: A character indicating the status of the batch input session.

• QERASE: If marked, indicates that the KEEP option is set. If KEEP is set, the system does not delete the session after it is successfully run.

• USERID: User to be used for authorization testing if a session is submitted for background execution.

-

-


k) Displaying Session Logs:

Every batch input session generates a log when it runs. To display a log, you can either:

• select Session --> Logs from the batch input main menu; or

• put the cursor on a particular session in the session queue and select Goto --> Log.

A session log contains any error messages issued by transactions in the session. It also includes batch input error messages reporting any problems in running transactions, together with the transaction and screen at which the problem occurred. Finally, a log contains a set of summary statistics.

-

-


l) Reorganizing the Log File:

You should periodically use the ABAP/4 program RSBDCREO to reorganize the batch input log file. You can run RSBDCREO in the background or interactively.

Running the program reduces the size of the log file, BI, in the shared R/3 directory "global" in the host system to the minimum possible size. Deleting a session marks a session log for deletion, but the storage held for the log is returned to the host only by a reorganization.

The program will delete a log only if the session to which the log belongs has been deleted.

-

-


m) Analyzing Sessions:

Use the analysis functions to check on the actions performed by a batch input session. The analysis functions allow you to display the transactions, screens, and data in a session.

You can use these functions before or after a session has been run.

note

Analysis of sessions that have been run is available only for sessions that contained an error or which were generated with the KEEP option. The KEEP option prevents the system from deleting a session that has been successfully run.

You can analyze a session by marking the session in the session queue and selecting Goto --> Analysis --> Session or by selecting Analysis from the session log screen.

Analysis Blocks

Reading very long sessions from the database can cause time-outs to occur. For this reason, the system reads sessions for analysis in blocks.

Blocks do not restrict your ability to display a long session. You can switch forward and backward from block to block with function keys.

A block always contains only complete transactions. A block boundary cannot fall in the middle of a transaction.

Session Summary

The first analysis screen lists the transactions and screens recorded in the session.

Screens are identified by the name of the program and the number of the screen. Statuses are identical to those of the session queue, except that transactions that were deleted with the /bdel OK code have the status Deleted.

Session Data

You can display the data entered on each screen of a session by selecting Analysis ® Data from the first analysis screen.

You can have the data presented to you in two formats:

• The first data display presents data in list format by field name.

• Alternatively, you can switch to the screen called by the session with the session data shown on it.

You can switch back and forth from one form of display to the other.

-

-


(3) WRITING A DATA TRANSFER PROGRAM:

The data transfer program is responsible for doing the following:

• Converting the data that is to be transferred into the SAP System as required by the SAP data structure or transactions that you are using.

The data structure may be generated from the standard SAP data structures (see Generating an SAP Data Structure(5)). This is required if you are working with a standard SAP batch input program. Or, if you are creating your own batch input procedure, you may have developed the data structure yourself by analyzing the SAP transactions with which the data is to be entered.

A conversion may be necessary for data type and length. The data type required by all standard SAP batch input programs is C, character data. You can find the required field lengths either in your analysis of the SAP data entry transactions or in the data structures that you generate in the ABAP/4 Dictionary.

• Exporting the data in SAP format to a sequential file. The batch input program in the SAP System reads the data in from this file.

Task Overview

The tasks involved in writing a data transfer program are shown in the diagram and list below.

figure(10).

Writing a Transfer Program

The procedure:

1. Analyze the structure of your existing data and specify the conversions that are required to fill the SAP data structures.

2. Generate the SAP data structure in code form and insert it into your program.

If the program is written in ABAP/4, you need only include the required tables in your program with the TABLES statement.

3. Initialize the SAP data structure.

4. Fill the structure with data, performing any conversions and error-checking that are required.

5. Write the sequential file that is typically required for making the data available to the batch input program in the SAP System.

-

-


(4) ANALYZING SAP TRANSACTIONS:

If you are creating your own batch input procedure, then you will need to analyze the SAP transaction(s) with which the batch input data is to be entered into the SAP System.

The purpose of the analysis is to gather the following information:

• the transaction code, if you do not already know it

• which fields require input

• which fields you can allow to default to standard values

• the names, types, and lengths of the fields that are used by a transaction

• the identifiers of the functions that you will need to call to have the transaction process the batch input data.

figure(11).

Collecting Transaction Data

To analyze a transaction, do the following:

1. Start the transaction by menu or by entering the transaction code in the command field.

You can determine the transaction name by choosing System --> Status.

2. Step through the transaction, entering the data and performing the functions that will be required for processing your batch input data.

3. On each screen, note the program name and screen (dynpro) number.

Display these by choosing System --> Status. The relevant fields are Program (dynpro) and Dynpro number.

If pop-up windows occur during execution, you can get the program name and screen number by pressing F1 on any field or button on the screen. The Technical info pop-up shows not only the field information but also the program and screen.

4. For each field, check box, and radio button on each screen, press F1 (help) and then choose Technical info.

Note the following information:

- The field name for batch input, which you'll find in its own box.

- The length and data type of the field. You can display this information by double- clicking on the Data element field.

5. Find out the identification code for each function (button or menu) that you must execute to process the batch input data.

Put the cursor on the button or menu entry while holding down the left mouse button. Then press F1. In the pop-up window that follows, choose Technical info and note the code that is shown in the Function field.

You can also run any function that is assigned to a function key by way of the function key number. To display the list of available function keys, click on the right mouse button. Note the key number that is assigned to the functions you want to run.

figure(12).

Getting Screen and Field Information in the Transaction Interface

Using the Screen Painter and Menu Painter to Get Field and Function Info

You can also obtain field and function information from the screen and menu definitions in the ABAP/4 screen painter and menu painter. For example, you can quickly display field information in the screen painter by displaying the screen in the Fullscreen editor and using the Attribs. for 1 field button for each field. The illustration below shows an example.

figure(13).

Getting Field Information in the Screen Painter

Similarly, you can get function and menu codes from the CUA definition of a screen in the menu painter.

See the ABAP/4 Development Workbench documentation for more information on using these tools.

-

-


(5) GENERATING AN SAP DATA STRUCTURE:

You can use the ABAP/4 Dictionary to generate data structures for SAP tables in any of the following programming languages:

• Cobol

• PL/1

• C

You can then incorporate these data structures in your data conversion program.

For most of the standard SAP batch input programs, SAP has also provided special data structure identifiers. With such an identifier, you can generate a listing of all of the table fields that are required by the corresponding batch input program. You do not need to find out which tables are required for the batch input program and generate their structures individually. If you are creating your own batch input procedure, you may be able to use the standard field listings as well.

The names of the special data structure identifiers are documented in the SAP Customizing system. For information on finding the relevant documentation, please see Batch Input Concepts(1).

Data Transfer Programs in ABAP/4

If your data transfer program is written in ABAP/4, you can include data structures of tables in your program with the TABLES instruction. The structure is then read directly from the ABAP/4 Dictionary.

In this case, you cannot use the special data structure identifiers provided by the SAP applications. The identifier names are not recognized by the TABLES instruction. Instead, you can find the required table names by checking the transactions that your batch input procedure will be using to enter data. Or you can find the table names in the listings generated by the special identifiers.

The diagram below shows the structures of transfer programs in ABAP/4 and as external programs written in other languages.

figure(14).

Including Table Structures in Transfer Programs: ABAP/4 and Other Languages

Procedure

To generate a data structure, do the following:

1. Choose Tools --> ABAP/4 Workbench and then ABAP/4 Dictionary.

2. In the ABAP/4 Dictionary, select Environment --> Generate table description.

With this function, you can generate the structures of one or a group of SAP tables in programming code. You can then add this code to your data transfer program.

3. Specify the programming language in which the structure should be generated and identify the tables to be included.

If you wish to use a special structure identifier for a standard SAP batch input report, then enter the identifier in the Key in TSRCG field. Example: The identifier AM-ANLA generates the data structure required for data transfers for the asset management application.

4. The system displays the data structure in list form, as in this example in PL/1 from the asset management application (AM-ANLA):

******************************************************************

  • MEMBER GENERATED FROM SAP DATA DICTIONARY *

  • T A B L E BALTD *

  • DATE: 08.12.1995 TIME: 17:47:16 *

  • PLEASE DO NOT CHANGE MANUALLY *

******************************************************************

*

01 BALTD.

*

  • Client (Old Assets Data Takeover AM)

05 MANDT PIC X(3)

VALUE SPACE.

  • Company code

05 BUKRS PIC X(4)

VALUE SPACE.

  • Asset class

05 ANLKL PIC X(8)

VALUE SPACE.

Choose System --> List --> Save --> File to download the data structure to your workstation or PC.

-

-


(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 data to the requirements of the SAP System.

figure(15).

Converting Data from Old Format to SAP Format

Your program must format batch input values just as an on-line user would when typing 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 the 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 contains either:

• a value; or

• a special NODATA marker, which indicates that the no batch input data is required for the field.

If you are writing your own data transfer program, you should therefore initialize all of the fields in your batch input data structure with the NODATA character. 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.

figure(16).

If a batch input program finds NODATA in a field, then the program allows the field to default to its standard value in the SAP transaction that contains the field.

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: '.

-

-


(8) 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 SAP Systems, you may be able to use RFC or CPI-C to process data directly in the target 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 batch 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 generated the data structure defined for the batch input program. For more information, see Generating an SAP Data Structure(5).

You'll find sample code for reading from and writing to a sequential file in Sample Program: Data Transfer(9) .

-

-


(9) SAMPLE PROGRAM: DATA TRANSFER:

The following ABAP/4 program demonstrates the data transfer process. The program does the following:

• reads customer address data from a sequential file

• checks the data for unacceptable records

• performs conversions on the data

• writes the data back out to a sequential file using the format required by the SAP standard batch input program Batch Input Interface for Customers (ABAP/4 program RFBIDE00).

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 .

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.

-

-


(10) WRITING A BATCH INPUT PROGRAM: PROCEDURE IN OVERVIEW:

In general, you can transfer data from an existing system into the SAP System with pre-defined batch input programs, delivered with the SAP System.

In some cases, however, you will need to write your own batch input program. For example, the standard SAP batch input programs in an application may not have foreseen the data transfer requirement you have, or you may wish to customize the standard data transfer procedure.

To write your own batch input program, you'll need to do the following:

1. Analyze the transaction(s) that you will use to process your batch input data.

You may have already done this when you wrote your data transfer program. Please see Writing a Data Transfer Program(3) and Analyzing SAP Transactions(4) for more information.

2. Decide on the batch-input method that you wish to use.

"Classical" batch input -- by way of a batch input session -- is more comfortable. Restart-capability and detailed logging are supported by the batch input management transaction for batch input sessions.

Batch input by way of CALL TRANSACTION USING offers faster processing if you need it to get your batch input done in the time slot that is available for it. CALL TRANSACTION USING offers, however, less support for error recovery and management of batch input.

For detailed information, please see Selecting a Batch-Input Method(11) .

3. Write the batch input program.

Your program will need to do the following:

- read data in, often from a sequential file that has been exported from another system or prepared by a data transfer program

- if necessary, perform data conversions or error-checking

- prepare the data for batch input processing by storing the data in the batch input data structure, BDCDATA.

- generate a batch input session for classical batch input, or process the data directly with CALL TRANSACTION USING.

You'll find information on programming techniques for batch input programs in the following topics, as well as a sample program.

-

-


(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.

figure(17).

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.

-

-


(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. Build 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-DYNPRO.

'X' TO BDCDAT-DYNBEGIN.

APPEND BDCDAT.

ENDFORM.

-

-


b) Identifying a Screen:

The first record for each screen must contain information that identifies the screen: program name, screen name and a start-of-screen indicator. You record this information in the PROGRAM, DYNPRO, and DYNBEGIN fields of the BDCDATA structure.

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 receive 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 target 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 function key number in the command field of an SAP session. You use the FNAM and FVAL 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. This name is constant and always identifies the command field.

This sample record would execute the save function. It uses the function key assignment 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 with the = character.

Example:

BDCDATA-FNAM = 'BDC_OKCODE'.

BDCDATA-FVAL = '=UPDA'.

-

-


e)Entering Values in Loop Fields

Some screen fields need multiple values, one on each line. To provide input to one of these loop fields, you must use an explicit line index :

Example:

BDCDATA-FNAM = 'fieldx(5)'.

BDCDATA-FVAL = 'value'.

The line index (in the example: (5), line 5) indicates in which loop line on the screen values are to appear.

-

-


f)Positioning the Cursor:

To position the cursor on a particular field, you must use the special cursor field:

Example:

BDCDATA-FNAM = 'BDC_CURSOR'.

BDCDATA-FVAL = 'fieldx'.

To position the cursor on a loop field, you must use again an index:

Example:

BDCDATA-FNAM = 'BDC_CURSOR'.

BDCDATA-FVAL = 'fieldy(5)'.

-

-


g)Ending a Transaction:

You can successfully complete processing of a transaction in batch input in either of two ways:

• leave the transaction and return to the SAP main menu.

• trigger an update of the database.

figure(18).

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 transaction:

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 enter 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 your batch input sessions cannot be run quickly enough. For more information on choosing the best batch input method, see Selecting a Batch-Input Method(11) .

figure(19).

Creating, Filling, and Closing a Batch Input Session

To create a session, program the following procedure using the following BDC_ function 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 be 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 Program(22) for an example of how the function modules are used.

-

-


(15) CREATING A SESSION WITH BDC_OPEN_GROUP :

Use the BDC_OPEN_GROUP function module to do the following create a new session. Once you have created a session, then you can insert batch input data into it with BDC_INSERT.

You cannot re-open a session that already exists and has been closed. If you call BDC_OPEN_GROUP with the name of an existing session, then an additional session with the same name is created.

A batch input program may have only one session open at a time. Before opening a session, make sure that any sessions that the program closes any sessions that it previously had opened.

figure(20).

BDC_OPEN_GROUP takes the following EXPORTING parameters:

• CLIENT

Client in which the session is to be processed.

Default: If you don't provide a value for this parameter, the default is the client under which the batch input program runs when the session is created.

• 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 that you specify. Only a system administrator with the LOCK authorization for the authorization object Batch Input Authorizations can unlock and run a session before this date.

Format: YYYYMMDD (8 digits).

Default: No lock date, session can be processed immediately. A lock date is optional.

• KEEP

Retain session after successful processing. Set this option to the value X to have a session kept after it has been successfully processed. A session that is kept 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 used 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 to be executed in a session. Otherwise, transactions will be terminated with "no authorization" errors.

The user can be of type dialog or background. Dialog users are normal interactive users in the SAP System. Background users are user master records that are specially defined for providing authorizations for background processing jobs.

-

-


(16) ADDING DATA TO A SESSION: BDC_INSERT :

Use the BDC_INSERT function module to add a transaction to a batch input session. You specify the transaction that is to be started in the call to BDC_INSERT. You must provide a BDCDATA structure that contains all of the data required to process the transaction completely.

figure(21).

BDC_INSERT takes the following parameters:

• TCODE

The code of the transaction that is to be run.

For help in finding the transaction code of a function, see Analyzing SAP Transactions(4) .

TCODE is an EXPORTING parameter in the function module.

• POST_LOCAL

Parameter to update data locally. If POST_LOCAL = 'X', data will be updated locally.

(refer to the keyword documentation of SET UPDATE TASK LOCAL for more information)

• DYNPROTAB

The BDCDATA structure that contains the data that is to be processed by the transaction.

DYNPROTAB is a tables parameter in the function module.

For information on filling the structure, see Programming Techniques: Entering Data and Executing Functions(13).

-

-


(17) CLOSING A SESSION: BDC_CLOSE_GROUP :

Use the BDC_CLOSE_GROUP function module to close a session after you have inserted all of your batch input data into it. Once a session is closed, it can be processed.

figure(22).

BDC_CLOSE_GROUP needs no parameters. It automatically closes the session that is currently open in your program.

You must close a session before you can open another session from the same program.

You cannot re-open a session once it has been closed. A new call to BDC_OPEN_GROUP with the same session name creates a new session with the same name.

-

-


(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) .

figure(23).

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

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. There is no restart capability for transactions that contain errors or produce update failures.

You can handle incorrect transactions by using update mode S (synchronous updating) and checking the return code from CALL TRANSACTION USING. If the return code is anything other than 0, then you should do the following:

• write out or save the message table

• use the BDCDATA table that you generated for the CALL TRANSACTION USING to generate a batch input session for the faulty transaction. You can then analyze the faulty transaction and correct the error using the tools provided in the batch input management facility.

-

-


(20) USING CALL DIALOG WITH BATCH INPUT:

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

1. For the screens you want processed, fill all desired fields.

2. Use a CALL DIALOG statement to call the dialog module and to pass it to the BDCDATA table.

figure(24).

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'.

-

-


(21) DIRECT INPUT:

To enhance the batch input procedure, the system offers the direct input technique, especially for transferring large amounts of data. In contrast to batch input, this technique does not create sessions, but stores the data directly. It does not process screens. To enter the data into the corresponding database tables directly, the system calls a number of function modules that execute any necessary checks. In case of errors, the direct input technique provides a restart mechanism. However, to be able to activate the restart mechnism, direct input programs must be executed in the background only. To maintain and start these programs, use program RBMVSHOW or the transaction BMV0.

Examples for direct input programs are:

Program Application

-

-


-

-


RFBIBL00 FI

RMDATIND MM

RVAFSS00 SD

RAALTD11 AM

RKEVEXT0 CO-PA

For more information, see the respective program documentation.

-

-


(22) SAMPLE BATCH INPUT PROGRAM:

The following program demonstrates both the creation of sessions, and the use of CALL TRANSACTION USING.

REPORT RJBDC200 LINE-SIZE 120.

*----


*

  • Add a line in a report *

*----


*

PARAMETERS : BDCTYPE TYPE C DEFAULT 'M',

" M = Create batch input session

" T = Call transaction

"----

-


*

" Only used for batch input sessions *

"----

-


*

GROUP(12) TYPE C DEFAULT 'BDCTEST',

" group name of session

USER(12) TYPE C DEFAULT SY-UNAME,

" user name for starting the

" session in background

KEEP(1) TYPE C,

" ' ' = delete session after processing

" 'X' = keep session after successful

" processing

HOLDDATE LIKE SY-DATUM,

"----

-


*

" Only used for call transaction *

"----

-


*

DMODE TYPE C DEFAULT 'A'.

" Display mode

" 'A' = display all screens

" 'E' = display only errors

" 'N' = display nothing

*----


*

  • Batch input data for a single transaction *

*----


*

DATA: BEGIN OF BDCDATA OCCURS 0.

INCLUDE STRUCTURE BDCDATA.

DATA: END OF BDCDATA.

DATA: BEGIN OF MESSTAB OCCURS 0.

INCLUDE STRUCTURE BDCMSGCOLL.

DATA: END OF MESSTAB.

*----


*

  • Generate batch input *

  • *

*----


*

CASE BDCTYPE.

WHEN 'M'.

PERFORM CREATE_GROUP.

EXIT.

WHEN 'T'.

PERFORM CALL_TRANSACTION.

EXIT.

ENDCASE.

*----


*

  • *

  • Create batch input session *

  • *

*----


*

FORM CREATE_GROUP.

WRITE: / 'Create group'.

"----

-


*

" Open batch input group *

"----

-


*

CALL FUNCTION 'BDC_OPEN_GROUP'

EXPORTING

CLIENT = SY-MANDT

GROUP = GROUP

USER = USER

KEEP = KEEP

HOLDDATE = HOLDDATE.

WRITE: / 'BDC_OPEN_GROUP rc ='(999), SY-SUBRC.

"----

-


*

" Insert first transaction *

"----

-


*

PERFORM GEN_BDC_DATA.

CALL FUNCTION 'BDC_INSERT'

EXPORTING

TCODE = 'SE38'

TABLES

DYNPROTAB = BDCDATA.

WRITE: / 'BDC_INSERT rc ='(999), SY-SUBRC.

"----

-


*

" Insert second transaction *

"----

-


*

PERFORM GEN_BDC_DATA.

CALL FUNCTION 'BDC_INSERT'

EXPORTING

TCODE = 'SE38'

TABLES

DYNPROTAB = BDCDATA.

WRITE: / 'BDC_INSERT rc ='(999), SY-SUBRC.

"----

-


*

" Close batch input group *

"----

-


*

CALL FUNCTION 'BDC_CLOSE_GROUP'.

WRITE: / 'BDC_CLOSE_GROUP rc ='(999), SY-SUBRC.

ENDFORM. " End CREATE_GROUP

*----


*

  • *

  • Call Transaction Using *

  • *

*----


*

FORM CALL_TRANSACTION.

WRITE: / 'Call Transaction RC ='(999).

PERFORM GEN_BDC_DATA.

CALL TRANSACTION 'SE38' USING BDCDATA MODE DMODE MESSAGES INTO

MESSTAB.

WRITE: SY-SUBRC, SY-MSGTY, SY-MSGID, SY-MSGNO, SY-MSGV1.

WRITE: / ' ', SY-MSGV2.

WRITE: / ' ', SY-MSGV3.

WRITE: / ' ', SY-MSGV4.

ENDFORM. " End CALL_TRANSACTION

*----


*

  • *

  • Create batch input data for *

  • transaction SE38 *

  • *

*----


*

FORM GEN_BDC_DATA.

DATA: LINE LIKE BDCDATA-FVAL.

REFRESH BDCDATA.

*----


*

  • First screen of transaction *

*----


*

PERFORM BDC_DYNPRO USING 'SAPMS38M' '0100'.

PERFORM BDC_FIELD USING 'RS38M-PROGRAMM' 'RJBDC999'.

PERFORM BDC_FIELD USING 'bdc_cursor' 'chap'.

PERFORM BDC_FIELD USING 'BDC_OKCODE' '/00'.

*----


*

  • In editor, go to bottom of report *

*----


*

PERFORM BDC_DYNPRO USING 'SAPMSEDT' '2310'.

PERFORM BDC_FIELD USING 'RSTXP-TDCOMMLINE' 'BOT'.

*----


*

  • Insert line into report *

*----


-


*

PERFORM BDC_DYNPRO USING 'SAPMSEDT' '2310'.

PERFORM BDC_FIELD USING 'RSTXP-TDLINECOM(17)' 'I'.

*----


*

  • Go to bottom of report again *

*----


*

PERFORM BDC_DYNPRO USING 'SAPMSEDT' '2310'.

PERFORM BDC_FIELD USING 'RSTXP-TDCOMMLINE' 'BOT'.

*----


*

  • Modify line in report and save report *

  • (Enter f11 in ok-code) *

*----


*

PERFORM BDC_DYNPRO USING 'SAPMSEDT' '2310'.

LINE = 'Batchinput'.

LINE+20 = SY-DATUM.

LINE+30 = SY-UZEIT.

PERFORM BDC_FIELD USING 'RSTXP-TDLINE(17)' LINE.

PERFORM BDC_FIELD USING 'BDC_OKCODE' '/11'.

*----


*

  • Leave the editor (enter f3 in ok-code) *

*----


*

PERFORM BDC_DYNPRO USING 'SAPMSEDT' '2310'.

PERFORM BDC_FIELD USING 'BDC_OKCODE' '/3'.

*----


*

  • Leave transaction se38 (enter f15 in *

  • ok-code) *

*----


*

PERFORM BDC_DYNPRO USING 'SAPMS38M' '0100'.

PERFORM BDC_FIELD USING 'BDC_OKCODE' '/15'.

ENDFORM. "End GEN_BDC_DATA

*----


*

  • *

  • In the batch input data, start a new screen *

  • *

*----


*

FORM BDC_DYNPRO USING PROGRAM DYNPRO.

CLEAR BDCDATA.

BDCDATA-PROGRAM = PROGRAM.

BDCDATA-DYNPRO = DYNPRO.

BDCDATA-DYNBEGIN = 'X'.

APPEND BDCDATA.

ENDFORM. "End BDC_DYNPRO

*----


*

  • *

  • In the batch input data, insert a field *

  • *

*----


*

FORM BDC_FIELD USING FNAM FVAL.

CLEAR BDCDATA.

BDCDATA-FNAM = FNAM.

BDCDATA-FVAL = FVAL.

APPEND BDCDATA.

ENDFORM.

-

-


(23) BATCH INPUT RECORDING FOR TRANSACTION RUNS:

This section tells you how to use the recording functions of batch input.

For more information, refer to these sections:

a)Recording features

b)Sample program

c)Special recording features

-

-


a)Recording features

The recording function offers the following features:

• recording transaction runs,

• creating batch input sessions from the recorded transaction run,

• generating a batch input program from the recorded data.

Recording transaction runs

A batch input recording consists of a sequence of transactions with the screens processed. A screen (program name, screen name) contains the modified fields (field name, field value), the executed user command (BDC_OKCODE) and the cursor position (BDC_CURSOR).

To start the recording function, go to the batch input initial screen and choose Record or directly call transaction SHDB.

The system stores each recording under a name of up to 12 characters that you can choose at will. You must specify this name when starting the recording. The following special characters are not allowed: . , ( ) ' " = Ä Ö Ü ß.

The recording function offers an overview of all exising recordings. To display the overview, click on Overview. You can limit the selection by entering a date interval.

To create a recording, specify the recording name and choose Create. In the subsequent dialog box, enter the name of the transaction you want to record. Then execute the transaction and enter the required values in the screen fields.

After the end of the transaction, the system displays the processed screens (module pool, screen number), the changed fields (field name, field value), the executed user commands (BDC_OKCODE). and the cursor position (BDC_CURSOR) in a hierarchical list. Choose Copy transaction to copy the executed transaction run into the recording. Choose Next transaction if you want to record another transaction run with a different transaction.

After recording all desired transactions, save the recording.

Create batch input sessions from the recorded transaction run

From within the recording overview, choose Create session to create a batch input session with the data of the recorded transaction. You can then process this session as usual.

Generate a batch input program from the recorded data

Apart from creating a session, you can also generate an ABAP/4 batch input program from within the recording overview. In this case, select the desired recording and specify the name of the program you want to generate. Then maintain the program attributes and the entry in the object list.

The generated program contains the entire coding required to create a batch input session. Thus you can leave out the transaction execution and the determination of the module pool name, the screen numbers, the field names, and the function codes.

You may need to modify this program only slightly, if you want to use it, for example, to read the data to be transferred from a sequential dataset.

-

-


b)sample program

This example shows a program that was generated to transfer data using transaction TFCA. This program changes the plane type (SFLIGHT-PLANETYPE) for the airline (SFLIGHT-CARRID) 'LH' and the connection ID (SFLIGHT-CONNID) '2402'.

report khtfca01.

include bdcrecxx.

start-of-selection.

perform open_group.

perform bdc_dynpro using 'SAPMTFCA' '0100'.

perform bdc_field using 'BDC_OKCODE' 'UPDA'.

perform bdc_field using 'BDC_CURSOR' 'SFLIGHT-CARRID'.

perform bdc_field using 'SFLIGHT-CARRID' 'LH'.

perform bdc_field using 'SFLIGHT-CONNID' '2402'.

perform bdc_dynpro using 'SAPMTFCA' '0200'.

perform bdc_field using 'BDC_OKCODE' 'SAVE'.

perform bdc_field using 'BDC_CURSOR' 'SFLIGHT-PLANETYPE(02)'.

perform bdc_field using 'SFLIGHT-PLANETYPE(02)' 'A321'.

perform bdc_transaction using 'TFCA'.

perform close_group.

The subroutines called are part of the include program BDCRECXX. They call the function modules required for creating a batch input session and they fill the BDC table. In addition, this include parameter contains statements for the selection screen layout.

-

-


c)special recording features:

The following data is not recorded:

• F1, F4, and customer-related F1 and F4 functions,

• all functions of the menus System and Help,

• values of the standard variant,

• error dialogs and warning dialogs,

• scrolling via the scrollbar (use F21 to F24 instead).

COMMIT WORK indicates the successful end of the transaction and, thus, of the recording.

LEAVE TO TRANSACTION cannot be processed in batch input and, therefore, ends the recording.

**********************************************************************

********************************************************************

Please undestand the basic concept of the BDC..and Let me know. So that, u can get veru good knowledge abt them.

Once, u got basic idea...then let me know...I will also provide you with some programs on Calll Transcation and session method.

Also let me know ur personel email address...I will send u few doc's

Hope the above information was helpful....

Reward Points if helpful

Regards,

Krishna Chaitanya

3 REPLIES 3

Former Member
0 Kudos
201

Hello Abhinab Mishra,

I am providing you with Url's.

Go through them...They will be useful....

http://www.sapbrainsonline.com/TUTORIALS/TECHNICAL/BDC_tutorial.html

http://abap-gallery.blogspot.com/2007/08/bdc-batch-data-communication-tutorial.html

I am also providing BDC Documentation for u, plz go through it. This is the bst info that you can get. So first go through it very carefully.

**********************************

BDC Documentation

***********************************************************

1) Batch Input Concepts

2) Transferring Data: Batch Input Procedure in Overview

DATA TRANSFER PROGRAMS

3) Writing a Data Transfer Program

4) Analyzing SAP Transactions

5) Generating an SAP Data Structure

6) Data Conversions

7) Initializing an SAP Data Structure

😎 Generating a Sequential File

9) Sample Program: Data Transfer

BATCH INPUT PROGRAMS

10) Writing a Batch Input Program: Procedure in Overview

11) Selecting a Batch-Input Method

12) Using the Batch Input Data Structure

13) Programming Techniques: Entering Data and Executing Functions

CREATING SESSIONS

14) Creating Batch Input Sessions

15) Creating a Session with BDC_OPEN_GROUP

16) Adding Data to a Session: BDC_INSERT

17) Closing a Session: BDC_CLOSE_GROUP

18) Processing Batch Input Sessions

CALL TRANSACTION USING

19) Using CALL TRANSACTION USING for Batch Input

20) Using CALL DIALOG with Batch Input

GENERAL INFORMATION AND SAMPLE PROGRAM

21) Direct Input

22) Sample Batch Input Program

23) Batch Input recording for transaction runs

24) Batch Input Authorizations

(1) BATCH INPUT CONCEPTS:

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 called "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 available in electronic form.

The batch input technique offers these advantages for transferring data:

• No manual interaction is required during data transfer. If the data to be transferred is already available in electronic form (on a tape, for example), then you can enter the data automatically into the SAP System using batch input.

• Batch input ensures data integrity. Batch input enters data into the SAP System using the same transactions that interactive users do. Batch input data is therefore submitted to all of the checks and controls that apply to data entered by normal interactive means.

The batch input methods.

There are several ways to process batch input data in the SAP System.

FIGURE(1)

Batch input processing methods.

The first processing method could be called "classical batch input." In it, an ABAP/4 program reads the external data that is to be entered in the SAP System and stores the data in a "batch-input session." A session stores the actions that are required to enter your data using normal SAP transactions.

When the program has finished generating the session, you can run the session to execute the SAP transactions in it. You can either explicitly start and monitor a session with the batch-input management function (System --> Services --> Batch input) or have the session run in the background processing system.

This method uses the function modules BDC_OPEN, BDC_INSERT, and BDC_CLOSE to generate sessions.

In the second method, your program uses the ABAP/4 CALL TRANSACTION USING statement to run an SAP transaction. Batch-input data does not have to be deposited in a session for later processing. Instead, the entire batch-input process takes place inline in your program.

There is a third batch-input method using the ABAP/4 CALL DIALOG statement. However, SAP recommends against using this method unless necessary. The CALL DIALOG method is now outdated and is more complex and less comfortable to use than the other techniques.

All three batch-input methods use a common data structure for holding the instructions and data for SAP transactions. This structure is defined as structure BDCDATA in the ABAP/4 Dictionary.

For help in selecting the method to use, please see SELECTING A BATCH-INPUT METHOS (11).

Typical uses of batch input.

Uses of batch input include the following:

• transferring data from another system when you install your SAP System

• regularly transferring data that is captured by a non-SAP system in your company into the SAP System. Assume, for example, that data collection in some areas of your company is still performed by a non-SAP system. You can still consolidate all of your data in the SAP System by exporting the data from the other system and reading it into the SAP System with batch input.

You can also use batch input to transfer data between two R/3 Systems. However, there are more direct methods for doing this, such as RFC (remote function calls).

application support for batch-input.

The SAP applications provide pre-programmed support for batch input transfers for many of SAP's business objects.

To implement one of the supported data transfers, you must often write the program that exports the data from your non-SAP System. This program, known as a "data transfer" program must map the data from the external system into the data structure required by the SAP batch input program.

Should you wish to write a transfer program that executes outside the SAP System, then the SAP applications provide definitions of the required data formats for the exports. From these definitions, you can generate code for the data structures to include in your export program. You can also write such programs in ABAP/4, which lets you take advantage of the comfort and conveniences of the SAP Development Workbench.

Once you have exported the data, you can then use a standard, pre-programmed SAP report to import the data. This program uses one of the batch input methods to process the data and add it to the SAP System.

You can find information on pre-defined batch-input programs in the SAP Customizing System. Choose Tools --> Customizing. Then display either your Enterprise IMG (Implementation Guide) projects or the SAP standard IMG. In the project display, use the Expand function to display all nodes in the project. You can then search for relevant topics with the keywords batch input and transfer.

(2) TRANSFERING DATA : BATCH INPUT PROCEDURE IN OVERVIEW.

Transferring data with batch input requires the steps shown in the illustration and list below.

Note that SAP standard batch-input programs take care of several of these steps for you. For more information, please see BATCH INPUT CONCEPTS (1).

FIGURE(2).

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 structure.

Method: You'll need to determine the structure of the data that is to be transferred 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 SAP 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 generate 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 function 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 determine 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 information, 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 PROGRAM(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 will import

the file (step 6).

- Reading and interpreting the file is much easier if you write it in ASCII or EBCDIC

(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 PROGRAM : 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 statement

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 TRANSACTION 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 MANAGING BATCH-INPUT SESSIONS(B).

8. Correct and re-process erroneous data.

Method: You can use the batch-input management function to process erroneous transactions interactively. You can correct data during this interactive processing.

A.GENERATING A BATCH-INPUT SESSION.

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 enter 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 your batch input sessions cannot be run quickly enough. For more information on choosing the best batch input method, see SELECTING A BATCH-INPUT METHOD(11).

FIGURE(3).

Creating, Filling, and Closing a Batch Input Session

To create a session, program the following procedure using the following BDC_ function 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 be

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 PROGRAM(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 input is typically used to transfer data from non-R/3 Systems to R/3 Systems or to transfer 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 following:

• Start batch input sessions to enter data into an R/3 System.

For debugging sessions that contain errors, the batch input system offers two modes for

running sessions interactively.

• Schedule the background program that automatically submits sessions for processing 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 session. 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 field.

• Display the log produced by a batch input session.

Functionally:

figure(4).

For help in generating sessions, please see the Basis Programming Interfaces manual.

b) Batch Input: Concepts:

Processing Sessions

A batch input session is a set of one or more calls to transactions along with the data to be processed by the transactions. The system normally executes the transactions in a session non-interactively, allowing rapid entry of bulk data into an R/3 System.

A session simulates on-line entry of transactions and data. It calls transactions 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, batch input sessions are subject to the user-based authorization checking that is performed by the system.

figure(5).

Generating Sessions

To transfer data with batch-input, the system that is sending the data uses a data transfer interface provided by an R/3 application program in the receiving system. The interface program in the application then produces a batch input session.

The interface program in an application is an ABAP/4 program that sets up the transaction calls and data that make up a session. If the batch input session contains data from an external source, the program also reformats the data to meet the 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, please see the documentation of the R/3 applications.

Authorizations

When a session is generated, a client and user are associated with it. If the session is run in background-processing mode, the system uses this user for authorization 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 authorizations. 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 that periodically checks for and starts any sessions that have not yet been run. Running sessions interactively is usually reserved for testing sessions or correcting sessions.

To start batch input sessions automatically, schedule the ABAP/4 program RSBDCSUB 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 input 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 --> Service -->

Batch input. On the main menu, you can select sessions using any or all of the following 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, you 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 remain 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 session 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.

figure(6).

Possible statuses are as follows:

• not yet processed

The Tran. and Screen fields in the display show how many transactions and screens,

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 processed.

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 information, please see Correcting a Session(f).

• processed

For further information on a session that has been successfully run, you can display the

log generated by the session. All completed sessions generate a log. You cannot run a

completed session a second time.

Only sessions that were generated with the KEEP option are held in the queue after

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 generation of a

session. If you suspect that a session has been interrupted, please see 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 execution of a

session. If you suspect that a session has been interrupted, please see 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 enters data into an R/3 System.

To start a session, select Session ® Overview from the main batch input screen. Then mark the session(s) that you wish to start and select Session ® Process or ® Process 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 status Incorrect. Sessions with the status Processed cannot be run again.

Run Modes

There are three ways to run a session:

figure(7).

•Process/foreground: You can interactively correct transactions that contained errors and step through transactions that have not yet been executed.

•Display errors only: This mode is like Process/foreground except that transactions that have not yet been run and which do not contain errors are run non-interactively.

If an error occurs, processing stops and the screen upon which the error occurred is displayed.

•Process in Batch: Use batch mode to schedule a session for immediate processing in the batch facility.

You receive control of your terminal again as soon as the session has been passed to the batch system.

Note that your session is automatically released for processing in the background processing system. You need not explicitly release the session for processing.

A completed session is handled in one of three ways:

- The system deletes a session from the queue when it has been successfully completed. You can check on the outcome of the session by displaying the session log file.

- If the KEEP option was set when the session was generated, then the system leaves a session in the queue, even if it was run successfully. The status is changed to Processed.

You cannot run the session a second time. You must manually delete it when you no longer need it.

- If a transaction in the session contained an error, the incorrect transaction is aborted. All other transactions are completed. The session remains in the queue and is held in the Errors section of the list. You can correct the session in one of the interactive modes and run it to completion.

A transaction contains an error if it issues a message of type E (error) or type A (abnormal termination). Other messages are ignored and do not affect the execution of a session..

A session also is held in the queue in the Errors list if the session was ended with the /bend OK code. Please see Correcting a Session(f).

For more information on correcting sessions with the display-all or error-display mode, please see Correcting a Session(f).

-

-


f) Correcting a Session:

When a session is run in background-processing mode, the system marks transactions that contain errors as incorrect. All other transactions in the session are completed. 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 (error) 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 the following advantages:

- The system skips transactions that were successfully completed. Only incorrect transactions or transactions that have not been executed are run.

- You can change inputs and add missing screens interactively as incorrect transactions 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 was. 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 generated the session and regenerate the session.

You must ensure that the new session does not include transactions that were successfully completed. Otherwise, the updates made by the transactions will be performed again.

Using Display-All Mode

When you use display-all mode to re-start a session that contains an incorrect transaction, the system skips to the first screen of the incorrect transaction. Completed transactions are not re-executed.

options when you run a session interactively.

figure(8).

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 the 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 omitted from the session.

To resume executing the session, return to the screen that was expected by the session.

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 OK 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 list.

You can use /bend when testing sessions. For example, you may wish to run the first two transactions of a large session in display-all mode to make sure that the session has been generated correctly.

If the transactions are correct, you can then terminate the run with /bend and then submit the session for background execution. The transactions that have already been run will not be run again.

Deleting a Transaction

You can delete a transaction from a session during interactive execution by entering 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.

figure(9).

-

-


g) Deleting Sessions:

You can delete any session from the session queue. Deleting a session discards the 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 are completed. However, if a session was generated with the KEEP option, it is kept in the session queue. You must explicitly delete the session when you no longer need it.

A session is also kept in the queue if it contained an error or was broken off with 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 recorded 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 entering a space as the lock date.

-

-


i) Releasing and Restarting an Interrupted Session:

If a system problem occurs while a session is being generated or is being run, the session is terminated abnormally. Typical causes of an abnormal termination might include shutdown of the R/3 System while a session is running or termination of a SAPGUI presentation process while a session is being run interactively.

In the session queue, a session that was terminated while it was being generated remains in the Being generated section of the list. A session that was terminated while it was running remains in the Active list.

You can recognize that a session has terminated abnormally because the status of the session does not change. If, for example, you find a session that was run the previous night still in the Active list, then it is likely that the session was interrupted.

If a session was to run in the background, you can check the status of the session's job in the background processing system. If the session was aborted, then the background job log contains the reason for the abnormal termination.

Before you can restart (or start) a session that terminated abnormally, you must release it. Releasing the aborted session sets its status to Being processed. Reset the status by marking the session or sessions and selecting Edit --> Release.

You can safely restart a session that was interrupted while it was being run. When you restart the session, all transactions that were successfully completed before the problem occurred will be skipped. The transaction that was executing when the problem occurred will be re-executed.

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 running.

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.

-

-


j) Displaying Queue Management Information:

Should you ever need to review the internal queue-management information on a particular entry, you can display this information by marking an entry and selecting Analysis --> Queue.

Not all of the queue management fields displayed are used by the batch input system; the queue management functions are used by other queues in the system as well. The fields that are used by the batch input system are as follows:

• Client: The client in which a session is to run.

• Groupid: The session name.

• QID: The internal ID of a session. The ID is used for queue management with System --> Services --> Queue.

• QSTATE: A character indicating the status of the batch input session.

• QERASE: If marked, indicates that the KEEP option is set. If KEEP is set, the system does not delete the session after it is successfully run.

• USERID: User to be used for authorization testing if a session is submitted for background execution.

-

-


k) Displaying Session Logs:

Every batch input session generates a log when it runs. To display a log, you can either:

• select Session --> Logs from the batch input main menu; or

• put the cursor on a particular session in the session queue and select Goto --> Log.

A session log contains any error messages issued by transactions in the session. It also includes batch input error messages reporting any problems in running transactions, together with the transaction and screen at which the problem occurred. Finally, a log contains a set of summary statistics.

-

-


l) Reorganizing the Log File:

You should periodically use the ABAP/4 program RSBDCREO to reorganize the batch input log file. You can run RSBDCREO in the background or interactively.

Running the program reduces the size of the log file, BI, in the shared R/3 directory "global" in the host system to the minimum possible size. Deleting a session marks a session log for deletion, but the storage held for the log is returned to the host only by a reorganization.

The program will delete a log only if the session to which the log belongs has been deleted.

-

-


m) Analyzing Sessions:

Use the analysis functions to check on the actions performed by a batch input session. The analysis functions allow you to display the transactions, screens, and data in a session.

You can use these functions before or after a session has been run.

note

Analysis of sessions that have been run is available only for sessions that contained an error or which were generated with the KEEP option. The KEEP option prevents the system from deleting a session that has been successfully run.

You can analyze a session by marking the session in the session queue and selecting Goto --> Analysis --> Session or by selecting Analysis from the session log screen.

Analysis Blocks

Reading very long sessions from the database can cause time-outs to occur. For this reason, the system reads sessions for analysis in blocks.

Blocks do not restrict your ability to display a long session. You can switch forward and backward from block to block with function keys.

A block always contains only complete transactions. A block boundary cannot fall in the middle of a transaction.

Session Summary

The first analysis screen lists the transactions and screens recorded in the session.

Screens are identified by the name of the program and the number of the screen. Statuses are identical to those of the session queue, except that transactions that were deleted with the /bdel OK code have the status Deleted.

Session Data

You can display the data entered on each screen of a session by selecting Analysis ® Data from the first analysis screen.

You can have the data presented to you in two formats:

• The first data display presents data in list format by field name.

• Alternatively, you can switch to the screen called by the session with the session data shown on it.

You can switch back and forth from one form of display to the other.

-

-


(3) WRITING A DATA TRANSFER PROGRAM:

The data transfer program is responsible for doing the following:

• Converting the data that is to be transferred into the SAP System as required by the SAP data structure or transactions that you are using.

The data structure may be generated from the standard SAP data structures (see Generating an SAP Data Structure(5)). This is required if you are working with a standard SAP batch input program. Or, if you are creating your own batch input procedure, you may have developed the data structure yourself by analyzing the SAP transactions with which the data is to be entered.

A conversion may be necessary for data type and length. The data type required by all standard SAP batch input programs is C, character data. You can find the required field lengths either in your analysis of the SAP data entry transactions or in the data structures that you generate in the ABAP/4 Dictionary.

• Exporting the data in SAP format to a sequential file. The batch input program in the SAP System reads the data in from this file.

Task Overview

The tasks involved in writing a data transfer program are shown in the diagram and list below.

figure(10).

Writing a Transfer Program

The procedure:

1. Analyze the structure of your existing data and specify the conversions that are required to fill the SAP data structures.

2. Generate the SAP data structure in code form and insert it into your program.

If the program is written in ABAP/4, you need only include the required tables in your program with the TABLES statement.

3. Initialize the SAP data structure.

4. Fill the structure with data, performing any conversions and error-checking that are required.

5. Write the sequential file that is typically required for making the data available to the batch input program in the SAP System.

-

-


(4) ANALYZING SAP TRANSACTIONS:

If you are creating your own batch input procedure, then you will need to analyze the SAP transaction(s) with which the batch input data is to be entered into the SAP System.

The purpose of the analysis is to gather the following information:

• the transaction code, if you do not already know it

• which fields require input

• which fields you can allow to default to standard values

• the names, types, and lengths of the fields that are used by a transaction

• the identifiers of the functions that you will need to call to have the transaction process the batch input data.

figure(11).

Collecting Transaction Data

To analyze a transaction, do the following:

1. Start the transaction by menu or by entering the transaction code in the command field.

You can determine the transaction name by choosing System --> Status.

2. Step through the transaction, entering the data and performing the functions that will be required for processing your batch input data.

3. On each screen, note the program name and screen (dynpro) number.

Display these by choosing System --> Status. The relevant fields are Program (dynpro) and Dynpro number.

If pop-up windows occur during execution, you can get the program name and screen number by pressing F1 on any field or button on the screen. The Technical info pop-up shows not only the field information but also the program and screen.

4. For each field, check box, and radio button on each screen, press F1 (help) and then choose Technical info.

Note the following information:

- The field name for batch input, which you'll find in its own box.

- The length and data type of the field. You can display this information by double- clicking on the Data element field.

5. Find out the identification code for each function (button or menu) that you must execute to process the batch input data.

Put the cursor on the button or menu entry while holding down the left mouse button. Then press F1. In the pop-up window that follows, choose Technical info and note the code that is shown in the Function field.

You can also run any function that is assigned to a function key by way of the function key number. To display the list of available function keys, click on the right mouse button. Note the key number that is assigned to the functions you want to run.

figure(12).

Getting Screen and Field Information in the Transaction Interface

Using the Screen Painter and Menu Painter to Get Field and Function Info

You can also obtain field and function information from the screen and menu definitions in the ABAP/4 screen painter and menu painter. For example, you can quickly display field information in the screen painter by displaying the screen in the Fullscreen editor and using the Attribs. for 1 field button for each field. The illustration below shows an example.

figure(13).

Getting Field Information in the Screen Painter

Similarly, you can get function and menu codes from the CUA definition of a screen in the menu painter.

See the ABAP/4 Development Workbench documentation for more information on using these tools.

-

-


(5) GENERATING AN SAP DATA STRUCTURE:

You can use the ABAP/4 Dictionary to generate data structures for SAP tables in any of the following programming languages:

• Cobol

• PL/1

• C

You can then incorporate these data structures in your data conversion program.

For most of the standard SAP batch input programs, SAP has also provided special data structure identifiers. With such an identifier, you can generate a listing of all of the table fields that are required by the corresponding batch input program. You do not need to find out which tables are required for the batch input program and generate their structures individually. If you are creating your own batch input procedure, you may be able to use the standard field listings as well.

The names of the special data structure identifiers are documented in the SAP Customizing system. For information on finding the relevant documentation, please see Batch Input Concepts(1).

Data Transfer Programs in ABAP/4

If your data transfer program is written in ABAP/4, you can include data structures of tables in your program with the TABLES instruction. The structure is then read directly from the ABAP/4 Dictionary.

In this case, you cannot use the special data structure identifiers provided by the SAP applications. The identifier names are not recognized by the TABLES instruction. Instead, you can find the required table names by checking the transactions that your batch input procedure will be using to enter data. Or you can find the table names in the listings generated by the special identifiers.

The diagram below shows the structures of transfer programs in ABAP/4 and as external programs written in other languages.

figure(14).

Including Table Structures in Transfer Programs: ABAP/4 and Other Languages

Procedure

To generate a data structure, do the following:

1. Choose Tools --> ABAP/4 Workbench and then ABAP/4 Dictionary.

2. In the ABAP/4 Dictionary, select Environment --> Generate table description.

With this function, you can generate the structures of one or a group of SAP tables in programming code. You can then add this code to your data transfer program.

3. Specify the programming language in which the structure should be generated and identify the tables to be included.

If you wish to use a special structure identifier for a standard SAP batch input report, then enter the identifier in the Key in TSRCG field. Example: The identifier AM-ANLA generates the data structure required for data transfers for the asset management application.

4. The system displays the data structure in list form, as in this example in PL/1 from the asset management application (AM-ANLA):

******************************************************************

  • MEMBER GENERATED FROM SAP DATA DICTIONARY *

  • T A B L E BALTD *

  • DATE: 08.12.1995 TIME: 17:47:16 *

  • PLEASE DO NOT CHANGE MANUALLY *

******************************************************************

*

01 BALTD.

*

  • Client (Old Assets Data Takeover AM)

05 MANDT PIC X(3)

VALUE SPACE.

  • Company code

05 BUKRS PIC X(4)

VALUE SPACE.

  • Asset class

05 ANLKL PIC X(8)

VALUE SPACE.

Choose System --> List --> Save --> File to download the data structure to your workstation or PC.

-

-


(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 data to the requirements of the SAP System.

figure(15).

Converting Data from Old Format to SAP Format

Your program must format batch input values just as an on-line user would when typing 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 the 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 contains either:

• a value; or

• a special NODATA marker, which indicates that the no batch input data is required for the field.

If you are writing your own data transfer program, you should therefore initialize all of the fields in your batch input data structure with the NODATA character. 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.

figure(16).

If a batch input program finds NODATA in a field, then the program allows the field to default to its standard value in the SAP transaction that contains the field.

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: '.

-

-


(8) 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 SAP Systems, you may be able to use RFC or CPI-C to process data directly in the target 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 batch 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 generated the data structure defined for the batch input program. For more information, see Generating an SAP Data Structure(5).

You'll find sample code for reading from and writing to a sequential file in Sample Program: Data Transfer(9) .

-

-


(9) SAMPLE PROGRAM: DATA TRANSFER:

The following ABAP/4 program demonstrates the data transfer process. The program does the following:

• reads customer address data from a sequential file

• checks the data for unacceptable records

• performs conversions on the data

• writes the data back out to a sequential file using the format required by the SAP standard batch input program Batch Input Interface for Customers (ABAP/4 program RFBIDE00).

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 .

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.

-

-


(10) WRITING A BATCH INPUT PROGRAM: PROCEDURE IN OVERVIEW:

In general, you can transfer data from an existing system into the SAP System with pre-defined batch input programs, delivered with the SAP System.

In some cases, however, you will need to write your own batch input program. For example, the standard SAP batch input programs in an application may not have foreseen the data transfer requirement you have, or you may wish to customize the standard data transfer procedure.

To write your own batch input program, you'll need to do the following:

1. Analyze the transaction(s) that you will use to process your batch input data.

You may have already done this when you wrote your data transfer program. Please see Writing a Data Transfer Program(3) and Analyzing SAP Transactions(4) for more information.

2. Decide on the batch-input method that you wish to use.

"Classical" batch input -- by way of a batch input session -- is more comfortable. Restart-capability and detailed logging are supported by the batch input management transaction for batch input sessions.

Batch input by way of CALL TRANSACTION USING offers faster processing if you need it to get your batch input done in the time slot that is available for it. CALL TRANSACTION USING offers, however, less support for error recovery and management of batch input.

For detailed information, please see Selecting a Batch-Input Method(11) .

3. Write the batch input program.

Your program will need to do the following:

- read data in, often from a sequential file that has been exported from another system or prepared by a data transfer program

- if necessary, perform data conversions or error-checking

- prepare the data for batch input processing by storing the data in the batch input data structure, BDCDATA.

- generate a batch input session for classical batch input, or process the data directly with CALL TRANSACTION USING.

You'll find information on programming techniques for batch input programs in the following topics, as well as a sample program.

-

-


(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.

figure(17).

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.

-

-


(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. Build 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-DYNPRO.

'X' TO BDCDAT-DYNBEGIN.

APPEND BDCDAT.

ENDFORM.

-

-


b) Identifying a Screen:

The first record for each screen must contain information that identifies the screen: program name, screen name and a start-of-screen indicator. You record this information in the PROGRAM, DYNPRO, and DYNBEGIN fields of the BDCDATA structure.

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 receive 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 target 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 function key number in the command field of an SAP session. You use the FNAM and FVAL 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. This name is constant and always identifies the command field.

This sample record would execute the save function. It uses the function key assignment 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 with the = character.

Example:

BDCDATA-FNAM = 'BDC_OKCODE'.

BDCDATA-FVAL = '=UPDA'.

-

-


e)Entering Values in Loop Fields

Some screen fields need multiple values, one on each line. To provide input to one of these loop fields, you must use an explicit line index :

Example:

BDCDATA-FNAM = 'fieldx(5)'.

BDCDATA-FVAL = 'value'.

The line index (in the example: (5), line 5) indicates in which loop line on the screen values are to appear.

-

-


f)Positioning the Cursor:

To position the cursor on a particular field, you must use the special cursor field:

Example:

BDCDATA-FNAM = 'BDC_CURSOR'.

BDCDATA-FVAL = 'fieldx'.

To position the cursor on a loop field, you must use again an index:

Example:

BDCDATA-FNAM = 'BDC_CURSOR'.

BDCDATA-FVAL = 'fieldy(5)'.

-

-


g)Ending a Transaction:

You can successfully complete processing of a transaction in batch input in either of two ways:

• leave the transaction and return to the SAP main menu.

• trigger an update of the database.

figure(18).

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 transaction:

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 enter 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 your batch input sessions cannot be run quickly enough. For more information on choosing the best batch input method, see Selecting a Batch-Input Method(11) .

figure(19).

Creating, Filling, and Closing a Batch Input Session

To create a session, program the following procedure using the following BDC_ function 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 be 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 Program(22) for an example of how the function modules are used.

-

-


(15) CREATING A SESSION WITH BDC_OPEN_GROUP :

Use the BDC_OPEN_GROUP function module to do the following create a new session. Once you have created a session, then you can insert batch input data into it with BDC_INSERT.

You cannot re-open a session that already exists and has been closed. If you call BDC_OPEN_GROUP with the name of an existing session, then an additional session with the same name is created.

A batch input program may have only one session open at a time. Before opening a session, make sure that any sessions that the program closes any sessions that it previously had opened.

figure(20).

BDC_OPEN_GROUP takes the following EXPORTING parameters:

• CLIENT

Client in which the session is to be processed.

Default: If you don't provide a value for this parameter, the default is the client under which the batch input program runs when the session is created.

• 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 that you specify. Only a system administrator with the LOCK authorization for the authorization object Batch Input Authorizations can unlock and run a session before this date.

Format: YYYYMMDD (8 digits).

Default: No lock date, session can be processed immediately. A lock date is optional.

• KEEP

Retain session after successful processing. Set this option to the value X to have a session kept after it has been successfully processed. A session that is kept 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 used 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 to be executed in a session. Otherwise, transactions will be terminated with "no authorization" errors.

The user can be of type dialog or background. Dialog users are normal interactive users in the SAP System. Background users are user master records that are specially defined for providing authorizations for background processing jobs.

-

-


(16) ADDING DATA TO A SESSION: BDC_INSERT :

Use the BDC_INSERT function module to add a transaction to a batch input session. You specify the transaction that is to be started in the call to BDC_INSERT. You must provide a BDCDATA structure that contains all of the data required to process the transaction completely.

figure(21).

BDC_INSERT takes the following parameters:

• TCODE

The code of the transaction that is to be run.

For help in finding the transaction code of a function, see Analyzing SAP Transactions(4) .

TCODE is an EXPORTING parameter in the function module.

• POST_LOCAL

Parameter to update data locally. If POST_LOCAL = 'X', data will be updated locally.

(refer to the keyword documentation of SET UPDATE TASK LOCAL for more information)

• DYNPROTAB

The BDCDATA structure that contains the data that is to be processed by the transaction.

DYNPROTAB is a tables parameter in the function module.

For information on filling the structure, see Programming Techniques: Entering Data and Executing Functions(13).

-

-


(17) CLOSING A SESSION: BDC_CLOSE_GROUP :

Use the BDC_CLOSE_GROUP function module to close a session after you have inserted all of your batch input data into it. Once a session is closed, it can be processed.

figure(22).

BDC_CLOSE_GROUP needs no parameters. It automatically closes the session that is currently open in your program.

You must close a session before you can open another session from the same program.

You cannot re-open a session once it has been closed. A new call to BDC_OPEN_GROUP with the same session name creates a new session with the same name.

-

-


(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) .

figure(23).

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

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. There is no restart capability for transactions that contain errors or produce update failures.

You can handle incorrect transactions by using update mode S (synchronous updating) and checking the return code from CALL TRANSACTION USING. If the return code is anything other than 0, then you should do the following:

• write out or save the message table

• use the BDCDATA table that you generated for the CALL TRANSACTION USING to generate a batch input session for the faulty transaction. You can then analyze the faulty transaction and correct the error using the tools provided in the batch input management facility.

-

-


(20) USING CALL DIALOG WITH BATCH INPUT:

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

1. For the screens you want processed, fill all desired fields.

2. Use a CALL DIALOG statement to call the dialog module and to pass it to the BDCDATA table.

figure(24).

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'.

-

-


(21) DIRECT INPUT:

To enhance the batch input procedure, the system offers the direct input technique, especially for transferring large amounts of data. In contrast to batch input, this technique does not create sessions, but stores the data directly. It does not process screens. To enter the data into the corresponding database tables directly, the system calls a number of function modules that execute any necessary checks. In case of errors, the direct input technique provides a restart mechanism. However, to be able to activate the restart mechnism, direct input programs must be executed in the background only. To maintain and start these programs, use program RBMVSHOW or the transaction BMV0.

Examples for direct input programs are:

Program Application

-

-


-

-


RFBIBL00 FI

RMDATIND MM

RVAFSS00 SD

RAALTD11 AM

RKEVEXT0 CO-PA

For more information, see the respective program documentation.

-

-


(22) SAMPLE BATCH INPUT PROGRAM:

The following program demonstrates both the creation of sessions, and the use of CALL TRANSACTION USING.

REPORT RJBDC200 LINE-SIZE 120.

*----


*

  • Add a line in a report *

*----


*

PARAMETERS : BDCTYPE TYPE C DEFAULT 'M',

" M = Create batch input session

" T = Call transaction

"----

-


*

" Only used for batch input sessions *

"----

-


*

GROUP(12) TYPE C DEFAULT 'BDCTEST',

" group name of session

USER(12) TYPE C DEFAULT SY-UNAME,

" user name for starting the

" session in background

KEEP(1) TYPE C,

" ' ' = delete session after processing

" 'X' = keep session after successful

" processing

HOLDDATE LIKE SY-DATUM,

"----

-


*

" Only used for call transaction *

"----

-


*

DMODE TYPE C DEFAULT 'A'.

" Display mode

" 'A' = display all screens

" 'E' = display only errors

" 'N' = display nothing

*----


*

  • Batch input data for a single transaction *

*----


*

DATA: BEGIN OF BDCDATA OCCURS 0.

INCLUDE STRUCTURE BDCDATA.

DATA: END OF BDCDATA.

DATA: BEGIN OF MESSTAB OCCURS 0.

INCLUDE STRUCTURE BDCMSGCOLL.

DATA: END OF MESSTAB.

*----


*

  • Generate batch input *

  • *

*----


*

CASE BDCTYPE.

WHEN 'M'.

PERFORM CREATE_GROUP.

EXIT.

WHEN 'T'.

PERFORM CALL_TRANSACTION.

EXIT.

ENDCASE.

*----


*

  • *

  • Create batch input session *

  • *

*----


*

FORM CREATE_GROUP.

WRITE: / 'Create group'.

"----

-


*

" Open batch input group *

"----

-


*

CALL FUNCTION 'BDC_OPEN_GROUP'

EXPORTING

CLIENT = SY-MANDT

GROUP = GROUP

USER = USER

KEEP = KEEP

HOLDDATE = HOLDDATE.

WRITE: / 'BDC_OPEN_GROUP rc ='(999), SY-SUBRC.

"----

-


*

" Insert first transaction *

"----

-


*

PERFORM GEN_BDC_DATA.

CALL FUNCTION 'BDC_INSERT'

EXPORTING

TCODE = 'SE38'

TABLES

DYNPROTAB = BDCDATA.

WRITE: / 'BDC_INSERT rc ='(999), SY-SUBRC.

"----

-


*

" Insert second transaction *

"----

-


*

PERFORM GEN_BDC_DATA.

CALL FUNCTION 'BDC_INSERT'

EXPORTING

TCODE = 'SE38'

TABLES

DYNPROTAB = BDCDATA.

WRITE: / 'BDC_INSERT rc ='(999), SY-SUBRC.

"----

-


*

" Close batch input group *

"----

-


*

CALL FUNCTION 'BDC_CLOSE_GROUP'.

WRITE: / 'BDC_CLOSE_GROUP rc ='(999), SY-SUBRC.

ENDFORM. " End CREATE_GROUP

*----


*

  • *

  • Call Transaction Using *

  • *

*----


*

FORM CALL_TRANSACTION.

WRITE: / 'Call Transaction RC ='(999).

PERFORM GEN_BDC_DATA.

CALL TRANSACTION 'SE38' USING BDCDATA MODE DMODE MESSAGES INTO

MESSTAB.

WRITE: SY-SUBRC, SY-MSGTY, SY-MSGID, SY-MSGNO, SY-MSGV1.

WRITE: / ' ', SY-MSGV2.

WRITE: / ' ', SY-MSGV3.

WRITE: / ' ', SY-MSGV4.

ENDFORM. " End CALL_TRANSACTION

*----


*

  • *

  • Create batch input data for *

  • transaction SE38 *

  • *

*----


*

FORM GEN_BDC_DATA.

DATA: LINE LIKE BDCDATA-FVAL.

REFRESH BDCDATA.

*----


*

  • First screen of transaction *

*----


*

PERFORM BDC_DYNPRO USING 'SAPMS38M' '0100'.

PERFORM BDC_FIELD USING 'RS38M-PROGRAMM' 'RJBDC999'.

PERFORM BDC_FIELD USING 'bdc_cursor' 'chap'.

PERFORM BDC_FIELD USING 'BDC_OKCODE' '/00'.

*----


*

  • In editor, go to bottom of report *

*----


*

PERFORM BDC_DYNPRO USING 'SAPMSEDT' '2310'.

PERFORM BDC_FIELD USING 'RSTXP-TDCOMMLINE' 'BOT'.

*----


*

  • Insert line into report *

*----


-


*

PERFORM BDC_DYNPRO USING 'SAPMSEDT' '2310'.

PERFORM BDC_FIELD USING 'RSTXP-TDLINECOM(17)' 'I'.

*----


*

  • Go to bottom of report again *

*----


*

PERFORM BDC_DYNPRO USING 'SAPMSEDT' '2310'.

PERFORM BDC_FIELD USING 'RSTXP-TDCOMMLINE' 'BOT'.

*----


*

  • Modify line in report and save report *

  • (Enter f11 in ok-code) *

*----


*

PERFORM BDC_DYNPRO USING 'SAPMSEDT' '2310'.

LINE = 'Batchinput'.

LINE+20 = SY-DATUM.

LINE+30 = SY-UZEIT.

PERFORM BDC_FIELD USING 'RSTXP-TDLINE(17)' LINE.

PERFORM BDC_FIELD USING 'BDC_OKCODE' '/11'.

*----


*

  • Leave the editor (enter f3 in ok-code) *

*----


*

PERFORM BDC_DYNPRO USING 'SAPMSEDT' '2310'.

PERFORM BDC_FIELD USING 'BDC_OKCODE' '/3'.

*----


*

  • Leave transaction se38 (enter f15 in *

  • ok-code) *

*----


*

PERFORM BDC_DYNPRO USING 'SAPMS38M' '0100'.

PERFORM BDC_FIELD USING 'BDC_OKCODE' '/15'.

ENDFORM. "End GEN_BDC_DATA

*----


*

  • *

  • In the batch input data, start a new screen *

  • *

*----


*

FORM BDC_DYNPRO USING PROGRAM DYNPRO.

CLEAR BDCDATA.

BDCDATA-PROGRAM = PROGRAM.

BDCDATA-DYNPRO = DYNPRO.

BDCDATA-DYNBEGIN = 'X'.

APPEND BDCDATA.

ENDFORM. "End BDC_DYNPRO

*----


*

  • *

  • In the batch input data, insert a field *

  • *

*----


*

FORM BDC_FIELD USING FNAM FVAL.

CLEAR BDCDATA.

BDCDATA-FNAM = FNAM.

BDCDATA-FVAL = FVAL.

APPEND BDCDATA.

ENDFORM.

-

-


(23) BATCH INPUT RECORDING FOR TRANSACTION RUNS:

This section tells you how to use the recording functions of batch input.

For more information, refer to these sections:

a)Recording features

b)Sample program

c)Special recording features

-

-


a)Recording features

The recording function offers the following features:

• recording transaction runs,

• creating batch input sessions from the recorded transaction run,

• generating a batch input program from the recorded data.

Recording transaction runs

A batch input recording consists of a sequence of transactions with the screens processed. A screen (program name, screen name) contains the modified fields (field name, field value), the executed user command (BDC_OKCODE) and the cursor position (BDC_CURSOR).

To start the recording function, go to the batch input initial screen and choose Record or directly call transaction SHDB.

The system stores each recording under a name of up to 12 characters that you can choose at will. You must specify this name when starting the recording. The following special characters are not allowed: . , ( ) ' " = Ä Ö Ü ß.

The recording function offers an overview of all exising recordings. To display the overview, click on Overview. You can limit the selection by entering a date interval.

To create a recording, specify the recording name and choose Create. In the subsequent dialog box, enter the name of the transaction you want to record. Then execute the transaction and enter the required values in the screen fields.

After the end of the transaction, the system displays the processed screens (module pool, screen number), the changed fields (field name, field value), the executed user commands (BDC_OKCODE). and the cursor position (BDC_CURSOR) in a hierarchical list. Choose Copy transaction to copy the executed transaction run into the recording. Choose Next transaction if you want to record another transaction run with a different transaction.

After recording all desired transactions, save the recording.

Create batch input sessions from the recorded transaction run

From within the recording overview, choose Create session to create a batch input session with the data of the recorded transaction. You can then process this session as usual.

Generate a batch input program from the recorded data

Apart from creating a session, you can also generate an ABAP/4 batch input program from within the recording overview. In this case, select the desired recording and specify the name of the program you want to generate. Then maintain the program attributes and the entry in the object list.

The generated program contains the entire coding required to create a batch input session. Thus you can leave out the transaction execution and the determination of the module pool name, the screen numbers, the field names, and the function codes.

You may need to modify this program only slightly, if you want to use it, for example, to read the data to be transferred from a sequential dataset.

-

-


b)sample program

This example shows a program that was generated to transfer data using transaction TFCA. This program changes the plane type (SFLIGHT-PLANETYPE) for the airline (SFLIGHT-CARRID) 'LH' and the connection ID (SFLIGHT-CONNID) '2402'.

report khtfca01.

include bdcrecxx.

start-of-selection.

perform open_group.

perform bdc_dynpro using 'SAPMTFCA' '0100'.

perform bdc_field using 'BDC_OKCODE' 'UPDA'.

perform bdc_field using 'BDC_CURSOR' 'SFLIGHT-CARRID'.

perform bdc_field using 'SFLIGHT-CARRID' 'LH'.

perform bdc_field using 'SFLIGHT-CONNID' '2402'.

perform bdc_dynpro using 'SAPMTFCA' '0200'.

perform bdc_field using 'BDC_OKCODE' 'SAVE'.

perform bdc_field using 'BDC_CURSOR' 'SFLIGHT-PLANETYPE(02)'.

perform bdc_field using 'SFLIGHT-PLANETYPE(02)' 'A321'.

perform bdc_transaction using 'TFCA'.

perform close_group.

The subroutines called are part of the include program BDCRECXX. They call the function modules required for creating a batch input session and they fill the BDC table. In addition, this include parameter contains statements for the selection screen layout.

-

-


c)special recording features:

The following data is not recorded:

• F1, F4, and customer-related F1 and F4 functions,

• all functions of the menus System and Help,

• values of the standard variant,

• error dialogs and warning dialogs,

• scrolling via the scrollbar (use F21 to F24 instead).

COMMIT WORK indicates the successful end of the transaction and, thus, of the recording.

LEAVE TO TRANSACTION cannot be processed in batch input and, therefore, ends the recording.

**********************************************************************

********************************************************************

Please undestand the basic concept of the BDC..and Let me know. So that, u can get veru good knowledge abt them.

Once, u got basic idea...then let me know...I will also provide you with some programs on Calll Transcation and session method.

Also let me know ur personel email address...I will send u few doc's

Hope the above information was helpful....

Reward Points if helpful

Regards,

Krishna Chaitanya

former_member212002
Active Contributor
0 Kudos
200

Thnks For all ur input