In addition to planning on InfoCube-like aDSOs, planning on direct update aDSOs also has its merit. In this article, I explain the structure of this aDSO type and illustrate possible fields of application.
But first we have to understand the general structure of aDSOs. While the Advanced DataStore object appears as a flat table, there are three important tables in the background. In addition, views for extraction and reporting are automatically created. An aDSO thus always consists of five tables. However, depending on the settings and the aDSO type, some tables are not used.
The three most important tables are the inbound table, the active data table and the change log table. In the inbound table, all data records are stored with a technical key. This corresponds to the activation queue for the classic DSOs and is comparable to the uncompressed fact table of an InfoCube. In planning scenario, this table contains the delta records before the requests are activated.
In addition, the system generates a table for the active data (Active Data). This tables contains, just like in the classic DSO, current values after activation. The key defined in the DSO is used as the key of the table. It is similar to the compressed fact table of an InfoCube.
Planning Tools compared - SAP BW IP vs. BPC vs. SAC
The third table, the Change Log, is the same as in classic DSO. This table stores the differences between the inbound table and the active data table. The change log is needed for delta creation. However, in the planning environment this table is negligible.
While an aDSO with the Planning on InfoCube-like setting has an inbound and an active table, the data for an aDSO set to Planning on Direct Update is written directly into the active table.
And while all characteristics are defined as keys in an InfoCube-like aDSO, the keys must be defined manually in a direct update aDSO.
Please bear in mind that all fields, which are not marked as keys, will be overwritten. This feature makes aDSOs suitable for immediate updating, especially for storing comments where characteristics are used as key figures.
Since the direct update aDSO, unlike InfoCube-like aDSO, only has an active table, it is not possible to delete individual requests. However, this feature makes it possible to write data directly to the active table via an API.
It should be also mentioned, that it is now possible to load data via a data transfer process (DTP) to direct update aDSOs. This was not possible with a classic DSO for direct update. However, only the setting Overwrite is available. The summation of key figures in the transformation is therefore not possible.
If you want to use measures with the aggregation behaviour NO2 (no aggregation), there is no way around direct update aDSOs. For example, when implementing price planning scenarios or setting active / inactive flags. When modelling with these key figures, you must use this aDSO type. It is not possible to use InfoCube-like aDSOs.
Photo by gdtography from Pexels
