BDC

[Former Member]

DIFFERENCE BETWEEN CALL TRANSACTION AND SESSION METHOD ?

[Former Member]

Batch Input and CALL TRANSACTION are both data transfer methods. Batch Input usually are used to transfer large amount of data. For example you are implementing a new SAP project, and of course you will need some data transfer from legacy system to SAP system. If there is no standard batch input program, direct input program, you would need to write your own data transfer program and it is going to be batch input program. CALL TRANSACTION methods is real-time method, whenever you run the program CALL TRANSACTION can be triggered. CALL TRANSACTION is used especially for integration actions between two SAP systems or between different modules. Users sometimes wish to do something like that click a button or an item then SAP would inserts or changes data automatically. Here CALL TRANSACTION should be considered. You use CALL TRANSACTION and you do everything automatically, collect necessary data, call transaction and so do database update. If any error occurs, show the user them.

Batch Input

With the Batch Input method, an ABAP program reads the external data that is to be entered in the R/3 System and stores the data in a “batch input session”. The session records the actions that are required to transfer data into the system using normal SAP transactions.

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

It 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 modules calls from the ABAP program.

The most important aspects of the session interface are:

Asynchronous processing

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

CALL TRANSACTION

In the second method, your program uses the ABAP statement CALL TRANSACTION USING to run an SAP transaction. External data doesn’t have to be deposited in a session for later processing. Instead, the entire batch input process takes place inline in your program. With CALL TRANSACTION USING, the system process the data more quickly than with batch input sessions. Unlike batch input sessions, CALL TRANSACTION USING does not automatically support interactive correction or logging functions.

Your program prepares the data and then calls the corresponding transaction that is then processed immediately.

The most important features of CALL TRANSACTION USING are:

Synchronous processing

Transfer of data from an individual transaction each time the statement CALL TRANSACTION USING is called

You can update the database both synchronously and asynchronously. The program specifies the update type.

Separate LUW (Logical Units of Work) for the transaction. The system executes a database commit immediately before and after the CALL TRANSACTION USING statement.

No batch input processing log

Check these link:

http://www.sap-img.com/abap/difference-between-batch-input-and-call-transaction-in-bdc.htm

http://www.sap-img.com/abap/question-about-bdc-program.htm

http://www.itcserver.com/blog/2006/06/30/batch-input-vs-call-transaction/

http://www.planetsap.com/bdc_main_page.htm

[Former Member]

Hi,

Call Transaction

1. Processing faster

2.Can transfer small amount of data

3.We have to handle the error by using

BDCMSGCOLL

4.Data Updated automatically

BDC Session

1. Processing is slower

2. Large amount of data

3. Error Log will be created

4. we have to process session using tcode sm35 or using program RSBDCSUB

[Former Member]

hi ramotar,

These two methods r used to upload data into the R/3 System from a legacy system. These two methods have quite a bit of difference.

Session Method.

1. Data is not updated in database table unless session is processed.

2. No sy-subrc is returned.

3.Error log is created for error records.

4. Updation in database table is always synchronous.

5. internal table ---> session -

---

> database table.

Call Transaction Method.

1.Immediate updation in database table.

2.sy-subrc is returned.

3.Error need to be handled explicitly.

4.Updation in database table can be synchronous or asynchronous.

5. internal table -

---

>(using call transaction stmt) database table.

Regards....

Arun.

[Former Member]

Session method.

1) synchronous processing.

2) can tranfer large amount of data.

3) processing is slower.

4) error log is created

5) data is not updated until session is processed.

Call transaction.

1) asynchronous processing

2) can transfer small amount of data

3) processing is faster.

4) errors need to be handled explicitly

5) data is updated automatically

Batch Data Communication (BDC) is the oldest batch interfacing technique that SAP provided since the early versions of R/3. BDC is not a typical integration tool, in the sense that, it can be only be used for uploading data into R/3 and so it is

not bi-directional.

BDC works on the principle of simulating user input for transactional screen, via an ABAP program.

Typically the input comes in the form of a flat file. The ABAP program reads this file and formats the input data screen by screen into an internal table (BDCDATA). The transaction is then started using this internal table as the input and executed in the background.

In ‘Call Transaction’, the transactions are triggered at the time of processing itself and so the ABAP program must do the error handling. It can also be used for real-time interfaces and custom error handling & logging features. Whereas in

Batch Input Sessions, the ABAP program creates a session with all the transactional data, and this session can be viewed, scheduled and processed (using Transaction SM35) at a later time. The latter technique has a built-in error processing mechanism too.

Batch Input (BI) programs still use the classical BDC approach but doesn’t require an ABAP program to be written to format the BDCDATA. The user has to format the data using predefined structures and store it in a flat file. The BI program then reads this and invokes the transaction mentioned in the header record of the file.

Direct Input (DI) programs work exactly similar to BI programs. But the only difference is, instead of processing screens they validate fields and directly load the data into tables using standard function modules. For this reason, DI programs are much faster (RMDATIND - Material Master DI program works at least 5 times faster) than the BDC counterpart and so ideally suited for loading large volume data. DI programs are not available for all application areas.

http://www.itcserver.com/blog/2006/06/30/batch-input-vs-call-transaction

http://www.geekinterview.com/Interview-Questions/SAP-R-3/BDC

[Former Member]

session method :

->using this we can upload large as well as small amount of data.

->error log is maintained by default.

->we can check it in sm35.(another session will be opened)

->it updates data synchronously and processes asynchronously

-> we can do back ground job schedulling also.

call transaction:

->for small amount of data only.

-> we have to catch errors using BDCMSGCOLL or else we can use FORMAT_MESSAGES for error handling.

->data can be updated syncronously or asyncronously.

[Former Member]

Hi,

Batch input is a standard procedure for transferring large amount of data into the R/3 system. It simulates manual data entry. Data consistency is ensured because batch input uses all the checks conducted on the normal screen. Using batch input is like entering the data online. Another advantage to batch input is that you do not have to check the data in advance.

Batch input is a two-step procedure. It involves a program that creates the batch input session. This session is the data file that includes everything to begin the transaction and the data to be entered on the appropriate screens. The data is not yet in the database tables of R/3 application.

The second step is to process the session, which then actually transfers the data to database table. You can transfer data directly to database table by using CALL TRANSACTION method also. Another method - Direct Input, is done for high volume of data for the standard application.

Difference Between Batch Input and Call Transaction in BDC .

Session method.

1) synchronous processing.

2) can tranfer large amount of data.

3) processing is slower.

4) error log is created

5) data is not updated until session is processed.

Call transaction.

1) asynchronous processing

2) can transfer small amount of data

3) processing is faster.

4) errors need to be handled explicitly

5) data is updated automatically

SESSION METHOD

About Session method

In this method you transfer data from internal table to database table through sessions.

In this method, an ABAP/4 program reads the external data that is to be entered in the SAP System and stores the data in session. A session stores the actions that are required to enter your data using normal SAP transaction i.e., Data is transferred to session which in turn transfers data to database table.

Session is intermediate step between internal table and database table. Data along with its action is stored in session i.e., data for screen fields, to which screen it is passed, the program name behind it, and how the next screen is processed.

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 or have the session run in the background processing system.

Unless session is processed, the data is not transferred to database table.

CALL TRANSACTION

About CALL TRANSACTION

A technique similar to SESSION method, while batch input is a two-step procedure, Call Transaction does both steps online, one after the other. In this method, you call a transaction from your program by

Call transaction <tcode> using <BDCTAB>

Mode <A/N/E>

Update <S/A>

Messages into <MSGTAB>.

Parameter – 1 is transaction code.

Parameter – 2 is name of BDCTAB table.

Parameter – 3 here you are specifying mode in which you execute transaction

A is all screen mode. All the screen of transaction are displayed.

N is no screen mode. No screen is displayed when you execute the transaction.

E is error screen. Only those screens are displayed wherein you have error record.

Parameter – 4 here you are specifying update type by which database table is updated.

S is for Synchronous update in which if you change data of one table then all the related Tables gets updated. And sy-subrc is returned i.e., sy-subrc is returned for once and all.

A is for Asynchronous update. When you change data of one table, the sy-subrc is returned. And then updating of other affected tables takes place. So if system fails to update other tables, still sy-subrc returned is 0 (i.e., when first table gets updated).

Parameter – 5 when you update database table, operation is either successful or unsuccessful or operation is successful with some warning. These messages are stored in internal table, which you specify along with MESSAGE statement. This internal table should be declared like BDCMSGCOLL, a structure available in ABAP/4. It contains the following fields:

1. Tcode: Transaction code

2. Dyname: Batch point module name

3. Dynumb: Batch input Dyn number

4. Msgtyp: Batch input message type (A/E/W/I/S)

5. Msgspra: Batch input Lang, id of message

6. Msgid: Message id

7. MsgvN: Message variables (N = 1 - 4)

For each entry, which is updated in database, table message is available in BDCMSGCOLL. As BDCMSGCOLL is structure, you need to declare a internal table which can contain multiple records (unlike structure).

Hope this helps.

Regards,

Sruthi