LUW’S AND CLIENT/SERVER ARCHITECHERE 46

LUW’S AND CLIENT/SERVER ARCHITECHERE


An SAP logical unit of work (LUW) is a functionally complete set of steps within a business process in the R/3 System.

The process steps must be logically related.

SAP LUWs work on an all-or-nothing principle: Either all or none of its steps are carried out.

The business process to be mapped must be basic. For example, you would not have a single SAP LUW consisting of all of the steps between a customer processing an order and an invoice being produced. Instead, you would split this up into separate parts, each of which would then be represented in the R/3 System by its own LUW. What constitutes an "elementary" process depends on the overall process and how you have modeled it.

For further information, see the ABAP Editor Keyword documentation for the term transaction processing.

A database logical unit of work (LUW) is a non-separable sequence of database operations. At the beginning and end of the LUW, the database is in a consistent state.

The database LUW is either fully carried out by the database system, or is not carried out at all.

A database LUW is opened with every dialog step and by a database commit of the previous DB LUW.

The database LUW is closed with a database commit. It is only in the commit that the data is written to the database (after which it can no longer be reversed). Before the database commit, you can undo the changes using a database rollback. Here, the database is reset to the status that it had before the first change was made to the current DB LUW.

Data that has been written to the database permanently with a database commit cannot be rolled back.

Database LUWs allow you to encapsulate logically related actions from a business process. For example, when transferring sums of money in financial accounting, you must deduct an amount from one account and then add it to another account. Before and after the process, the data is consistent, but in between the two steps, it can be inconsistent.

The SAP R/3 System is based on the three-tier architecture of a client/server system. The three tiers are the database, application, and presentation server layers.

This architecture, along with the distribution of users' requests (user dispatching), leads to a highly efficient, cost-effective multi-user system.

The three-tier architecture means that a large number of users with low-cost desktop computers (with low performance) can be mapped to a small number of high-performance (and considerably more expensive) work processes on application servers. Each work process on an application server is assigned a work process on a high-performance database server.

Distributing user requests to work processes assigns individual clients at presentation server level to a work process for a particular period. In turn, the work process uses another work process in the database. After the work process has processed the user input in a dialog step, the user, along with the program context, is removed from the work process, which can then be used by another user.

The three-tier architecture is far more scalable than a "fat" client architecture, in which the Presentation and application levels run on one server. With three-tier architecture, the number of database users is considerably lower than the number of users active in the system. This has a positive effect on the behavior of the database.

The three-tier architecture of the R/3 System has certain consequences for process handling. When a work process is released for use by another user (client), an implicit database commit is triggered for the database process assigned to it (via a basis program).

Work processes on the application server and database are released before each user dialog. This Ensures that long user dialogs in which the system is "only displaying a screen" are not included in Database LUWs. The duration of the user interaction will be longer than the DB LUW duration.

Shorter database LUWs lead to less load on the database.

Implicit commits on the database are triggered whenever the work process has to wait.

This includes:

When the system sends a new screen
When the system sends a dialog message
When you make a synchronous remote function call (RFC)
When you use the CALL TRANSACTION or SUBMIT statement.

Using an SAP LUW to represent a business process chain usually involves user dialogs as well as the changes to the database. The aim of an R/3 transaction is to represent the information exchanged in the SAP LUW as an indivisible unit in the database. This means that an SAP LUW can only use a single database LUW.

Since SAP LUWs usually involve several database LUWs, you need to bundle the database changes in a single database LUW within your transaction.


RELATED POSTS