Entering content frameProcess documentation The Update Process Locate the document in its SAP Library structure

Purpose

Among other things, the update system is used to lighten the workload of the SAP transactions when time-consuming changes are made to the database. The changes are carried out asynchronously - usually with short delays in between - by special update work processes.

This is why the update system is widely used in SAP transactions (by almost every transaction that changes business data), although transactions can also change the data directly in the database.

Prerequisites

The application programmer decides whether, and if so, how, the update system is used for developing transactions. The different options open to the programmer are described in detail in the ABAP manual in the section entitled Structure linkUpdate Techniques.

Note

When you are working with the SAP update system, it is important to make sure that only insert, update and delete statements are executed in the update. The necessary data should, of course, be gathered together beforehand (using select and so on). Programming that has not been carefully thought through can result in poor system performance, and can, in certain cases, cause serious problems.

Process Flow

As illustrated in the graphic in Functional Description of Updates, at the end of a transaction COMMIT WORK and the update task are called; the dialog part of the SAP transaction is closed, and the update part of the SAP logical unit of work (LUW) is started. The following graphic illustrates the necessary actions and the sequence in which they execute the different Structure linkwork processes.

This graphic is explained in the accompanying text

After the transaction has been processed, the dialog process completes the VBHDR entry (the update header of the update request) and searches an update server for the V1 update. This process is described in greater detail in the section entitled Update Dispatching with Load Distribution.

The update server distributes the tasks to an update work process. This processes the V1 modules of the update request, triggers a COMMIT to the database, and releases the SAP locks on the update request (see Structure linkThe SAP Lock Concept). The work process then searches for an update server for the V2 update, providing V2 update modules exist.

A V2 update server then passes this onto a V2 work process, which processes the V2 modules and triggers a COMMIT to the database.

The following graphic illustrates this from the point of view of the different work processes. The graphic also shows the times at which changes are made in the database.

This graphic is explained in the accompanying text

Processing the V1 modules involves transferring the contents of the update tables VBMOD and VBDATA to the application tables of the database. The changes are not actually made to the tables in the database until the database LUW in which this takes place is completed. The SAP locks are released and, if V2 update modules exist, the V2 update is started. This is similar to the V1 update with the exception that there are no locks that have to released and no search for a process for further processing.

Result

If the update is completed without any errors, the update record is no longer listed in update management and the data is successfully processed.

 

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

Bundling Updates

Synchronous and Asynchronous Updates

The Most Important Update Statuses

Error Handling and Data Consistency

 

 

Leaving content frame