Requests in DataStore Objects
This tab page provides information about all requests that have run in the DataStore object. You can also delete requests here or schedule an update.
The information
(Request Is Available for Reporting
) is displayed once the activation process has been started.
Caution
The system does not check whether the data has been activated successfully.
When a request of the DataStore object is updated into other InfoProviders, the data mart status for the request is displayed. Use the corresponding pushbutton to manage the distribution of this request.
Choose 
Request Got from InfoProvider
to show the InfoProvider into which the request has been updated. More information: Where-Used List for DTP Requests.
The
icon shows you that the request is already updated in other InfoProviders. However, it is possible that you might have to repeat this request. If you think that data was not correctly posted, reset the monitor status and request a repeat so that the request can be posted again. To do this, choose Request Reverse Posting
in the monitor. For more information, see the documentation in the monitor.
A "red" traffic light means that there are problems processing requests, and that these problems are preventing a secure upload.
Note
Only requests that have a “green” status after loading can be activated and displayed in the query.
If a request was “green” after loading but is “red” during activation, you can restart activation.
Data packages with traffic light status "red" or "yellow" cannot be taken into consideration when a BEx query is executed. In this case, subsequent data packages with a green traffic light are not used in the query either because the consistency of the data in the query can no longer be guaranteed.
You can reset the original monitor request status by clicking on the status symbol of the request (in the QM Status of Request After Update
column) and choosing Delete status; return to request status
.
Choose 
Monitor
to jump to the extraction monitor and locate the errors that occurred. The 
log
for all request operations provides you with a detailed overview of request processing. You trace the start and end times of the steps in request processing, such as status changes and activation. You can use the runtimes to check performance. Technical information and detailed messages help you analyze errors.
You have information on all requests that have been run in the DataStore object and you can delete requests if required. You can only directly delete requests that have not yet been activated. The system uses rollback for requests that have already been activated.
For more information, see Deleting by Request.
Choose Selection
to schedule the update of requests individually or as an event chain in the background. The Subsequent Processing
function allows you to specify the events that you want to execute once the process is complete. The Delete
function triggers the background job or can delete it directly.
Choose
Activate
to activate requests. You can specify whether you want the requests to be compressed into one request in the change log when they are activated (this request is then rolled back from the DataStore object as a whole). You can also apply settings for processing.
SeeActivating Data in DataStore Objects.
If you have set the Unique Data Records
flag in the DataStore object maintenance transaction, this is displayed here as the default setting. You can also overwrite this setting, if required (for initial data loading, for example).