Application Development and Automation 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: 
Read only

BDC

Former Member
0 Likes
387

It has been mentioned in the document document that,

the data transfer by Session method is asynchronous processing and the updation is always synchronous.

And the data transfer by call transaction method is synchronous processing and the updation is either synchronous or asynchronous?

Pls explain me.

Pls dont do copy paste.. Helpful answers will sure be rewarded...

Thanks.

2 REPLIES 2
Read only

former_member189629
Active Contributor
0 Likes
361

Shori,

You use the UPDATE parameter to 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 data transfer 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 data

transfer 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 is 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. (See the ABAP keyword documentation on SET UPDATE TASK LOCAL

for more information.)

When you transfer data in ABAP, you have three options to submit the data for the data transfer. 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.

Use the CALL TRANSACTION USING statement

Summary: With CALL TRANSACTION USING, the system processes 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

Create a session on the batch input queue.

Reward if helpful,

Karthik

Read only

0 Likes
361

A BDC done with sessions is always synchronus.

A BDC with call transaction is by default asynchronus

unless you define it explicitly as

call transaction 'XXXX' ...... update 'S'.

( If you donot define update option it is defaulted to "A" ).

The update method is of importance when one transaction locks data which may be required by a subsequent transaction . The subsequent transaction will fail if data is locked from previous one. An example would be you are creating sales order for same material in succession ( with asynchronus update ). Quite likely that some of transactions would fail due to material locked.