The objective of this document is aimed at explaining the concept of logical unit of work in SAP. I assume that this will be a good read for my fellow readers.
The main purpose of the logical unit of work is to ensure data consistency in the R/3 systems. Let us consider that there is a complex R/3 transaction that involves a series of dialog steps; during the execution of one such dialog step at the middle of the transaction the data involved will lack completeness & will therefore be inconsistent. When talking about of logical unit of work we must note the following points initially.
A database LUW is work unit consisting of database operations (INSERT, UPDATE, MODIFY & DELETE) that it used to make the database changes. The final database LUW of a SAP LUW is used to make the changes to the database, the changes to the database is not made until after the database commit. The database LUW is executed in a special kind of work process called the update work process.
A SAP LUW is a logical unit work that spans over several dialog steps. Let us consider a complex R/3 transaction of n screens; where each screen has its own DB LUW involving database operations and are logically related to each other. It is important that the changes to the database for this complex transaction must be made all at once or it must be rolled back all for the data consistency; that is where the SAP LUW becomes critical in maintaining a logical relationship between several DB LUWs (dialog phases) & making all the changes to the database in the final DB LUW. SAP LUW uses the bundling technique to achieve the same. There are several possibilities of bundling technique and one of them is bundling the database changes using a function module call in the UPDATE TASK.
A CALL FUNCTION…IN UPDATE TASK is one of the bundling techniques to achieve all the database changes in the last DB LUW of the SAP LUW. The open SQL statements for database changes are placed in the function module instead of placing them in the code, using the addition UPDATE TASK ensures that the function module is not executed until COMMIT WORK is found in the program. At COMMIT WORK the function module calls with UPDATE TASK are executed in a special work process called update work process and the changes to the database is executed in the final DB LUW of the SAP LUW.
Let us consider there is one R/3 transaction calling another R/3 transaction and as well as calling some update function module. There is some typical behavior that can be noted for this particular scenario.
DATA: gv_x TYPE i.
gv_x = 1.
CALL FUNCTION UPD_FUNC IN UPDATE TASK
EXPORTING
IM_X = gv_x.
gv_x = 2.
CALL FUNCTION UPD_FUNC IN UPDATE TASK
EXPORTING
IM_X = gv_x.
gv_x = 3.
COMMIT WORK.
What will be the value of gv_x at the COMMIT WORK?
No, the value of gv_x will not be 3; when commit is executed by the system the value of gv_x that will be passed is dependent at the point of function call therefore during the first call the value of gv_x will be 1 & during the second call the value of gv_x will be 2.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
6 | |
5 | |
3 | |
3 | |
2 | |
2 | |
2 | |
2 | |
1 | |
1 |