2/28/24, 1:17 PM Fighting problems of asynchronous processing in ABAP | Hello World!

Hello World!
My thoughts on SAP development, technology and more…

Fighting problems of asynchronous processing

in ABAP
Posted on January 31, 2011

In most Standard SAP applications, changes to data are not directly (“synchronously”) written back to the database.
Instead, SAP Netweaver buffers these changes and writes them at a later time (“asynchronously”).

On many occasions, you won’t notice this asynchronous nature and it won’t cause any problems. Even
better, asynchronous processing is good for performance! However, sometimes you’ll want to continue
processing only when the database is completely up-to-date. For example:

When you are trying to get additional data not returned by the BAPI or Function Module you just called;
When you want to run another BAPI or Function Module that depends on the database being completely up to
date after the previous call.

Especially in interface programming, I have seen some cumbersome solutions. The good news is: There are good
solutions to enforce synchronous processing. This post lists these options.

The bad solution

During development or even during testing, some developers notice the asynchronous behaviour and try to fight it –
with varying success. One approach I have seen (and even used myself!) is to use a WAIT statement to let the
program in the current work process sleep for several seconds:

* Step 1: Call your functions and BAPI’s

CALL FUNCTION 'BAPI_OUTB_DELIVERY_CHANGE'
DESTINATION 'NONE'
EXPORTING
header_data = ls_header_data
header_control = ls_header_control
delivery = lv_bapi_delivery
TABLES return = lt_return.

* Step 2: Wait for some period of time that you see fit
WAIT UP TO 15 SECONDS.

While this example functions, there are some serious downsides to this ‘solution’:

Rather than changing the processing mode itself, it is fighting a symptom of asynchronous processing;
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
It is difficult to decide how long you should wait. A time interval that is long enough on your oversized
To find out more, including how to control cookies, see here: Cookie Policy
Close and accept
development system, might be too short on your crowded production system.

https://wilcomenge.wordpress.com/2011/01/31/synchronous-processing-abap/ 1/8
2/28/24, 1:17 PM Fighting problems of asynchronous processing in ABAP | Hello World!
The performance of your system and the overall user experience goes down the drain as the current
process becomes unresponsive and waits for a period that is almost certainly far too long.

The good Solutions

The following solutions can be successful in changing an asynchronous processing mode to a synchronous
processing mode:

Solution 1: Set Update task local

By using the SET UPDATE TASK LOCAL statement, SAP Netweaver executes database updates in the current work
process instead of a separate background process. Then, by using the COMMIT WORK statement, you force all
updates in the current process to finish before continuing.

* Step 1: Set all update task to the local session

SET UPDATE TASK LOCAL.

* Step 2: Call your functions and BAPI’s

CALL FUNCTION 'BAPI_OUTB_DELIVERY_CHANGE'
EXPORTING
header_data = ls_header_data
header_control = ls_header_control
delivery = lv_bapi_delivery
TABLES return = lt_return.

* Step 3: Commit the changes locally

COMMIT WORK AND WAIT.

In most situations, all databases updates are finished after this point.

Solution 2: Execute in a separate session

Using a two-step approach it is possible to achieve synchronous processing:

1. Force the execution of a Function Module or BAPI in a new, separate session.

2. Explicitly close that session so that all relevant database commits are actually triggered before continuing.

The following code demonstrates this strategy for a standard BAPI:

* Step 1: Create a separate session. This is done by calling

* your BAPI or Function Module from remote destination ‘NONE’
CALL FUNCTION 'BAPI_OUTB_DELIVERY_CHANGE'
DESTINATION 'NONE'
EXPORTING
header_data = ls_header_data
header_control = ls_header_control
delivery = lv_bapi_delivery
TABLES
return = lt_return.

* Commit the changes within this session

CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
DESTINATION 'NONE'
EXPORTING wait = 'X'.
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy
* Step 2: Explicitly close the session.

https://wilcomenge.wordpress.com/2011/01/31/synchronous-processing-abap/ 2/8
2/28/24, 1:17 PM Fighting problems of asynchronous processing in ABAP | Hello World!
* Main effect: All commits of all work processes in the
* the remote session will executed
* Side effects:
* -A next RFC call will be started in a new session.
* -This resets the globals data in the function group.
CALL FUNCTION 'RFC_CONNECTION_CLOSE'
EXPORTING destination = 'NONE'
EXCEPTIONS OTHERS = 0.

It is necessary to use the BAPI_TRANSACTION_COMMIT Function Module instead of the regular COMMIT WORK
AND WAIT statement. This is because the COMMIT has to take place in the ‘remote’ work process and not in the
local process.

Again, after this point, all database updates are finished.

This entry was posted in ABAP and tagged development, geek, how-to, technical by wilcomenge. Bookmark the
permalink [https://wilcomenge.wordpress.com/2011/01/31/synchronous-processing-abap/] .

14 THOUGHTS ON “FIGHTING PROBLEMS OF ASYNCHRONOUS PROCESSING IN ABAP”

Peter
on March 21, 2011 at 14:14 said:

Hi
thanks

is the DESTINATION ‘NONE’ actually needed in the first solution or just the 2nd?

Peter

wilcomenge
on March 21, 2011 at 15:12 said:

Nope, you’re right! I admit: its a typo and I have just fixed it.

Bernd
on April 4, 2011 at 13:37 said:

Heey Wilco,

Thanx for the information.

It is working great :-).

The second solution was just where I wass looking for.

Bernd
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

https://wilcomenge.wordpress.com/2011/01/31/synchronous-processing-abap/ 3/8
2/28/24, 1:17 PM Fighting problems of asynchronous processing in ABAP | Hello World!

manuelecheverry
on October 2, 2014 at 00:14 said:

Great post! I used solution 1 and worked fine for me

Abaper
on January 13, 2015 at 07:36 said:

which best solution or best performance ?

wilcomenge
on May 18, 2015 at 09:58 said:

The first solution has the least impact. Normally, the actual DB update is done in a seperate process.
This way, the user doesn’t have to wait for the actual DB operation. But: in some cases you *do* want
to wait for the DB update to finish. In that case, try one of the solutions mentioned here.

Sravanthi
on May 17, 2015 at 05:00 said:

I have used the first solution you suggested. But, instead of COMMIT WORK AND WAIT, I used
BAPI_TRANSACTION_COMMIT (without a wait). Does that make a difference?

The problem still persists. In the production system, sometimes the release does not commit to database.
Please note that it is happening randomly ( like once or twice in a month), not able to find the cause.

Also, I am working on a single system, so there is no remote system. In that case, does it make sense to try
the second solution? (RFC_CONNECTION_CLOSE)

wilcomenge
on May 18, 2015 at 10:19 said:

Using COMMIT WORK AND WAIT or BAPI_TRANSACTION_COMMIT shoulnd’t make a real differ-
ence, since the last one is just a wrapper for COMMIT WORK.

It is indeed possible that the problem in my blog occurs randomly: Sometimes the database is under
light load and the update happens fast enough, sometimes the update is slower. However: in all
cases, the update occurs eventually. Is this also the case in your situation?

On you last remark: Yes, it makes sense to try the second solution (RFC_CONNECTION_CLOSE),
even in a single system: You actually do a remote call the the same system, forcing all update logic in

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

https://wilcomenge.wordpress.com/2011/01/31/synchronous-processing-abap/ 4/8
2/28/24, 1:17 PM Fighting problems of asynchronous processing in ABAP | Hello World!
a new session. This way, when the other session has been closed, you can be sure that all database
operations are finished.

Sravanthi
on May 17, 2015 at 05:00 said:

I have used the first solution you suggested. But, instead of COMMIT WORK AND WAIT, I used
BAPI_TRANSACTION_COMMIT (without a wait). Does that make a difference?

The problem still persists. In the production system, sometimes the release does not commit to database.
Please note that it is happening randomly ( like once or twice in a month), not able to find the cause.

Also, I am working on a single system, so there is no remote system. In that case, does it make sense to try
the second solution? (RFC_CONNECTION_CLOSE).

Hariny
on October 18, 2017 at 08:04 said:

Thanks for the post. When I use the first solution, I get a GUI screen for Update control and each time in loop
I need to press back button. Any idea how to avoid this?

wilcomenge
on October 18, 2017 at 09:13 said:

That is probably caused by some of the code that you are calling. I think you should try one of the
other solutions mentioned in the post. Your mileage may vary.

mks49443
on February 8, 2018 at 01:06 said:

HI Wilcomenge,
Thanks for the nice blog.
I got a problem here.. I am using the Solution 1, for example if 5 items in a sales order it creates 4 items and
one item comes out an error message ‘Sales document XXXX is currently being processed by user’ .
Please advise the solution to resolve this isues.
Warm regards
Chandra

wilcomenge
on February
Privacy & Cookies: This site uses cookies. 8,
By2018 at 08:45
continuing said:this website, you agree to their use.
to use
To find out more, including how to control cookies, see here: Cookie Policy

https://wilcomenge.wordpress.com/2011/01/31/synchronous-processing-abap/ 5/8
2/28/24, 1:17 PM Fighting problems of asynchronous processing in ABAP | Hello World!
It sounds like you are first trying to save the order header and create the items in subsequent Function
Module calls. Is that correct? I would expect that whatever Function Module you are calling is able to
create the header and all items in one call, preventing the application lock.

mks49443
on February 9, 2018 at 01:22 said:

Thanks for the quick response.

My scenario are as follows:
1. Sales order with one line items always comes from legacy system and hits the PI and then to SAP.
2. Some time there will be more than one line item or may be 2 to 30 line times belonging to same sales order
that means one interface (1 record for one line item with header, if 30 line items it would be 30 interfaces ie 30
records. ) . SAP is processing one record at one time. Suppose 30 records hits SAP it will be parallel
processing and it opens up 4 to 6 Dialogue processing in SM 50 and try to create and insert sales orders at
the same time by each CPU. In this case one sales order is created with may be 15 to 20 line items and rest
of the others fails with a message

‘Sales document XXX is currently being processed by user ‘

I have exhausted all the solutions and implemented your first solution but still no joy.
The code snippets is as shown below:
Please advise.
Warm regards
Chandra

CREATION OF ORDER
SET UPDATE TASK LOCAL.

CALL FUNCTION ‘BAPI_SALESORDER_CREATEFROMDAT2’

DESTINATION ‘NONE’
EXPORTING
order_header_in = ls_order_header
convert = lc_x “CONVERT – Conversion of Partner Function + Order Type
IMPORTING
salesdocument = lv_vbeln
TABLES
return = lt_bapiret2
order_items_in = lt_order_items
order_partners = lt_order_partners
order_schedules_in = lt_order_schedules
order_text = lt_order_text
extensionin = lt_extensionin
partneraddresses = lt_partneraddresses.
******************************************************************
*Lock current Order to ensure parallel processing does not result in error
do 10 times.
CALL FUNCTION ‘ENQUEUE_EVVBAKE’
EXPORTING
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
vbeln = lv_VBELN
To find out more, including how to control cookies, see here: Cookie Policy
EXCEPTIONS

https://wilcomenge.wordpress.com/2011/01/31/synchronous-processing-abap/ 6/8
2/28/24, 1:17 PM Fighting problems of asynchronous processing in ABAP | Hello World!
foreign_lock = 02
system_failure = 03.
* Check whether lock was successful
IF sy-subrc = 0.
* Successful lock so exit do loop
CALL FUNCTION ‘DEQUEUE_EVVBAKE’
EXPORTING
VBELN = lv_VBELN.
EXIT.
ELSE.
* Unsuccessful lock so wait 1 second and retry
WAIT UP TO 1 SECONDS.
ENDIF.

ENDDO.
LOOP AT lt_bapiret2 INTO ls_bapiret2.
APPEND ls_bapiret2 TO return_tab.
* Check if there is an error in BAPI returned messages
IF ls_bapiret2-type = lc_e.
lv_error = lc_x.
* Begin of insert by MarkYang LD4K900464
* rollback material data created above
CALL FUNCTION ‘BAPI_TRANSACTION_ROLLBACK’.
* End of insert LD4K900464
ELSE.
CALL FUNCTION ‘BAPI_TRANSACTION_COMMIT’
DESTINATION ‘NONE’
EXPORTING
wait = ‘X’
IMPORTING
return = ls_bapiret2.
ENDIF.
ENDLOOP.

CHANGE OF ORDER

SET UPDATE TASK LOCAL.

CALL FUNCTION ‘BAPI_SALESORDER_CHANGE’
DESTINATION ‘NONE’
EXPORTING
salesdocument = lp_vbeln
order_header_inx = ls_order_header_inx
TABLES
return = lt_bapiret2
order_item_in = lt_order_items
order_item_inx = lt_order_items_inx
order_text = lt_order_text
schedule_lines = lt_order_schedules
schedule_linesx = lt_order_schedules_inx.
**Lock current Order to ensure parallel processing does not result in error
do 20 times.
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
CALL FUNCTION ‘ENQUEUE_EVVBAKE’
To find out more, including how to control cookies, see here: Cookie Policy
EXPORTING

https://wilcomenge.wordpress.com/2011/01/31/synchronous-processing-abap/ 7/8
2/28/24, 1:17 PM Fighting problems of asynchronous processing in ABAP | Hello World!
vbeln = lp_VBELN
EXCEPTIONS
foreign_lock = 02
system_failure = 03.
* Check whether lock was successful
IF sy-subrc = 0.
* Successful lock so exit do loop
CALL FUNCTION ‘DEQUEUE_EVVBAKE’
EXPORTING
VBELN = lp_VBELN.
EXIT.
ELSE.
* Unsuccessful lock so wait 1 second and retry
WAIT UP TO 1 SECONDS.
ENDIF.
ENDDO.

LOOP AT lt_bapiret2 INTO ls_bapiret2.

APPEND ls_bapiret2 TO return_tab.
* Check if there is an error in BAPI returned messages
IF ls_bapiret2-type = lc_e.
lv_error = lc_x.
* rollback material data created above
CALL FUNCTION ‘BAPI_TRANSACTION_ROLLBACK’.
else.
CALL FUNCTION ‘BAPI_TRANSACTION_COMMIT’
DESTINATION ‘NONE’
EXPORTING
wait = ‘X’
IMPORTING
return = ls_bapiret2.
ENDIF.
ENDLOOP.

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

https://wilcomenge.wordpress.com/2011/01/31/synchronous-processing-abap/ 8/8