The Update Process
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
Update
Techniques.
When you are working with the SAP update system, it is important to make sure that only insert, update and deletestatements 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
work
processes.
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, and triggers a COMMIT to the database. Then it processes AFTER_COMMIT
modules (if present), and then releases the SAP locks on the update request
(see
The 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.
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:
Synchronous and Asynchronous Updates
The Most Important Update Statuses
Error Handling and Data Consistency