Update Work Process

1)    The update work process handles database update operations

2)    SAP transactions usually consists of several dialogue steps i.e., it creates a log record for dialogue step in SAP transaction in the VBLOG table for database update.

3)    Update work process later process the log record at the end of the SAP transaction.

4)    Update Service

        i)        Create update request

        ii)       Send update message

        iii)      Read update request

        iv)      Implement update request

5)    While doing the updating object has to be locked for not execute other requests at the same time.  Otherwise it might leads to database inconsistency.

6)    The locking mechanism will be taken care by enqueue work process.

7)    Dialogue work process updates the data to the temporary tables. From temporary tables update work process update the data directly to the database.

8)    The list of temporary tables are

       i)        VBHDR : Contains header information

       ii)       VBMOD: contains modification of updated data

       iii)      VBDATA: contains actual updated data

       iv)      VBERROR: Error information will be stored

       v)       VBWORK: work list for mass processing

9)    Update process are of three types

i)             Local Update: in this dialogue work process will update the data directly to database. This case occurs when dialogue work process dealing a small transaction.

ii)            Asynchronous Update: This case occurs when dialogue work process is writing the data to the temporary tables.

iii)           Synchronous Update: This case occurs when update work process will write the temporary table data to the database.

10)  In each and every system there are two update work processes. Those are UPD and UPD2.

11)  UPD will take care of all critical updates and UPD2 will take care of all non critical updates.

12) The configuration of update work process depends on dialogue work process in general we need one update work process for each and every 5 dialogue work processes.

13) From SM13 T-code we will check the all update processes.

14) Update process status are

1)    Cancelled

2)    To be updated

3)    V1 executed

4)    V2 executed

15)  While running update processes there are four update stages

1)    I (INIT): It will initialize the update records

2)    N (RUN): Update is started in main memory

3)  O(AUTO): When we got any update errors after solving those errors the update process starts automatically.

4)    F (Error): Error in the process

16)  From SM14 we can activate or deactivate the update process.

17)  The update errors will occur when

i)             DB Errors

ii)            Program Errors

iii)           Table overflow

iv)           Network issues

v)            When less number of work processes are configured

Update Work Process Profile Parameters:

1)    rdisp/wp_no_vb: number of update work processes

Default value: 0

Recommended: 2

2)    rdisp/vbmail: Send mail in case of an update error

If update errors occur, the user is informed by the sending of an Express mail. You can deactivate this mail:

   Parameter value = 1: A mail is sent

   Parameter value = 0: No mail is sent

3)    rdisp/vbname: Name of the update server

4)    rdisp/vbreorg: deletion of old update requests

This parameter specifies whether incomplete update requests should be deleted as an update server is started. This type of request can occur if a transaction has already saved function modules in the update tables and executed an implicit COMMIT WORK at a screen change, after which a rollback occurred. As these incomplete update requests can never be executed and only occupy space in the database, you should delete them from time to time.

Alternatively to deleting incomplete update requests at the start of an update server, you can use background job rsm13002 to delete them. In this case, you can set the parameter to 0. This means that no reorganization is performed when the update server is started.

Default value: 1 (a reorganization is executed when the update server is started).

5)    rdisp/auto_vb_stop: DB errors will stop update task automatically

Update automatically stops when database errors occur.

The possible values are:

     0 No automatic stop

     1 Automatic stop

Default: 1

6)    rdisp/vb_lock_mode: handling of sap enqueues after update error

This parameter defines the handling of the SAP locks inherited by the update process after update terminations. There are three variants: - the locks are released. This should mean that important system   resources do not remain locked after update termination. The parameter value for this variant is RELEASE.

·         The locks remain in place. The parameter value for this variant is   HOLD.

·         The locks only remain in place if the update was externally   and was previously in the status PREPARE. The parameter value   for this variant is HOLD_AFTER_PREPARE.

Default value: RELEASE

7)    rdisp/vbdelete: Delete old update requests

The parameter specifies the duration in days, after which an update request is deleted. At the end of this period, the update requests are deleted irrespective of their status. If the parameter has the value 0, the update requests are not deleted.

Default value: 50 days

8)    rdisp/vb_stop_active:

You can deactivate the SAP update as follows: - By manual deactivation (SM14 or SM13 Update records -> Update -> Deactivate)

- When severe database problems occur, the system deactivates the update process.

This parameter is used to switch off the ability to deactivate the update process. If the value is set to 1, updating can no longer be deactivated.

Default value: 1

9)    rdisp/vb_mail_user_list: List of users to receive mails in case of update                    errors

This parameter controls which users receive an express mail "Update terminated" when an update terminates. Usually only the affected user receives the mail. Other or additional users can be specified. This can be used, for example, to ensure the administrator receives all mails.

The parameter must be entered in the profile using the syntax:

      rdisp/vb_mail_user_list = <usr1> [, <usr2> ] ...

If the affected user is to receive the mail, use the name $ACTUSER.

Examples:

·         rdisp/vb_mail_user_list = $ACTUSER, ADMIN1, ADMIN2   The mail is sent to the affected user and to the users   ADMIN1 and ADMIN2.

·         rdisp/vb_mail_user_list = ADMIN. The mail is sent to the user ADMIN.

10)  rdisp/vbstart: Perform update startup actions

This parameter controls the start-up behavior of an update server. During startup, the update server checks in its request to see if it contains any update requests that have not yet been executed (status init). If this is the case, these requests are flagged and then executed. You can use this parameter to deactivate this automatic starting:

   Parameter value 1: The automatic starting is active

   Parameter value 0: The automatic starting is not active

Default value: 1