Sie sind auf Seite 1von 3

Synchronous Update

In synchronous update, you do not submit an update request using CALL FUNCTION... IN
UPDATE TASK. Instead, you use the ABAP statement COMMIT WORK AND WAIT. When the
update is finished, control passes back to the program. Synchronous update works in the same
way as bundling update requests in a subroutine (PERFORM ON COMMIT). This kind of update
is useful when you want to use both asynchronous and synchronous processing without having to
program the bundles in two separate ways. The following diagram illustrates the synchronous
update process:

Use this type of update whenever the changed data is required immediately. For example, you
may want to link SAP LUWs together where one LUW depends on the results of the previous
one.

Update Techniques
The main update technique for bundling database changes in a single database LUW is to use
CALL FUNCTION... IN UPDATE TASK. This section describes various ways of updating the
database.
A program can send an update request using COMMIT WORK

To the update work process, where it is processed asynchronously. The program does
not wait for the work process to finish the update ( Asynchronous Update).

For asynchronous processing in two steps ( Updating Asynchronously in Steps.)

To the update work process, where it is processed synchronously. The program waits for
the work process to finish the update ( Synchronous Update).

To its own work process locally. In this case, of course, the program has to wait until the
update is finished ( Local Update.)

Asynchronous Update
A typical R/3 installation contains dialog work processes and at least one update work process.
The update work processes are responsible for updating the database. When an ABAP program
reaches a COMMIT WORK statement, any function modules from CALL FUNCTION... IN
UPDATE TASK statements are released for processing in an update work process. The dialog
process does not wait for the update to finish. This kind of update is called asynchronous update.

The following diagram shows a typical asynchronous update:

For example, suppose a user wants to change an entry in a database table, or add a new one.
He or she enters the necessary data, and then starts the update process by choosing Save. This
starts the following procedure in the ABAP program:
1. Firstly, the program locks the database entry against other users, using the enqueue work
process (or the message server in the case of a distributed system). This generates an
entry in the lock table. The user is informed whether the update was successful, or
whether the lock could not be set because of other users.
2. If the lock is set, the program reads the entry that is to be changed and modifies it. If the
user has created a new entry, the program checks whether a record with the same key
values already exists.
3. In the current dialog work process, the program calls a function module using CALL
FUNCTION... IN UPDATE TASK, and this writes the change details as an entry in table
VBLOG.
4. When the program is finished (maybe after further dialog steps), a COMMIT WORK
statement starts the final part of the SAP LUW. The work process that is processing the
current dialog step starts an update work process.
5. Based on the information passed to it from the dialog work process, the update work
process reads the log entries belonging to the SAP LUW from table VBLOG.
6. The update work process passes this data to the database for updating, and analyzes the
return message from the database. If the update was successful, the update work
process triggers a database commit after the last database change and deletes the log
entries from table VBLOG. If an error occurred, the update work process triggers a
database rollback, leaves the log entries in table VBLOG, flags them as containing errors,
and sends a SAPoffice message to the user, who should then inform the system
administrator.
7. The corresponding entries in the lock table are reset by the update work process.
Asynchronous update is useful when response time from the transaction is critical, and the
database updates themselves are so complex that they justify the extra system load of logging
them in VBLOG. If you are running a transaction in a background work process, asynchronous
update offers no advantages.