On the way to BW/4HANA there is no more option to avoid using aDSO’s. The good news is that things are similar as beforehand and there are no disadvantages in using an aDSO instead of a RealTimeCube or a direct Update DSO as an InfoProvider for planning.
One of the biggest advantages of using an aDSO for planning is that there is no need any more in rolling up the plan data (closing the yellow request) before extracting data via a transformation.
Each SAVE event creates a unique request which is immediately available for reporting and extraction.
A second advantage of an aDSO is that the data can be easily read via a SQL statement in ABAP. As the data is stored in a table like format in one of the aDSO’s tables and views the only challange is to find the correct table/view to read the data from.
Example of accessing the reporting view of the aDSO named ZADSO:
In the past the direct update DSO was mainly used for key figures which can not be aggregated (e.g. prices, percentages, comments): prices planned on a higher drill-down level were not distributed but copied to each characteristic beneath if the key figure was set up with the aggregation behavior: “No Aggregation (X, If More Than One Value Occurs)”. The query setting for that is “disaggregation copy”.
Most of the other scenarios were kept in an RealTimeCube as this was the first option SAP BW-IP offered since the early stages.
When creating an aDSO for planning you have two options: InfoCube-like or Direct Update aDSO. Which one should you choose?
When planning non-aggregated key figures, you need to use the Direct Update aDSO for planning (template ‘Planning on Direct Update’).
For all other scenarios you have the choice of using the InfoCube-like behavior (see Model Template ->Planning -> Planning on InfoCube-like) or the Direct Update one
(see Model Template ->Planning -> Planning on Direct Update) .
So what is the difference between the two types of planning aDSOs?
In general, there are two major differences. First of all how the data is stored and second how the aDSOs are setup.
Storage of data
InfoCube-like data is stored on SAVE event in the inbound table with the key-figures containing only the delta.
The active table of the aDSO is empty as long as the aDSO data is not activated. To activate the data the aDSO needs to be switched into the load mode. The activation is similar to the compression of real time cubes. All requests are aggregated, and the delta information is lost after activation.
Example:
First save of 1.000 EA
The inbound table of aDSO ZVOLPLA1 -> /BIC/AZVOLPLA11:
Changing the 1.000 EA to 1.500 EA leads to the following records in the inbound table:
The active table of aDSO ZVOLPLA1 : /BIC/AZVOLPLA12 is currently empty.
Data activation will aggregate the inbound table and delete the records from there.
The active table of aDSO ZVOLPLA1 : /BIC/AZVOLPLA12 will hold this record after activation:
The Direct Update aDSO uses only the active table to store the data. No deltas are stored. If a value is changed, the old record gets updated with the new information directly (direct update).
This leads by nature to less data records. No need of switching to load mode as there is no option of activating the data – it is already stored in the active table.
Difference in setting up the planning data model
InfoCube-like aDSO by nature handles all characteristics as key fields.
There is no option in defining key fields (the option in Eclipse is disabled), all of them are part of the key by definition.
To be precise: this holds true in the active table, in the inbound table the key is a unique field REQTSN which holds a timestamp like information followed by a number and a time zone (YYYYMMDDHHMMSS<number><timezome>).
When creating an aggregation level on top of such an aDSO not all characteristics need to be in the aggregation level. When saving data via a planning function or via an input ready query the characteristics which are in the aDSO but not in the aggregation level are kept empty (#).
Direct update DSO like aDSO can only be used for planning if all characteristics are set to key fields, and you will need to do that manually via the details tab in Eclipse (key components).
For both types of aDSO the aggregation level defines which characteristics are visible in the query or planning function. Not included characteristics will be # on SAVE.
Takeaways
As there are no real benefits in using InfoCube-like aDSO the clear advice is to use the Direct Update DSO like aDSO.
Advantages of the Direct Update DSO are:
– less records (no delta bookings) which might lead to a better performance
– no need of activation via switching to load mode
– the possibility to physically delete records via planning
– both options of disaggregation are supported: copy or disaggregation
In general it is recommended to keep the planning model as lean as possible by using in the planning Composite Provider only the data and characteristics which are really needed for your planning application.
In case you need to combine several planning models, do not save on Composite Providers – there is no need in keeping everything in one big Composite Provider as it was used to with Multi Providers.
On top of the Composite Provider we need one Aggregation Level and there is also no need to create multiple ones.
In case you need additional data for reporting being combined with your plan values a stacked composite provider could achieve that:
