Let’s skip the definition of LUV ( LOVE ) and jump to LUW .
A “LUW” (logical unit of work) is the span of time during which any database updates must be performed Either they are all performed ( committed ) , or they are all thrown away ( rolled back ).
Ppl always confused between database LUW and SAP LUW.
Starting with DATABASE LUW :
The Open SQL statements INSERT, UPDATE, MODIFY, and DELETE allows you to program database changes that extend over several dialog steps. Even if you have not explicitly programmed a database commit, the implicit database commit that occurs after a screen has been processed concludes the database LUW. The following diagram shows the individual database LUWs in a typical screen sequence:
So let’s say in case we have a requirement where you want ALL or Nothing .
In simple word at any step user can Rollback all the DB changes!!! That’s where SAP LUW comes into picture. What is does is , it bundles all the changes throughout the business transaction and commit them in single go to database when everything is fine.
So we got three super heroes to help you out for bundling J
- Bundling using Function Modules for Updates
If you call a function module using the CALL FUNCTION… IN UPDATE TASK statement, the function module is flagged for execution using a special update work process. This means that you can write the Open SQL statements for the database changes in the function module instead of in your program, and call the function module at the point in the program where you would otherwise have included the statements. When you call a function module using the IN UPDATE TASK addition, it and its interface parameters are stored as a log entry in a special database table called VBLOG.
The function module is executed using an update work process when the program reaches the COMMIT WORK statement. After the COMMIT WORK statement, the dialog work process is free to receive further user input. The dialog part of the transaction finishes with the COMMIT WORK statement. The update part of the SAP LUW then begins, and this is the responsibility of the update work process. The SAP LUW is complete once the update process has committed or rolled back all of the database changes.
- Bundling Using Subroutines
The statement PERFORM ON COMMIT calls a subroutine in the dialog work process. However, it is not executed until the system reaches the next COMMIT WORK statement. Here, as well, the ABAP statement COMMIT WORK defines the end of the SAP LUW, since all statements in a subroutine called with PERFORM ON COMMIT that make database changes are executed in the database LUW of the corresponding dialog step.
- Bundling Using Function Modules in Other R/3 Systems
Function modules that you call using CALL FUNCTION… IN BACKGROUND TASK DESTINATION… are registered for background execution in another R/3 System when the program reaches the next COMMIT WORK statement (using Remote Function Call). After the COMMIT WORK, the dialog process does not wait for these function modules to be executed (asynchronous update). All of the function modules that you register in this way are executed together in a single database LUW. These updates are useful, for example, when you need to maintain identical data in more than one database.
Now sometimes we need to start our own local LUW inside already running LUW without effecting the main LUW.Something like..
Let’s discuss possible ways to do that???
How about calling a Function module in update task??
It will start a new LUW, but you can’t commit your LUW inside it, As you can’t write commit work inside your LUW.
How about Calling a Function module in Background task something like :
REPORT ZTEST_MAIN.
TABLES : ZEMPLOYEE.
ZEMPLOYEE–EMPLOYEE_ID = 0034.
ZEMPLOYEE–EMPLOYEE_FNAM = ’10/07/2011′.
ZEMPLOYEE–EMPLOYEE_LNAM = ‘Main’.
CALL FUNCTION ‘ZTEST_UPDATEFM1’ IN UPDATE TASK
EXPORTING
ZEMPLOYEE = ZEMPLOYEE.
call function ‘ZTEST_UPDATEFMJOB’ IN BACKGROUND task AS SEPARATE UNIT DESTINATION ‘NONE’
exporting
ZEMPLOYEE = ZEMPLOYEE.
write : / ‘hello’.
Advantages: It will start a separate LUW
But To trigger ZTEST_UPDATEFMJOB in Background needs a commit work in the calling program. So again it’s not our requirement.
-
How about SUBMIT and RETURN.
REPORT ZTEST_SUBMIT.
TABLES : ZEMPLOYEE.
ZEMPLOYEE–EMPLOYEE_ID = 0034.
ZEMPLOYEE–EMPLOYEE_FNAM = ’10/07/2011′.
ZEMPLOYEE–EMPLOYEE_LNAM = ‘Main’.
CALL FUNCTION ‘ZTEST_UPDATEFM1’ IN UPDATE TASK
EXPORTING
ZEMPLOYEE = ZEMPLOYEE.
SUBMIT ZTEST_SUBMIT1 AND RETURN. “a new LUW
write : / ‘hello’.
Advantage: perfect!!!! But issue is passing of the data to Submitted report. You might need to use EXPORT TO MEMORY or IMPORT TO MEMROY if you want to pass tables and etc. To the called program (If its RANGE tables or normal parameters that fine) u can use VIA SELECTION-SCREEN option
-
Use parallel processing
It’s like calling Remote enabled Function module in asynchronous task.
Check out the below article to know more about it.
http://sapignite.com/learn-parallel-processing-in-abap/
Note: Theory says that calling a Remote enabled Function module in separate task does implicit commit and complete the current SAP LUW.But till now practical does not says it.. J !!!!! so Try it out for yourself.
Please feel free to comment on this and let’s discuss more about LUW .
