Administrating DataStore Objects (advanced)

Data has been loaded into DataStore Objects (advanced). Let's see how loaded requests are managed in DataStore Objects (advanced) and which possibilities are offered in SAP BW/4HANA to delete data from DataStore Objects (advanced). We'll discuss the behavior in the Data Mart DataStore Object and the Standard DataStore Object.

You can launch the app DataStore Objects (Manage requests) from the BW Modeling Tools using the icon on the toolbar, or you can use the context menu of the DataStore Object (advanced). You can also launch it directly from the SAP BW/4HANA Cockpit. You can use this app to activate and delete requests. Let's first have a look at request activation.

The activation run (activating the data in the inbound table) is usually triggered by a process chain, or can be started manually in test cases. The data is sorted at the start of the activation run. The sorting takes place, primarily, according to the semantic key of the DataStore Object (advanced) (that is, the table with the active data). Next, the data is sorted according to the technical key of the inbound table.

You can choose whether the changes called up from the different load requests are to be combined in one change log request, or generated for each loaded request. A load request identifies when records were loaded, a change log request identifies when the records were activated and moved into the change log from the inbound table.

Activation of requests in a Data Mart DataStore Object means compression. The records are summarized to one entry and are deleted from the /BIC/A<ADSO>1 inbound table and moved to the /BIC/A<ADSO>2 active data table. The Change Log table isn’t used for a Data Mart DataStore Object.

Activation of requests in a Standard DataStore Object means delta harmonization. Activation of a request in a Standard DataStore Object deletes the request from the /BIC/A<ADSO>1 inbound table and updates the /BIC/A<ADSO>2 active data table and /BIC/A<ADSO>3 change log table.

The option Activate Request by Request enables request by request rollback and deletion for Standard DataStore Objects.

If you’ve more than one DTP load request that is yet to activate, and you’ve decided to activate only one request, then this request ID helps to selectively process the records from the inbound table to active and change log table.

When you select the get delta request by request in DTP settings, the delta requests from the source are processed one after another and it creates separate request IDs for each run.

Besides the Default View, the app DataStore Objects (Manage requests) also offers an Advanced View. On the Advanced View, you can see if the request has been activated and updated to a target.

It also offers information for each load, where you can see the following request IDs:

• Load request (created at the time of loading)

• Activation request (created at the time of activation)

During upload of data, a request is always inserted into the /BIC/A<ADSO>1 table. Each record gets its own request ID, package ID and record ID. This feature enables you, for example, to delete a request from the /BIC/A<ADSO>1 table after the upload. However, these data loads can result in several entries in the table with the same values for all Characteristics except the request ID. This will increase the size of the table unnecessarily.

During activation of requests in a Data Mart DataStore Object (compression), these records are summarized to one entry and are deleted from the /BIC/A<ADSO>1 table and moved to the /BIC/A<ADSO>2 table. In the /BIC/A<ADSO>2 table, there's no request ID, package ID, or record ID. Once the data has been compressed, it is not possible to display or delete the data for a specific request ID.

In a Standard DataStore Object, you can delete load requests, even if they've been activated.

When you've used the option Activate Request by Request, it's possible to delete a request including rollback. When you want to delete an older request in a Standard DataStore Object, all newer requests will then be rolled back to ensure data consistency (due to the overwrite behavior of Key Figures and data fields). The rollback of requests is possible because the change log is used to find out how the data looked like before the load so a reversal can be executed.

To ensure data consistency on different data stages, a data flow using an active delta DTP only allows request deletion in the source, if beforehand the request in the subsequent target has been deleted.

The option Clean Change Log only deletes data from the Change log table. Be careful if you have to reload data to a subsequent target or if you have to roll back data.

The option Delete Data from All Tables is the fastest way to delete all data from all tables of a DataStore Object (advanced) in one step.

The option Selective Deletion offers you to delete data from a DataStore Object (advanced) based on values of a Characteristic, for example all data of a plan version.

For a Standard DataStore Object, selective deletion only applies to the Active Data table, for a Data Mart DataStore Object, selective deletion applies to the Inbound Table and the Active Data table.