Upon activation, data is written from the activation queue to the table of active data.
The SIDs are determined 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 directly to the table for active data, where it is made available for reporting purposes. Requests are then sorted by the key of the DataStore object/ request ID/ data package ID/ data record number. This ensures that the data is updated to the table for active data in the correct request sequence. During an activation session, packages (from several PSA requests) are created that can be activated in parallel. Only one activation session can run at a time. Instead, when one activation session ends, the next one in the sequence must be 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 completed.
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:
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 again individually to restore to 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 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 data uniqueness: Here you can override the setting that you specify when editing the DataStore object. You have the following options:
Only process new, unique data records:
Using this flag, you can specify that only unique data records are written to the DataStore object on this activation request. This is recommended, if you are sure that the active table does not contain any records with the same key. This is the case if the object does not contain any data or if you load an init request from a newly connected source (that supplies disjunct data).
During activation, the system does not need to read the data again, to check whether records with this key already exist. This means the activation runtime is reduced, especially in cases where the active tables contains a large number of records.
Process new and changed data records:
If you have configured the setting in DataStore object that only unique data records should be loaded, you can override it by using this option. This means that during activation, the system checks whether the relevant records already exist in the DataStore object.
Settings for parallel processing:
For determining SIDs as well as for activating requests, processing is set on three parallel processes. You can change this setting. If you change the setting to 1, serial processing takes place.
Processing is controlled by BW background management. For more information, see Setting Parallel Processing in BW Processes.