Symptom: The following issue occurs whenever you run a Bapi with asynchronous updates more than once in a single LUW. Usually, the Bapi runs fine during the first run, but in the next run it appears to be a lock of the database.
Example error messages – “RU 806 Invalid call of a method for confirmation/ “Confirmation cannot be successfully saved”.
Problem Description: For example, if the following BAPI is used to save multiple confirmations.
CALL FUNCTION 'BAPI_ALM_CONF_CREATE'
EXPORTING
POST_WRONG_ENTRIES = '1'
TESTRUN = TESTRUN
IMPORTING
RETURN = ls_return
TABLES
TIMETICKETS = TIMETICKETS
DETAIL_RETURN = lt_conf_return.
When the user tries to enter one incorrect record and one correct record on the same form and then clicks the save button, the correct record gets successfully saved. The user is now supposed to correct the invalid field of the second record and click on the save button again.
At this step it gives errors like - "RU 806 + Invalid call of a method for confirmation" or "Confirmation cannot be successfully saved".
The TIMETICKETS table has only the corrected record during the second run but the work order somehow gets locked during the first bapi run resulting in an unsuccessful save action.
Solution:
The solution is to execute the statement SET UPDATE TASK LOCAL just before calling 'BAPI_ALM_CONF_CREATE' (or before any other BAPI with asynchronous update). As a result, all the updates will then be made in the same task.
SET UPDATE TASK LOCAL.
CALL FUNCTION 'BAPI_ALM_CONF_CREATE'
EXPORTING
POST_WRONG_ENTRIES = '1'
TESTRUN = TESTRUN
IMPORTING
RETURN = ls_return
TABLES
TIMETICKETS = TIMETICKETS
DETAIL_RETURN = lt_conf_return.
COMMIT WORK.
With this the function module is not executed immediately, but is scheduled for execution in an update work process. The actual execution is triggered by the statement COMMIT WORK.
In a local update, the update program is run by the same work process that processed the request. This kind of update is useful when you want to reduce the amount of access to the database from one LUW.
Using SET UPDATE TASK LOCAL is better for background processing when you want the program to continue processing only when the update has actually finished. The dialog user has to wait for the update to finish before entering further data.
