In what situations we have to choose Call transition, Session method, LSMW

[Former Member]

Hi,

In Batch Data Communication we have 3 methods

1) Call Transaction Method, 2) Session Method, 3) LSMW.

I am aware of the above 3 methods. But I am not clear in what situations we have to choose Call transition, in what situations we have to choose Session method, similarly in what situations we have to choose LSMW.

Can any body please explain?

Thanks in advance.

Ramana

[Former Member]

Hi,

In BDC there r three methods 1. Call Transaction 2. Session 3.Direct Input.

LSMW is another tool to upload data where you may not require to do any coding but in BDC u hv to do coding.

Generally Call Transaction use to run in the foreground and if voloum is less if there exist any error then u hv to pass those information in another internal table and later on u can display that in a control report but in session method which will run in the background , u may require to process the session manually (sm35) and all errinous information will be available in the log file so from there later on data can be corrected manually and it can be processed again.

If sounds good pl reward.

Cheers.

[Former Member]

Here is some information about different methods. Reward points if they are helpful.

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.

The most important aspects of the batch 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 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.

<b><u>SAP Data Migration with LSMW</u></b>

No ABAP effort are required for the SAP data migration. However, effort are required to map the data into the structure according to the pre-determined format as specified by the pre-written ABAP upload program of the LSMW.

The Legacy System Migration Workbench (LSMW) is a tool recommended by SAP that you can use to transfer data once only or periodically from legacy systems into an R/3 System.

More and more medium-sized firms are implementing SAP solutions, and many of them have their legacy data in desktop programs. In this case, the data is exported in a format that can be read by PC spreadsheet systems. As a result, the data transfer is mere child's play: Simply enter the field names in the first line of the table, and the LSM Workbench's import routine automatically generates the input file for your conversion program.

The LSM Workbench lets you check the data for migration against the current settings of your customizing. The check is performed after the data migration, but before the update in your database.

So although it was designed for uploading of legacy data it is not restricted to this use.

We use it for mass changes, i.e. uploading new/replacement data and it is great, but there are limits on its functionality, depending on the complexity of the transaction you are trying to replicate.

The SAP transaction code is 'LSMW' for SAP version 4.6x.

For those with the older SAP version (4.7 and below), the data migration programs might not have been pre-loaded.

You can download the LSMW at no cost from SAPNet under Services, SAP Methodology and Tools, category Tools.

Rgds,

Naren

[Former Member]

Hi Naren

good answer to my question

thanks for that

[Former Member]

Session method – Use the BDC_OPEN_GROUP to create a session. Once we have created a session, then we can insert the batch input data into it with BDC_INSERT. Use the BDC_INSERT to add a transaction to a batch input session. We specify the transaction that is to be started in the call to BDC_INSERT. We must provide a BDCDATA structure that contains all the data required to process the transaction completely. Use the BDC_CLOSE_GROUP to close a session after we have inserted all of our batch input data into it. Once a session is closed, it can be processed.

We use Session method for huge amount of data and also if you want to do dynamic validation ,then we go for Call Transaction

Call Transaction -

In this method, we use CALL TRANSACTION USING to run an SAP transaction. External data does not have to be deposited in a session for later processing. Instead, the entire batch input process takes place inline in our program.

Call transaction is faster then session method. But usually we use session method in real time...because we can transfer large amount of data from internal table to database and if any errors in a session, then process will not complete until session get correct.

See the below example to go for Call Transaction :

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 data transfer program.

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 is much easier for you to analyze and recover from errors

one simple example : You are creating sales order from file and also you want to update header text of sales order.

when you want to update sales order header text,you need to use save_text function module ,here you need to pass sales order number.

when you use call transaction update 'A', data will update transaction level and it goes to the next record,here it will not wait for database .

when you use call transaction update 'S',data will update transaction level and it will update database then it goes next record.

if you want to update header text,then you need to use sync update

database commit -

comitt work - it will update data in database sucessfully

roll back - it will not update in database.

LSMW - tool and no need to write the code - if you do not have complex validation then we go for LSMW Other wise we go for normal BDC Method

[Former Member]

Hi Seshu

thanks for ur convincing answer

i got an idea from ur explanation

[Former Member]

Thanks a lot Naren. It was a wonderful explanation .

[bhagaban_pradhan2]

Thank, for this post abt why we choose syn.

I have some doubt ?

In real time which scenario we should go for call transaction instead of session method in BCD ?

[bhagaban_pradhan2]

Hi Seshu,

Thank, for this post abt why we choose syn.

I have some doubt ?

In real time which scenario we should go for call transaction instead of session method in BCD ?