Concept and Technical Implementation of the Update Technique

 

Update Concept and Process Flow

You use the update techniques to separate user dialogs from the database changes. Different programs execute user dialogs and database changes, which generally run in different work processes.

 

The program that the user uses to execute dialogs is called a dialog program. It accepts user entries and, at the end, when it passes on the changed data, triggers an update program that updates the corresponding data in the database. No dialogs run in the update programs.

 

The steps in a program that use an update technique are as follows:

1. Write requests
2. Complete requests
3. Transfer information to update program
4. Perform database updates
5. Delete requests

 

Write Requests

The dialog program performs database changes by calling an appropriate function module. An addition to the call statement ensures that the function module is not processed directly, but information about the function module and the data passed to the module is written to a special log.

 

A dialog program can write several entries to the log.

 

The entries in the log represent an SAP LUW. The update techniques ensure that all called function modules (which contain the database update coding) are executed within one database LUW ("all or nothing" principle).

 

Complete Requests

The dialog program closes the request queue (representing the LUW) that was written to the log. The dialog program also informs the basis system that a request queue to be processed exists.

 

Transfer Information to Update Program

A basis program reads the information associated with the LUW from the log and supplies it to the update program.

 

Perform Database Updates

The update program processes the information transferred to it and executes the function modules with the corresponding data stored in the log.

 

Delete Requests

If the update function modules run successfully, a basis program deletes all entries for the LUW from the log.

 

To increase the update performance, the automatic deletion is omitted by setting the profile parameter rdisp/ vb_delete_after_execution to 2 (default: 1). In this case, however, the program RSM13002 has to be scheduled periodically to delete all entries related to finished updates.

 

In case of an error, the entries remain in the log. They are flagged as incorrect. The user who has triggered the update is generally informed by express mail about the error.

 

Hint:

The option of informing users by mail that an update action has failed can be set using the following profile parameters:

• rdisp/vbmail
  The parameter rdisp/vbmail can be given the value 1 (send mail) or 0 (do not send mail).
• rdisp/vb_mail_user_list
  The value of rdisp/vb_mail_user_list defines who is to be contacted if there is an error. The value $ACTUSER means that the user who has created the data record to be updated will be informed. Multiple users are informed if their names (separated by commas) are defined as the parameter’s value.

 

The monitor transaction code for update requests is SM13.

 

 

Technical Implementation of the Update

The technical implementation of the update concept requires, in addition to the dialog program, a so-called update module that must be implemented as a special function module.

 

Update modules, like other function modules, have an interface for transferring data. The interface for update function modules only includes IMPORTING and (for compatibility reasons) TABLES parameters. These must be typed using classical data types and the flag “Pass Value” has to be checked (call by value). Exceptions can be defined in update modules. However, if used in the update context, exceptions are ignored.

 

The function modules contain the actual database update statements. The update function modules should concentrate to the database update and should terminate only in case of technical or database issues.