A request can be defined as a data request from a subscriber. There are two different types of requests:
A composite request transfers data from one or more queues that have been grouped together into a subscription.
An extraction request transfers queue data from the provider to the queue storage.
A composite request can contain several extraction requests. If only data changes are requested that were written to the queue by the source application, the composite request does not contain any extraction requests.
You monitor the requests in the Requests overview in the delta queue monitor view. You can perform various actions for the unconfirmed requests (in other words, requests that have not been transferred by the subscriber).
Checking the Status of Current Requests
Use the function to check all the displayed requests to see if any have the status or . If the extraction process was canceled or terminated, the status in the database and in the display is updated (corrected).
Investigating Failed Extraction Requests
Analyze the cause of the error:
Use the function to open the job overview. Here you can display the log of the relevant background job (if it has not been deleted).
In the application log (transaction SLG1), you can analyze the data extraction logs, using object ODQ and subobject Extraction .
Use the function to reschedule failed extraction requests. The extraction process is delayed by 60 seconds. This gives you the chance to activate debugging for the background job - in the process overview (transaction SM50) or the global work process overview (transaction SM66) - and find the cause of the error.
Fix the error.
When you transfer data changes (delta), you have the following options:
Use the function to repeat the extraction process.
Use the function to conclude the corresonding request and set the status of the extraction request to . This status means that the data is transferred again when the next request is made. For more information, see the next section.
When you transfer a data snapshot (full), a data request is made again.
Closing Unconfirmed Requests
Use the function to conclude requests that have not been confirmed or canceled by the subscriber. It may be necessary to close a request in the monitor for various reasons:
The request without subscription has not been retrieved (for example, the connection to target system was deleted).
In this case, you should not assume that the subscriber will close the request by itself. However, if the request status is not set to or , the delta queue stores the data until the retention period has expired.
Completing these types of requests saves memory space and large data snapshots can be removed from the delta queue. The status of the request is set as follows: If extraction fails, the status is set to . If extraction is successful, the status is set to .
The system could not extract the data changes (delta). (Status: ).
In this case, none of the subscribers to this queue can continue transferring the new data, because data changes must be transferred seamlessly in the correct sequence. Usually, closing the failed request is not enough to continue transferring the data changes for this queue. You need to solve the cause of the problem, otherwise the next extraction attempt will also fail.
When the request is closed, the extraction request is given status . The request cannot be repeated with the . The delta process can be continued subsequently by any subscriber. This creates a new extraction request that fits in seamlessly with the most recent successful extraction.
Displaying Units and Data for Specific Queues or Time Periods
You can display units in the units overview. The preselection made in the monitor or the navigation route to this view (and the associated time stamps and queues) define which units are displayed here. Double-clicking a row displays the extracted data for a unit in the bottom of the Monitor screen.