All About – ‘SET UPDATE TASK LOCAL’
In ABAP, usually the FM and Subroutine can be called in Update Task. The function module should be an update function module. When the FM is called in update task in a program, the FM is not executed at the moment but it is written to the standard table and when in the program an explicit statement – COMMIT WORK or COMMIT WORK AND WAIT occurs then the update FM call stored in the database resume its execution and in another session called as update session.
Here the main program runs in normal abap session and the update FM runs in update session. The COMMIT WORK decides an asynchronous where as COMMIT WORK AND WAIT makes synchronous process.
In addition to this update FM and commit work/commit work and wait, sometimes the abap command- SET UPDATE TASK LOCAL can be maintained. In such a case, the FM ‘XXXX’ in update task ( HIGH Priority- Update type as – Start Immed or Immed Start, No Restart), is not written to the standard database and then when commit work/commit work and wait occurs it is not executed in the update session but in the same session of the main program. Again the commit work/commit work and wait, remains work as same as – commit work ( only synchronous process).
More over if a Update FM is of type Start Delayed( Low Priority), then SET UPDATE TASK LCOAL doesn’t make any sense, i.e always the update FM call is written to the standard table and a commit work/commit work and wait statement executes such delayed update FM in update task.
The below post shows this process:
Here we have a Update FM with high priority( not a delayed one)
Body of the FM- Normally it carries data base SQL statements but for the demo it is fine. Put a debug point.
The update FM call normally written in header and item table and TABLE- VBMOD where we can check the FM calls.
A small program that calls the FM in update task and then a commit work. Put break point and execute the program.
The program stopped at the debug point. From the menu – Settings – Select Update Debugging.
Here we have the update debugger is active. Press F5.
The call doesn’t go inside the FM and we are at our statement’ COMMIT WORK’ .
The update FM call is available in the table VBMOD.
Press F5 .
Here we have two debugger session, one is for the main program and one for the update FM. Finish execution of the update FM by pressing F8 .
Now we are in the man program and the update FM removed from the database as the execution finished. Finish the execution of the main program.
So we have the output.
Perfect. Lets put SET UPDATE TASK LOCAL in the program and start execution again.
The debugger is on and press F5.
The debug point is at COMMIT WORK statement and the update FM call is not written in the DB table VBMOD. Press F5.
So commit work now starts executing the update FM not in the update session but in the same session of the main session( actually it is internal session of the main session).
So here we have the output of the update FM executed locally and then press F3 to go back.
We are here in the main program and press F8 to finish execution.
Here is the program output.
Now change the update FM as – Start Delayed( Low Priority)
Execute the program.
Though – it is set as ‘SET UPDATE TASK LOACL’ because the updated FM is delayed one, it is written to the DB VBMOD and when commit work/ and wait will occur it will start its execution.
Now if the Update FM is type – Start Immed/ Start Immed, No Restart and used in a program with SET UPDATE TASK LOCAL’, the statement COMMIT WORK OR COMMIT WORK AND WAIT behaves synchronously like COMMIT WORK AND WAIT.
Thanks for this great article. One small query – Isn’t ‘commit work’ async while ‘and wait’ is sync? The comment in the last screenshot seems to be the opposite.