<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: BDC in Application Development and Automation Discussions</title>
    <link>https://community.sap.com/t5/application-development-and-automation-discussions/bdc/m-p/2837900#M664558</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Shori,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;You use the UPDATE parameter to specify how updates produced by a &lt;/P&gt;&lt;P&gt;transaction should be processed. You can select between these modes: &lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;A Asynchronous updating. In this mode, the called transaction does not &lt;/P&gt;&lt;P&gt;wait for any updates it produces to be completed. It simply passes the &lt;/P&gt;&lt;P&gt;updates to the SAP update service. Asynchronous processing therefore&lt;/P&gt;&lt;P&gt; usually results in faster execution of your data transfer program.&lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;Asynchronous processing is NOT recommended for processing any larger &lt;/P&gt;&lt;P&gt;amount of data. This is because the called transaction receives no completion &lt;/P&gt;&lt;P&gt;message from the update module in asynchronous updating. The calling data &lt;/P&gt;&lt;P&gt;transfer program, in turn, cannot determine whether a called transaction ended &lt;/P&gt;&lt;P&gt;with a successful update of the database or not. &lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;If you use asynchronous updating, then you will need to use the update &lt;/P&gt;&lt;P&gt;management facility (Transaction SM12) to check whether updates have &lt;/P&gt;&lt;P&gt;been terminated abnormally during session processing. Error analysis and &lt;/P&gt;&lt;P&gt;recovery is less convenient than with synchronous updating.&lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;S Synchronous updating. In this mode, the called transaction waits for any&lt;/P&gt;&lt;P&gt; updates that it produces to be completed. Execution is slower than with &lt;/P&gt;&lt;P&gt;asynchronous updating because called transactions wait for updating to be&lt;/P&gt;&lt;P&gt; completed. However, the called transaction is able to return any update error&lt;/P&gt;&lt;P&gt; message that occurs to your program. It is much easier for you to analyze &lt;/P&gt;&lt;P&gt;and recover from errors. &lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;L Local updating. If you update data locally, the update of the database will &lt;/P&gt;&lt;P&gt;not be processed in a separate process, but in the process of the calling &lt;/P&gt;&lt;P&gt;program. (See the ABAP keyword documentation on SET UPDATE TASK LOCAL&lt;/P&gt;&lt;P&gt; for more information.)&lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;When you transfer data in ABAP, you have three options to submit the data for the data transfer. Only the &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;first two methods can be recommended without reservation. The third method, by way of CALL DIALOG, is &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;outmoded. CALL DIALOG is less comfortable than the other methods. You should use it only if you must.&lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;Use the CALL TRANSACTION USING statement&lt;/P&gt;&lt;P&gt;Summary: With CALL TRANSACTION USING, the system processes the data more quickly than with batch input &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;sessions. Unlike batch input sessions, CALL TRANSACTION USING does not automatically support interactive &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;correction or logging functions.&lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;Your program prepares the data and then calls the corresponding transaction that is then processed &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;immediately.&lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;The most important features of CALL TRANSACTION USING are:&lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;Synchronous processing &lt;/P&gt;&lt;P&gt;Transfer of data from an individual transaction each time the statement CALL TRANSACTION USING is called &lt;/P&gt;&lt;P&gt;You can update the database both synchronously and asynchronously&lt;/P&gt;&lt;P&gt;The program specifies the update type&lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;Separate LUW (logical units of work) for the transaction&lt;/P&gt;&lt;P&gt;The system executes a database commit immediately before and after the CALL TRANSACTION USING statement &lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;No batch input processing log&lt;/P&gt;&lt;P&gt;Create a session on the batch input queue.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Reward if helpful,&lt;/P&gt;&lt;P&gt;Karthik&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 03 Oct 2007 07:59:41 GMT</pubDate>
    <dc:creator>former_member189629</dc:creator>
    <dc:date>2007-10-03T07:59:41Z</dc:date>
    <item>
      <title>BDC</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/bdc/m-p/2837899#M664557</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;It has been mentioned in the document document that,&lt;/P&gt;&lt;P&gt;the data transfer by Session method is asynchronous processing and the updation is always synchronous.&lt;/P&gt;&lt;P&gt;And the data transfer by call transaction method is synchronous processing and the updation is either synchronous or asynchronous?&lt;/P&gt;&lt;P&gt;Pls explain me.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Pls dont do copy paste.. Helpful answers will sure be rewarded...&lt;/P&gt;&lt;P&gt;Thanks.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 03 Oct 2007 07:57:05 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/bdc/m-p/2837899#M664557</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-10-03T07:57:05Z</dc:date>
    </item>
    <item>
      <title>Re: BDC</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/bdc/m-p/2837900#M664558</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Shori,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;You use the UPDATE parameter to specify how updates produced by a &lt;/P&gt;&lt;P&gt;transaction should be processed. You can select between these modes: &lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;A Asynchronous updating. In this mode, the called transaction does not &lt;/P&gt;&lt;P&gt;wait for any updates it produces to be completed. It simply passes the &lt;/P&gt;&lt;P&gt;updates to the SAP update service. Asynchronous processing therefore&lt;/P&gt;&lt;P&gt; usually results in faster execution of your data transfer program.&lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;Asynchronous processing is NOT recommended for processing any larger &lt;/P&gt;&lt;P&gt;amount of data. This is because the called transaction receives no completion &lt;/P&gt;&lt;P&gt;message from the update module in asynchronous updating. The calling data &lt;/P&gt;&lt;P&gt;transfer program, in turn, cannot determine whether a called transaction ended &lt;/P&gt;&lt;P&gt;with a successful update of the database or not. &lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;If you use asynchronous updating, then you will need to use the update &lt;/P&gt;&lt;P&gt;management facility (Transaction SM12) to check whether updates have &lt;/P&gt;&lt;P&gt;been terminated abnormally during session processing. Error analysis and &lt;/P&gt;&lt;P&gt;recovery is less convenient than with synchronous updating.&lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;S Synchronous updating. In this mode, the called transaction waits for any&lt;/P&gt;&lt;P&gt; updates that it produces to be completed. Execution is slower than with &lt;/P&gt;&lt;P&gt;asynchronous updating because called transactions wait for updating to be&lt;/P&gt;&lt;P&gt; completed. However, the called transaction is able to return any update error&lt;/P&gt;&lt;P&gt; message that occurs to your program. It is much easier for you to analyze &lt;/P&gt;&lt;P&gt;and recover from errors. &lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;L Local updating. If you update data locally, the update of the database will &lt;/P&gt;&lt;P&gt;not be processed in a separate process, but in the process of the calling &lt;/P&gt;&lt;P&gt;program. (See the ABAP keyword documentation on SET UPDATE TASK LOCAL&lt;/P&gt;&lt;P&gt; for more information.)&lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;When you transfer data in ABAP, you have three options to submit the data for the data transfer. Only the &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;first two methods can be recommended without reservation. The third method, by way of CALL DIALOG, is &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;outmoded. CALL DIALOG is less comfortable than the other methods. You should use it only if you must.&lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;Use the CALL TRANSACTION USING statement&lt;/P&gt;&lt;P&gt;Summary: With CALL TRANSACTION USING, the system processes the data more quickly than with batch input &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;sessions. Unlike batch input sessions, CALL TRANSACTION USING does not automatically support interactive &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;correction or logging functions.&lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;Your program prepares the data and then calls the corresponding transaction that is then processed &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;immediately.&lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;The most important features of CALL TRANSACTION USING are:&lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;Synchronous processing &lt;/P&gt;&lt;P&gt;Transfer of data from an individual transaction each time the statement CALL TRANSACTION USING is called &lt;/P&gt;&lt;P&gt;You can update the database both synchronously and asynchronously&lt;/P&gt;&lt;P&gt;The program specifies the update type&lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;Separate LUW (logical units of work) for the transaction&lt;/P&gt;&lt;P&gt;The system executes a database commit immediately before and after the CALL TRANSACTION USING statement &lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;No batch input processing log&lt;/P&gt;&lt;P&gt;Create a session on the batch input queue.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Reward if helpful,&lt;/P&gt;&lt;P&gt;Karthik&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 03 Oct 2007 07:59:41 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/bdc/m-p/2837900#M664558</guid>
      <dc:creator>former_member189629</dc:creator>
      <dc:date>2007-10-03T07:59:41Z</dc:date>
    </item>
    <item>
      <title>Re: BDC</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/bdc/m-p/2837901#M664559</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;A BDC done with sessions is always synchronus.&lt;/P&gt;&lt;P&gt;A BDC with call transaction is by default asynchronus&lt;/P&gt;&lt;P&gt;unless you define it explicitly as &lt;/P&gt;&lt;P&gt;call transaction 'XXXX' ...... update 'S'.&lt;/P&gt;&lt;P&gt;( If you donot define update option it is defaulted to "A" ).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 03 Oct 2007 08:01:15 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/bdc/m-p/2837901#M664559</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-10-03T08:01:15Z</dc:date>
    </item>
  </channel>
</rss>

