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:
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:
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.
SAP BASIS Related Interview Questions
|SAP CRM Interview Questions||SAP HR Interview Questions|
|SAP ABAP Interview Questions||SAP HANA Interview Questions|
|SAP Crystal Reports Interview Questions||SAP SOLMAN Interview Questions|
|SAP Security Interview Questions||SAP BPC Interview Questions|
|SAP Netweaver Interview Questions||SAP UI5 Interview Questions|
|SAP Smart Forms Interview Questions|
Sap Basis Tutorial
Sap: From Sap R/3 To Sap Netweaver
The Architecture Of The Sap Web Application Server
Sap Netweaver: An Overview
Using Sap Systems
Upgrading To Sap R/3 Enterprise: The First Step Into Sap Netweaver
The Change And Transport System
Development Options With Sap Solutions: Abap Engine
User Management And Security In Sap Environments
Web Application Server System Management
Performance And Troubleshooting With Sap Solutions
Sap For It Managers: Implementation, Planning, Operation, And Support Of Sap Systems
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.