Displaying and Managing Update Records SAP BASIS

The update work processes are in charge of making and recording the changes in the SAP underlying database as users work normally in the system. The update work processes perform their functions when the ABAP applications are programmed with the statement IN UPDATE TASK. This type of updating is performed asynchronously in the system, meaning that the programs leave update records in a queue to be processed and then continue the execution.

The following section discusses the main concepts related to the update processes. Normally, the updating processes run without management intervention; nevertheless, the SAP system includes utilities to monitor, check, and perform management operations on the updating process, which can be very useful in case problems arise. When updating errors occur, normally the user requesting the update receives an express SAP message and an alert is triggered in the CCMS monitor.

The update functions are located under the administration menu, and then Monitor | Update. Alternatively, enter transaction code SM13 in the command field. The system displays the Initial Update screen as shown in Figure.

From the Initial Update screen, you can perform the following functions:

  • Display the system update records with error status or that have not yet been processed or to be processed.
  • Activate and deactivate the updating in the whole SAP system.
  • Display update statistics from the updated administration.
  • Display the data on the erroneous update records and reprocess them, either in real or in test mode.
  • Send waiting update records for processing after a deactivation/activation of the updating.
  • Delete update records.

Update process monitoring initial display

Update process monitoring initial display

Be sure to understand clearly how the updating process can affect the system before performing any management options on update records.

Update Process Concepts

Several of the work process types of the SAP system update the database. The dialog and background work processes include a database interface that can directly update the database. But these processes might also make use of the update work processes for updating the physical database in an asynchronous way. This section deals with the updating as performed by the update work processes. If the transactions programmed in the ABAP business applications have been designed for asynchronous updating, then in the database commit phases, the transactions pass the update records to the update work processes, which finally perform the changes in the database.

The update records contain both the data and the instructions on how to modify the database. These update records also have an update record header that is created by the transaction requesting the update. The headers of the update records are used for monitoring and managing the update processes. An update record might have several update components in charge of making different changes to the database. Update component types modify different database objects. The SAP system distinguishes between primary (U1 or V1) and secondary (U2 or V2) update components.

Primary update components, known as UI components, are in charge of the critical updates of the database and have priority over the secondary update components, U2. Critical updates of the database are the most usual, including posting financial documents, receiving sales orders, launching a production order, and so on. Secondary updates are lower priority changes such as calculating totals or preparing statistical information. The SAP dispatcher always assigns a higher priority to U1 components to perform the update as soon as possible; they are always processed before the U2 components. These types of update components are completely transparent to users and system managers, since they are programmed in the application transactions.

However, developers must consider the update components when defining new customer transactions. A group of update components of both types in an update record is processed sequentially by a single work process of an application server. U2 update components are always processed by the U2 update work processes. Should no U2 update work process be available in the application server, then the U2 components are processed by the U1 update work process.

Distribution of Update Work Processes

The profile parameters rdisp/wp_no_vb and rdisp/wp_no_vb2 define the number of update work processes running in an instance. A U2 work process can only process U2 update components. The update work processes can be running on more than one server, in which case the system will perform server load balancing to distribute the update requests among the available work processes. For performance reasons, many installations define most of their update work processes as "close" to the database as possible, that is, on the same server as the database server.

Every 10 minutes or whenever period that is selected (this is customizable), the system checks the availability of the update servers and refreshes the information for the application servers. When a server is down, the update requests are reallocated to active update servers. As a security measure to ensure that the update process does not get saturated with update records, the update servers process synchronously every 100th update. When this happens, the program that requested the update will wait until all pending updates have been processed. Then the program will resume execution.

This is particularly useful for large data load programs or background jobs that perform many updates and that could potentially fill up the processing capacity of the update server.

Monitoring Update Records

From the main menu for monitoring the update records, as shown in Figure, there are several input fields and radio buttons for selecting update records. When entering selection criteria, you can use wildcards for selecting all update records. You can select using the following criteria:

  • Client. Enter here the SAP system client or an * to indicate all clients.
  • User. You can specify the user ID whose transaction generated the update record.
  • Status. With this radio button, you can indicate the type of update record:
    • Canceled. Indicates that the update records terminated with errors. This status corresponds to internal status ERR.
    • To be updated. Will show records that have not yet been processed.
    • V1 executed. With this status, you select those update records for which the U1 part has been successfully processed.
    • V2 executed. It's the status for selecting those update records which have successfully processed the U2 component.
    • All To display all the update records regardless of their status.
  • From date and From time. These are used to specify the date and time range in which to display update records. Successfully processed update records are automatically deleted by the system and will not appear.
  • Maximum no. records. This is used to limit the number of update records to be displayed.
  • Update server. This is used to indicate which update server is in use in case there is more than one update server configured in the SAP system. After executing the report of update request, you get a list of canceled or terminated update records, and there are several actions you can take. From this screen, by selecting the record and then choosing Goto | Update Header from the menu, you can display the header of the update record, needed by the update process to manage the records. The update header includes management data that show specific information about the update record and that can be useful for finding the problem in the system log as transaction/report that caused the error and error details and navigate the source code.

Available Update Functions

From the Monitoring Update menu, there are functions to help you locate the causes of updating problems, functions for looking at the data that were contained in the update record, and also utilities for processing or repeating update records. The next section contains an overview of the management options within the Update Monitoring menu.

Processing and Repeating Update Records

From the Updated Records menu, you have the option to manually start, restart, continue, or repeat the processing of update records. This function is performed with the Repeat Update option. With the Repeat Update option, you can decide to update records which have not yet been committed and which are waiting to be processed. These records have either the status INIT or AUTO. INIT status indicates that an update record has all the needed components: header, update function modules, and the data, but has not yet been processed. Records with AUTO status are flagged in update records that have been marked for processing as the update process restarts. This situation might happen when the updating process has been deactivated.

Within the Post menu option, select whether you want to process all records or a single update record. With the Repeat Update function, you can request the system to reprocess update records carrying status ERR, which means they have terminated abnormally. You should, however, analyze the cause of the error before proceeding. You cannot reprocess an update with those records with status Error (No Retry), which is indicated by a Stop icon. When an update record terminates abnormally, it automatically releases the lock held on the objects for updating. This means that the user who got the error might have tried to manually enter the same data again and therefore update the database.

If you, as administrator, are not aware of that fact and repeat an update, you can cause severe inconsistencies in the database. Therefore, as a step before repeating an update record, contact the user or users with the update errors to see if they can reenter the data in the system. If the users do not know or do not remember the data, you can help them by looking at the actual data fields and tables with the update records. Select Goto | Update Modules | Display Data | Display RF Documents functions.

When repeating the processing of an update record, you can select either the U1 or U2 update components. However, the U2 components will not be processed unless the U1 have been successfully processed. Normally, the U2 update takes place immediately after the U1 update, but it's not asynchronously performed from the U1. From the Repeat Update menu you can decide whether to select All Records or Single to repeat abnormally terminated update records.

Deleting Update Records

Once you are sure the update record has been processed, either by manually reentering the data or by repeating the update process, you can delete the update records (if the record was processed successfully, it is automatically deleted from the list of pending update processes). To do that, from the Update menu, first enter the criteria for selecting the records to delete. The system will display a list with the update records that met the criteria. On this new screen from the Updated Records menu, select Delete and then either All Records or Single to delete just the one you have selected. When deleting update records, the system releases any locks held on the objects.

Displaying and Resetting Update Statistics

You can display a report for the update activity in the SAP instance where you are currently logged on. This report can be seen by selecting Goto | Administration of Update System from the first Update Monitoring screen, and then clicking on the Statistics icon or directly from the Update Request initial screen Goto | Administration of Updated System. In this report, you can see information such as number and status of update requests, database activity involved in the update processing, and runtime statistics.

You can reset the statistics to zero. From the Statistics screen, select Edit | Statistics | Reset and then you can either choose local, for resetting the statistics just on the current application server, or global, for resetting the statistics in all update servers.

Activating and Deactivating Updating

If a severe system error takes place but the system did not crash, such as, for example, a tablespace overflow, it sometimes might be useful to deactivate the updating as a security measure to prevent all coming update records to be aborted by the system, in which case users must enter the data back and process again the erroneous transactions. You could deactivate the updating, correct the system problem, and then activate it again and reprocess all the pending update records.

To deactivate updating systemwide, from the initial Monitoring Update menu, select the Administration of Update System function, located as an icon in the application toolbar, and from the next screen, select the Deactivate button. When performing this function, users will get a message in the status bar indicating that updating has been paused. When the system updating is deactivated, all the transactions in the system, including background processing, are paused and users are disabled from generating update requests; however, when updating is reactivated, they can continue to work without losing any data. Background jobs continue from the point they were paused. To reactivate the updating process, from the Update Administration screen, select the Activate button.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status