There have been many architecture level changes in SAP BW/4HANA. One of this change are data modeling based.
In this article we will walk through the various features and capabilities of ADSOs, as well as explore how these capabilities help to optimize various tasks in your SAP BW environment.
At first, we will talk about the classic DSO and his features. After that I will present you the differences between the classic DSO and the new implemented ADSO.
DSO (Data Store Object)
What is DSO?
A DSO is a two-dimensional storage unit which mainly stores transaction data or master data on a lowest granularity. The data is stored at detailed level.
Types of DSO
When creating a DSO, you must choose the type:
When we create a DSO, the system sets a system ID of ‘SIDs Generation upon Activation ‘by default. This option can be found in the edit mode settings of a DSO. If we checked this option, the system will check the SID values for all the characteristics in the DSO. If a SID value for the characteristic doesn’t exist, the system will then generate the SIDs. If the SIDs are generated during the Activation, this process will help the system to improve the runtime performance of a query. In this way the system doesn’t have to generate SID’s at query runtime. SID values are always stored in SID table of a InfoObject. Using this SID, the attributes and texts of a master data InfoObject is accessed. The SID table is connected to the associated master data tables via the char key.
The following Table shows you the properties of the different DSO types and architecture:
ADSO (Advanced Data Store Object)
The Advanced DSO manages to replace all these objects.
Before we create an ADSO we must know that it includes 3 main tables:
- Inbound Table
- Activation queue table for classic DSO
- Uncompressed fact table of non-SAP HANA optimized InfoCube
- All records with are stored with a technical key
- Table of Active Data
- Same as classic DSO, contains the current values after activation. The key of the table is the DSO-Key (more about keys later)
- Compressed fact table of non-SAP HANA optimized InfoCube
- Change Log
- Same as classic DSO
- Stores the difference between Inbound and Active-table
- Needed for Delta-generation
Important Steps in creating a ADSO
We create an ADSO in the BWMT in Eclipse like all new Objects (in BW 7.5 you have the possibility top create the classical objects still in SAP GUI, in BW4HANA you can create only the new objects in BWMT).
In the General tab you will be able to configure activation settings and other property. At first the user must write a description. After that we have the possibility to choose a Model Template. In the ADSO you can behave like either one of the objects from classic BW:
- Acquisition Layer
In this layer you can create objects that cover the “write-optimized” use cases for classic DSO. It is divided into 3 other layers:
- Data Acquisition Layer
- Corresponds to a persistent staging area (PSA) and acts as an incoming storage area in BW for data from source systems
- No use of Active Table, so activation is not needed
- Requests will be loaded into and extracted from the inbound table
- All the records in the Inbound Table contain a Request Transaction Number (TSN), Data packet, and Data record number
- The inbound (Old name = New Data / Activation Queue Table) table is accessed to execute a BEx query and for extraction
- Data doesn’t get aggregated
- Corporate memory with compression feature
- Requests will still be loaded into the inbound table
- Old requests that are no longer needed on detailed level can be compressed into the active data table.
- To save memory space, the CM – compression ADSO doesn’t use a Change Log table, only an Inbound Table and an Active Data Table.
- As soon as a load request is activated, the system loads the data into the Active Table and deletes it from the Inbound Table
- If there are 2 records with the same key, BW/4HANA overwrites all the characteristics of the record with the characteristics of the lastly loaded record.
- Corporate memory with reporting option
- A difference between this template and the “Corporate memory with compression feature” template is that, the system does not erase data from the Inbound Table. Instead, the data also remain in the Inbound Table so that none of the technical information is lost.
- The CM reporting template has no Change Log though
- Another difference is that the data is not extracted from the Active Table but from the Inbound Table
- Because the data remain in the Inbound Table after activation, these ADSOs are a good solution for you when you want to store data but save space by not using a Change Log
- Propagation Layer
- Provides a basis for further distribution and reuse of data
- Corresponds to a standard DataStore object (classic)
- Requests will be loaded into the inbound table
- For reporting the user must activate the loaded requests
- The data is then transferred into the active data table and the deta is stored in the change log
- The change log is also used to rollback already activated request
- Reporting Layer
- Used to perform queries for analysis
- Corresponds to a standard InfoCube
- The inbound table acts as “F”-table and the active data table as “E”-table
- It does not have a Change Log. If the Change log table do not exist the Delta process cannot be done.
- After activation, the Inbound Table is empty
- The user reports on a union of the inbound table and the active data table
- Planning Layer
It splits in 2 other layers:
- Planning on Direct Update
- Data is automatically loaded into the Active table, so no need for activation
- It has no Change Log or Inbound Table
- You can fill the Active table with an API
- also load data to this type of ADSO using a DTP
- Only have an Overwrite option. No summation of key figures like there is in the Planning on Cube-like ADSO
- Planning on Cube-like
- Has an Inbound Table and an Active Table
- All characteristic fields are marked as key fields in the Active Table, which is a necessary requirement to make it suitable for planning.
- Only have an Summation option
Process of SID generation highly optimized for HANA
With the goal to optimize the performance, in BW/4HANA it is possible to set a flag not only on InfoProvider level, but individually per characteristic of the DSO. The data integrity check then is only executed on the selected characteristic.
As a new feature, you can use fields with simple data types instead of InfoObject. To do so, go to the Details tab and click the Add Field button. Under Identify, you can specify in the “With” dropdown menu whether you want to use an InfoObject or a Field for the definition.
In BW the user can choose whether he is modeling with InfoObjects or fields. Modelling with InfoObjects brings extra effort, but also brings a lot of advantages. Before you choose one of this option, you should consider the advantages and the disadvantages of both of this modeling options.
In the following I will present you a part of the advantages and disadvantages when you choose the option of modeling with fields:
Advantages when using fields:
- If the query contains fields, it can be processed key-based in SAP HANA
- Using fields can enhance the flexibility and range of the data warehouse, when the data volume is small.
Disadvantages when using fields
- The services for InfoObjects (attributes and hierarchies for example) are not available for fields.
- Validity characteristics for DataStore objects (advanced) with non-cumulative key figures must be InfoObjects.
- InfoObject attributes must be InfoObjects
- A field-based key figure cannot be an exception aggregation
- Planning queries on DataStore objects (advanced) are only supported with fields as read-only
- If fields are used in the query, the InfoProviders can only be read sequentially
- In the query on a CompositeProvider, not all data types for fields are supported (ex. maximum length for fields is 20 characters)
Defining Keys for a ADSO
Also, in this tab we select which fields make up the keys of our ADSO. To define a key, click on Manage Keys button.
There are 2 types of keys: Primary and Foreign key
Advantages of using Key fields:
- uniquely identify a record in a table.
- Key Fields cannot be NULL
- Used to link two tables
- Main purpose of a foreign key is data validation.
- Read Master Data: using the input field value as a key, you can read the value of a Characteristic attribute belonging to a specified Characteristic
- Read from advanced DataStore: using the input field value(s) as a (compounded) key, you can read the data fields of a specified advanced DataStore Object (DSO)
- Somethings that you don’t wish for is that, 2 records with the same key, BW/4HANA overwrites all the characteristics of the record with the characteristics of the lastly loaded record
Disadvantage of not using Key fields:
- Records are not uniquely identified =>Duplicates records allowed
- Performance affected
Benefits of using a ADSO instead of a classic DSO:
- Simplification of object types
- Can behave like 4 Objects from the classic BW
- Flexibility in data modeling
- Modeling your ADSO using the Reporting Layer settings
- Performance of data loads and activation is optimized for HANA as ADSO is a HANA native object.
Source of images: SAP SE, Inspiricon AG