topic LUW in Application Development and Automation Discussions

LUW

Former Member — Sat, 22 Mar 2008 06:04:39 GMT

hi experts,

can u please explain me following questions

1.what is LUW ?

2. what is SAP LUW.?

3.Every data base is providing by default DB LUW then why SAP is providing SAP LUW?

4.what are lock objects?

5.if SAP is providing by default lock objects why we have to use?.when we have to use?

please provide explanations for above questions?

Thanks & Regards,

Re: LUW

Former Member — Sat, 22 Mar 2008 07:28:51 GMT

The R/3 system is multi user system and many users access the same information at the same time, which is mainly DATA. Consider the case where one user is modifying a record, and second user is trying to delete the same record. If the second user is successful in deleting the record then the first user will face problem for modifying the record that is already deleted. The avoid such situation, R/3 system has provided Logical Unit of Work, which is defined as a locking mechanism to protect transaction integrity. Of course, there are other measures, which ensures data integrity like check table i.e. foreign key relationship. Within SAP system there are three types of transaction and may be distinguished as:

• Database transaction known as LUW. It can be defined as a period in which operation requested must be performed as a unit, i.e. all or nothing operation. At the end of LUW, either of the database changes are committed or rolled back.

• Update transaction or SAP LUW. One SAP LUW can have several databases LUW. So a set of a database is either committed or rolled back. The special ABAP/4 command COMMIT WORK, marks the end of a SAP LUW.

• ABAP/4 transaction. Is made up of a set of related task combined under one transaction code. ABAP/4 transactions are for programming environment, in which ABAP/4 transaction functions like one complete object containing screens, menus and transaction codes.

R/3 system has provided in built locking mechanism, which defines the Logical Unit of Work. Also user can set his own locking mechanism. The LUW starts when a lock entry in the system table is created, and it ends when the lock is released.

To provide the user the facility to communicate with the table in order to modify or delete or insert data, R/3 has provided tool called SCREEN PAINTER. This tool allows you to design screen, process screen through program and update the database table. SAP has provided one and only one way to update the database table, i.e. transaction. Though you can update database table by using open SQL statement through program, SAP usually doesn’t recommend this kind of updating. Many standard transactions are available to update standard table but if the need arises, the developer should be able to develop new transaction, which allows the updating of database tables. This can be achieved by using various components of screen painter.

Types of LUWs:

Database transaction or LUW.

Update transaction or SAPLUW.

ABAP/4 Transaction.

database transaction

Database transaction or LUW is defined as a period in which operation requested must be performed as one unit.

At the end of LUW, either the database changes are committed or rolled back.

SAP LUW

One SAP LUW can have several databases LUW. So a set of database transactions either committed or rolled back.

The special ABAP/4 command ‘Commit work’ marks the end of SAP LUW.

ABAP/4 Transaction

It is made up of a set of related task combined under one transaction code.

ABAP/4 transaction functions like one complete object containing screens, menus and transaction code.

Check this documentation..

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

Thnaks,

Pavan

Re: LUW

Former Member — Sat, 22 Mar 2008 10:23:13 GMT

Hi Gopi,

LUW: Indivisible business process, which is performed either completely or not at all.

Related sequence of programming units which when executed can be distributed across several work processes (several database LUWs) as with, for example, dialog steps or remote function calls. However, database changes are made within one single database LUW. SAP LUWs are carried out by grouping techniques in which update function modules or subroutines, among other things, are registered in various work processes and executed by one single work process. An SAP LUW is completed by the open SQL statement COMMIT WORK. Changes within an SAP LUW can be undone with the open SQL statement ROLLBACK WORK.

An SAP LUW usually has the same function as a dialog transaction (which maps a business process) and maps database changes made in dialog transactions to an update. A dialog transaction can, however, also include several SAP LUWs.

Lock bjects Are Used to Synchronys Access to same data by more than One user.

Suppose You that u have opened the Program and if any one is trying to access the same by another user then it will show the same program in Display Mode. so SAP will Automaticaly take care of the Things About Locking.

Suppose U Have Created A Transaction Code. Suppose U If u want Give Authorization Some User Only Than u have to Use Lock Objects.

Please go through this link for further info:

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/8bde9690-0201-0010-ed8e-8787eae24388#q-2

Hope it solves your concern...:)

Regards,

Eshwar.

Re: LUW

Former Member — Mon, 24 Mar 2008 09:00:40 GMT

Hi,

Database Logical Unit of Work (LUW)

From the point of view of database programming, a database LUW is an inseparable sequence of database operations that ends with a database commit. The database LUW is either fully executed by the database system or not at all. Once a database LUW has been successfully executed, the database will be in a consistent state. If an error occurs within a database LUW, all of the database changes since the beginning of the database LUW are reversed. This leaves the database in the state it was in before the transaction started.

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 R/3 System, database commits and rollbacks can be triggered either implicitly or using explicit commands.

Implicit Database Commits in the R/3 System

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 in the R/3 System

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 in the R/3 System

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 in the R/3 System

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.

· . To remove the object is being queued through above FM.

You have to use these function module in your program.

with regards,

sowjanyagosala.

Re: LUW

Former Member — Mon, 24 Mar 2008 09:03:22 GMT

Hi,

Database Logical Unit of Work (LUW)

Implicit Database Commits in the R/3 System

· 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 in the R/3 System

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 in the R/3 System

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

Explicit Database Rollbacks in the R/3 System

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.

· . To remove the object is being queued through above FM.

You have to use these function module in your program.

with regards,

sowjanya

Re: LUW

Former Member — Mon, 24 Mar 2008 09:33:29 GMT

hi,

Logical Unit of Work

Inseparable sequence of database operations, working on the all-or-nothing principle, where the operations are either all carried out, or all canceled.

From the point of view of the database system, logical units of work (LUWs) are crucial to the integrity of

the data in the database.

An SAP Logical Unit of Work (LUW) contains a series of dialog steps for a business process in the R/3

System that form a logical unit.

The steps in the process chain of the business process must be logically related.

SAP LUWs work on an all-or-nothing principle: Either the system processes all of the steps, or none of

them at all.

The business process represented in the LUW must be basic, that is it must not be too big. For example, the entire process from customer order to billing is too big to be included in a single LUW.

Instead, you would split the process up into smaller, independent sections, each of which would form a

transaction in the R/3 System. Exactly what constitutes a "basic" process depends on the business process and the way in which you have modeled it.

Note: A business LUW is often refered to as a transaction. The term transaction has several meanings.

In an SAP environment, transaction is often understood to mean an application that you start using a transaction code. A program can include several SAP LUWs.

A database LUW (DB Logical Unit of Work) is an inseparable sequence of database operations that takes the database from one consistent state to another.

Database LUWs are either completely executed by the database system, or not at all.

Database LUWs close with a database commit. It is only in the commit that the changes are firmly written in the database. Until the commit occurs, you can undo your changes using a database rollback.

Implicit database commits are triggered when:

A dialog step is completed

An error dialog occurs

You call a function module in another work process (RFC).

The SAP LUW can span several dialog steps and contains consistency checks, which are processed as closely as possible to the user action, so that the user can be informed of the error status. Since the user processing time of a screen is generally much longer than a dialog step of the application server, an SAP LUW requires a much larger time frame than a database LUW.

Using an SAP LUW to represent a business process in the R/3 System involves both user dialogs and a database dialog. The purpose of a transaction is to make sure that the data exchanged between program and user in the user dialogs is processed on an all-or-nothing basis in the database. This

means that all of the changes from the SAP LUW must be processed in a single database LUW.

Usually an SAP LUW is processed in more than one DB LUW.

The aim when programming a transaction is to bundle the segments of the database dialog in a DB

LUW.

You should aim to process the database dialogs as late as possible within the database LUW, and to keep the database locks set for as short a time as possible.

if SAP is providing by default lock objects why we have to use?.when we have to use?

Whenever you make direct changes to data on the database in a transaction, the database system sets corresponding locks.

The database management system (DBMS) physically locks the table entries that you want to change (INSERT; UPDATE, MODIFY), and those that you read from the database and intend to change (SELECT SINGLE <f> FROM <dbtab> FOR UPDATE). Other users who want to access the locked

record or records must wait until the physical lock has been released. In such a case, the ABAP program waits until the lock has been released again.

At the end of the database transaction, the database releases all of the locks that it has set during the transaction.

In the R/3 System, this means that each database lock is released when a new screen is displayed,

Locks are maintained in a central lock table. This ensures that also programs that run on a different application server of the same SAP System, are informed of the locks.

Before a database update is triggered, the program requests a lock using a special function module. You can set a lock for a data record in a database table, or even a set of records, according to you requirements. The function module first checks whether there is an existing lock that will obstruct the

lock request. If a lock does not already exist then the lock is set.

If another program tries to set the same lock, the function module sends a message to say that the record is already locked. This is carried out using an exception of the function module. Afterwards the return code is set to the value <> 0.

The return code must be supplied with values in the program.

You can inform the user of a corresponding message.

If the database change is successful, then the lock entry in the central lock table is deleted using a different function module.

since a change of screen triggers an implicit database commit.

Hope this helps, Do reward.