LUW example

[Former Member]

hello SAP Gurus,

can u explain me about LUW by using an example ?

Regards,

Vijaya.

[Former Member]

Vijaya,

SAP LUW 
Related sequence of programming units, whose execution, for example in dialog steps or in Remote Function Calls can be distributed across several work processes, but their database changes are updated within one single database LUW. SAP LUWs are implemented by bundling techniques, in which programming units such as update function modules or sub-routines are registered in different work processes but executed by one single work process. An SAP LUW is completed by the Open SQLstatement COMMIT WORK. Changes within one SAP LUW can be undone by the open SQLstatement ROLLBACK WORK.

[Former Member]

LUW stands for a Logical unit of work.

Let is take an example of a sales order.

One sales order will have its data stored in different tables like VBAK, VBAP, VBPA, VBEP, VBUK and many other tables.

Assume that you have updated VBAK table in you code and commited the work. and later the program goes for a dump beofre the data gets saved in the other related tables.

Then those tables will not be filled.

This leads to a inconsistency of data.

Hence the commit should happen only when all the logically relevant tables get updated.

This is called a LOGICAL UNIT of WORK.

Ths system commits the database changes only after the succeful completion of the LUW, else its rollsback the changes.

Regards,

ravi

[Former Member]

Hi Vijaya lakshmi,

Please check this link

http://help.sap.com/saphelp_nw04/helpdata/en/41/7af4bfa79e11d1950f0000e82de14a/content.htm

http://help.sap.com/saphelp_nw70/helpdata/en/41/7af4bca79e11d1950f0000e82de14a/content.htm

Best regards,

raam

[Former Member]

Hi Vijaya,

An SAP LUW is a logical unit consisting of dialog steps, whose changes are written to the database in a single database LUW. There are various bundling techniques that you can use to ensure that all of the database updates belonging to an SAP LUW are made in the same single database LUW.

Externally-called procedures do not open a new SAP LUW.

However, when you start a new executable program or transaction, a new SAP LUW starts. Database updates belonging to these programs are collected in their own database LUW. If the new program does not return control to the calling program, the SAP LUW of the old program concludes when the new program is called. If, on the other hand, the new program does return control to the calling program, the new SAP LUW runs parallel to the SAP LUW of the calling program.

The database changes that occur within a database LUW are not actually written to the database until after the database commit. Until this happens, you can use a database rollback to reverse the changes. In the SAP System, database commits and rollbacks can be triggered either implicitly or using explicit commands.

Implicit Database Commits

A work process can only execute a single database LUW. The consequence of this is that a work process must always end a database LUW when it finishes its work for a user or an external call. Work processes trigger an implicit database commit in the following situations:

· When a dialog step is completed

Control changes from the work process back to the SAP GUI.

· When a function module is called in another work process (RFC).

Control passes to the other work process.

· When the called function module (RFC) in the other work process ends.

Control returns to the calling work process.

· When a WAIT statement interrupts the work process.

Control passes to another work process.

· Error dialogs (information, warning, or error messages) in dialog steps.

Control passes from the work process to the SAP GUI.

Explicit Database Commits

There are two ways to trigger an explicit database commit in your application programs:

· Call the function module DB_COMMIT

The sole task of this function module is to start a database commit.

· Use the ABAP statement COMMIT WORK

This statement starts a database commit, but also performs other tasks (refer to the keyword documentation for COMMIT WORK).

Implicit Database Rollbacks

The following cases lead to an implicit database rollback:

· Runtime error in an application program

This occurs whenever an application program has to terminate because of an unforeseen situation (for example, trying to divide by zero).

· Termination message

Termination messages are generated using the ABAP statement MESSAGE with the message type A or X. In certain cases (updates), they are also generated with message types I, W, and E. These messages end the current application program.

Explicit Database Rollbacks

You can trigger a database rollback explicitly using the ABAP statement ROLLBACK WORK. This statement starts a database rollback, but also performs other tasks (refer to the keyword documentation for ROLLBACK WORK).

From the above, we can draw up the following list of points at which database LUWs begin and end.

A Database LUW Begins

· Each time a dialog step starts (when the dialog step is sent to the work process).

· Whenever the previous database LUW ends in a database commit.

· Whenever the previous database LUW ends in a database rollback.

A Database LUW Ends

· Each time a database commit occurs. This writes all of the changes to the database.

· Each time a database rollback occurs. This reverses all of the changes made during the LUW.

For more help u can go on to

Thnks.