Logic checks about consistency of application data, such as, flight is overbooked should be a part of the dialog program where users can react on error or warning messages.

 

 

Write and Close Requests

All the update requests in an SAP LUW are stored under the same update key (“VB key”). The update key is a unique worldwide identification code for an SAP LUW. Only when the system finds a COMMIT WORK statement will it create a header entry for the requests that belong together (log header) and then the unit is closed. The log header contains information on the dialog program that wrote the log entries, as well as information on the update modules to be executed. After the log header has been created, the dispatcher process is informed that there is an update package ready or available for processing.

 

If the transparent tables VBHDR, VBMOD, VBDATA and VBERROR are used to implement the log, the information is distributed as follows:

• Each time an update module is called with the addition IN UPDATE TASK, two datasets are created. The data is written to the DB table VBDATA, while the information related to the update module is stored in the DB table VBMOD. Both data sets get the same update key.
• If the statement COMMIT WORK is processed, a new dataset is added to the DB table VBHDR. This dataset is also identified by the common update key.

 

 

Discard Requests (Generation Phase)

Sometimes all change requests that were written till now for the current SAP LUW may need to be discarded from within the dialog program. Such is the case, for example, when you terminate the transaction.

 

To discard the current SAP LUW during the generation phase, use the ABAP statement ROLLBACK WORK or send a type “A” or “X” dialog message.

 

The following actions are carried out to discard an SAP LUW:

• Delete all log entries related to the current LUW
• Delete all previously set locks
• Discard all of the updates executed for the current DB LUW so far
• Discard all of the subroutines registered by using PERFORM ON COMMIT

 

The ROLLBACK WORK statement does not affect the program context, that is, all data objects (program-specific objects and objects from function groups or classes that may be used) remain unchanged and they are NOT reset.

 

If the update module calls are neither confirmed (COMMIT WORK) nor discarded (ROLLBACK WORK) from within the dialog program before the program ends, the log entries stay in the log since neither an update header is created nor the log entries are removed because of an error. These log entries have to be removed later on.

 

 

Discard Requests (Processing Phase)

The task of an update module is to pass the requests for database updates to the database and to evaluate their return codes. To trigger a database rollback in the update module, issue a type “A” dialog message. The processing of the current SAP LUW will also be terminated. The log entry belonging to the SAP LUW is flagged as containing an error. The termination message is also entered in the log.

 

You must not use the explicit ABAP statements COMMIT WORK and ROLLBACK WORK in the update module.

 

You can examine the log entry by using the transaction code SM13.

 

An express mail is sent to the relevant user, informing the user that the LUW update was terminated. For this purpose, you must set the profile parameters rdisp/vbmail and rdisp/ vb_mail_user_list.

 

The profile parameters rdisp/vbmail and rdisp/vb_mail_user_list can be set as follows:

• The parameter rdisp/vbmail can be given the value 1 or 0 (switch/flag to dispatch mail in case of error).
• The value given to rdisp/vb_mail_user_list defines who is to be contacted in case of an error. The value $ACTUSER means that the user who has created the data record to be updated will be informed.

 

 

 

Set Locks in the Update Process