Functional Description of Updates (SAP Library - Updates in the SAP System (BC-CST-UP))

Functional Description of Updates

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.

Example

This graphic is explained in the accompanying text

This example illustrates an SAP transaction that represents an SAP-LUW. The transaction consists of a dialog part extending over three screens. A different (dialog) work process can process each screen, 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. The update part is described in greater detail in the section entitled The Update Process.

Database LUW vs. SAP LUW

In the case of the database, an LUW is a sequence of data operations that cannot be divided up. The operations are either carried out in full or not at all. Database LUWs are modules that make up the database procedures for consistent data processing.

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 usually 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).

In each database LUW, data is written to the database to special update tables (and not to the application tables). Once the dialog part has been completed, all of the data in a database LUW is transferred into 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 update system offers a number of advantages over database changes that are made directly 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 V1 updates

Non-time-critical V2 updates, which depend on V1 updates

Non-time-critical V2 updates, which are gathered together and processed later (collective runs)

See also:

Further details on the update process can be found in the following sections:

The Update Process

Distributed Processing of Updates

Main System Profile Parameters for Updates

Reporting Update Problems