Features of the Update
The following graphic shows you how the SAP System and the database interact when an SAP transaction is being executed, and illustrates the difference between a database LUW (Logical Unit of Work) and an SAP LUW.
This example illustrates an SAP transaction that represents an SAP-LUW. The transaction consists of a dialog part extending over three screens. Each screen can be processed by a different (dialog) work process, because while the system is waiting for the user to make an entry, the work process can be assigned a different task by the dispatcher.
The dialog part of the transaction finishes with the COMMIT WORK statement; the update part of the LUW then begins: the update server transfers the update request to an update work process. Each dialog step (interval between screens) here corresponds to a database transaction (database LUW, finished with a COMMIT to the database, that is either executed in full or not at all on the database). The update part of the SAP transaction is executed in a database LUW. It is in this database LUW that the data is actually transferred into the application table. For more information, see The Update Process.
Difference Between Database LUWs and SAP LUWs
To the database, an LUW is an indivisible sequence of data operations that must be completed in its entirety or not performed at all. Database LUWs are the building blocks out of which database procedures for consistent data-handling are built.
By way of contrast, an LUW for the SAP System is a business process, which cannot be divided up. The process is either executed in full or not at all. An SAP LUW must include several database LUWs (see graphic above), each of which can be terminated with a database COMMIT, which is generated automatically. Under normal circumstances, the SAP LUW contains a dialog part (which maps a business process), and the command for writing the data to the database (update part).
For each database LUW, the data is written to the database, but not to the application tables, rather to special update tables. Once the dialog part has been completed, all of the data in a database LUW is copied to the application tables: the Update Request is then performed. This is described in greater detail in the section entitled The Update Process.
Advantages of the SAP Update System
The updating system offers a variety of advantages over direct database changes inline in a transaction. These include:
Problems that arise as a result of different types of logical units of work (for database systems and SAP transactions) are avoided. By Bundling Updates, the update system supports critical rollback and restore functions for transactions.
● Enhanced performance for dialog transactions: time-consuming database changes are carried out asynchronously at the end of the LUW after the user has already moved onto the next LUW.
To enhance performance even further, the application programmer can configure different types of updates (see V1 and V2 Update Modules):
● Time-critical U1 updates
● Non-time-critical U2 updates, dependent on U1 updates
● Non-time-critical U2 updates that are gathered and processed at a later time (see Collective Run)
See also:
For more information on the update process:
Distributed Processing of Updates
Primary System Profile Parameters for Updating
Notification of Update Problems