Activation of Data in DataStore Objects  

Use

Upon activation, the system writes data from the activation queue to the table of active data.

Features

The system determines the SIDs before the process of activating the data starts. The process of activating the data only begins after the SIDs have been determined.

If the activation process terminates while the SIDs are being determined, the data remains inactive and stays in the activation queue.

When the data is activated, it is written to the table of active data, where it is then available for reporting. Requests are sorted by the key of the DataStore object, request ID, data package ID, or data record number. This ensures that the data is updated to the table of active data in the correct request sequence. During an activation session, packages (from several DTP requests) are created that can be activated in parallel. Only one activation session can run at a time. When one activation session ends, the next one in the sequence is triggered. This is, however, only relevant when data is activated automatically. When you activate data manually, the pushbutton that you use to trigger the process disappears from the toolbar and is available again only after the current activation run is complete.

If an activation process is canceled, you cannot activate any subsequent requests. You have to keep repeating the activation process that was canceled until it is completed successfully.

The following options are available for the activation process:

●      Do not compress requests into a single request when activation takes place.

If you set this indicator, when the activation is complete a request is displayed in the change log for each of the requests that has been loaded. This means you can delete requests individually to restore a previous status of the DataStore object. However, when you update to another InfoProvider, all requests that are active but have not yet been updated are combined into one single request.

If you want to update requests to connected InfoProviders individually, you have to update the requests immediately after you have activated them. You can do this using process chains.

If you do not set this indicator, all the requests activated in this process are compressed into one change log request. Only this request can be rolled back fully from the DataStore object.

●      Settings for parallel processing:

By choosing Extras →  PSA -> Parallel DTA, you can set the maximum number of parallel processes for the update process from DataSource 3.x of this InfoPackage to the defined data targets.

For determining SIDs as well as for activating requests, processing is set to be carried out in three parallel processes. You can change this setting. If you change the setting to 1, serial processing occurs.

Processing is controlled by BI background management. More information: Setting Parallel Processing of BI Processes