topic Re: call transaction method in Application Development and Automation Discussions

call transaction method

Former Member — Tue, 05 Jun 2007 05:14:15 GMT

what is the default update mode in call transasction method?

syncronous or asyncronous? why?

Re: call transaction method

gopi_narendra — Tue, 05 Jun 2007 05:16:39 GMT

The default is 'A' Asynchronous update mode

Regards

Gopi

Re: call transaction method

Former Member — Tue, 05 Jun 2007 05:17:06 GMT

Syncronous is the Default for Call transaction.

A synchronous Workflow task must be executed before control is passed to the next step. It is used for tasks that do not involve required updates, because once the workitem is executed, control is passed on to the next step without checking the success or failure of any update that might or might not have taken place.

Regards

Sudheer

Re: call transaction method

Former Member — Tue, 05 Jun 2007 05:17:32 GMT

hi,

'A' - Asynchronous mode is the default one.

Regards,

Santosh

Message was edited by:

Santosh Kumar Patha

Re: call transaction method

Former Member — Tue, 05 Jun 2007 05:17:58 GMT

Synchronous only.

Re: call transaction method

Former Member — Tue, 05 Jun 2007 05:19:03 GMT

Hi,

The default is 'A' Asynchronous update mode.

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

Regards

Re: call transaction method

Former Member — Tue, 05 Jun 2007 05:22:02 GMT

hi sandya,

default update mode is <b>'A'-asyncronous</b> mode,

this can update the database at a single shot that means we can save the time here.

regards,

seshu.

Re: call transaction method

Former Member — Tue, 05 Jun 2007 05:22:52 GMT

Hi,

I think it is Asynchronous

Thanks,

Naren

Re: call transaction method

Former Member — Tue, 05 Jun 2007 06:42:22 GMT


A program that uses CALL TRANSACTION USING to process legacy 
data should execute the following steps:

Prepare a BDCDATA structure for the transaction that you wish to run. 
With a CALL TRANSACTION USING statement, call the transaction and 
prepare the BDCDATA structure. For example:

CALL TRANSACTION 'TFCA' USING BDCDATA 
MODE 'A'
UPDATE 'S'.
MESSAGES INTO MESSTAB.

IF SY-SUBRC <> 0.

 <Error_handling>.

ENDIF.

The MODE Parameter

You can use the MODE parameter to specify whether data transfer 
processing should be displayed as it happens. You can choose 
between three modes: 

A Display all. All screens and the data that goes in them appear 
when you run your program. 

N No display. 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. 

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

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 points if it is usefull .......

Girish

Re: call transaction method

Former Member — Wed, 03 Oct 2007 06:50:56 GMT