SAP BW/4HANA users must be aware of ADSO Functions as this is the core of the data modeling, storage, and consolidation. Having diverse implementation and utilities makes this tool a must-have for perfected data analysis seekers.
This post throws light on the meaning, implementation, and utilities related to ADSO Functions so that one can make most of it.
Also Read: The Write Interface enabled ADSO Ability for SAP BW/4HANA
ADSO stands for Advanced DataStore Object and refers to the primary and pre-integrate persistent object, offered with SAP BW/4HANA solution. The object is used widely in the data modeling, data storage, and data consolidation-related tasks in the SAP BW/4HANA system and is suitable to use in multiple workflows as per the selected properties.
Recently, SAP BW/4HANA has got the updated request management functionality. As per this recent update, ADSO is now equipped to handle the frequent loading and huge databases. When compared with InfoProviders, ADSO functions are more efficient as they can modify their functions while causing no damage to the data integrity. Also, table content can be modified seamlessly in case the data type is altered.
Also Read: Your Modern Data warehouse for Elevated Needs
The feature is only available for BW 7.40 SP8 or above. Other than this, its seamless implementation demands starting with at least 7.40 with SP9 or SP10.
What makes this feature gain an edge over other functions is the advanced and modeling user interface. BW/4HANA users are no longer required to use customary SAP GUI to get started with ADSO as it’smodeled in the Eclipse environment.
Now that the meaning of ADSO functions is clear, it’s time to understand the ADSO structure.
Structurally, there are three core tables that construct the ADSO function. The three key tables are:
All these tables are constructed in the background while using ADSO. BW/4HANA system makes use of these tables automatically as per the pre-defined properties. It’s crucial to understand that all these three tables are generated by all means as they are essential for seamless data model alteration when the huge database is handled.
Also Read: SAP DWC: The Future of Data Warehousing
ADSO tables don’t exist alone as few views are created in the background automatically. These views are views for extraction, views for reporting, and views for external access.
Along with the fundamental tables, validity and reference point tables for inventory data are also created in ADSO functions.
Under the Standard DataStore Object, there are three core modeling properties.
This property leads to the auto-save of delta (any updated, erased, and altered record) in the changelog that is further used to extract delta.
This modeling property is used when Data Source distributes the present dataset as “Full”. Activation of Snapshot support leads to auto-identification and update of the deleted data record. Also, this modeling property allows BW/4HANA system to identify the active data table content while load request is not taken into consideration. In the changelog, Snapshot support is written/recorded as a reverse image.
This modeling property is required when load unique records are stored in the ADSO. Activation of this property makes BW/4HANA system inspect whether or not unique records exist. In case of the prior existence of a unique record, this property will be canceled with an error.
Multiple ways, based upon its properties, are there for staging ADSO.
This type of ADSO features no changelog and full or delta extraction will lead to an Inbound table. This ADSO function is not suitable for reporting and analysis purposes.
By default, data is written in the inbound table, and the selection of Compress Data will make data to be written in active data table after it reaches the inbound table. The data aggregation and active data table writing are decided by the semantic key.
Also, this function displays only the activated data. One can’t make request-based data deletion in this function. Only selective data selection is possible.
Activation of this feature will lead to continuing the presence of data in the inbound table when the data loss request is active. In case when trying to continue with data-target loading, data will be always extracted from the inbound table. When a query is executed, the active table will be accessed automatically.
This function is mainly used for analysis and reporting and features auto data loading in the inbound table. Data gets copied from the active data table when it’s activated and is then coupled as per the aggregation behavior. After this stage, data will be deleted from the inbound table and the changelog remains empty.
Data required for any further data-target update will be fetched from the active data table to support the early and exclusive extraction. Upon query execution, active table data can be accessed that makes only the previously activated data visible.
This function makes the direct data loading into the data active table and supports full data extraction and is readable from the table of active data. Data present in the active table is available for reporting soon after the loading.
All the above-stated options and their settings decide the activation of three special ASDO properties.
Enabling this table will lead to the creation of two additional ADSO tables, validity and reference point table.
A validity table is used to log the time interval against which the non-cumulative values are loaded into InfoProvider.
The reference point table is automatically updated when inventory-enabled ADSO data is activated.
This setting enables the writing back feature in connected planning applications such as Office and Lumira dashboard. End-users are permitted to move back and forth between plan and load mode while performing essential actions.
Data stored in the ADSO function is equipped to move to an inbound table with the help of tools like Data Services. The data moving happens using SAP Cloud Platform Integration via PUSH. The DataStore writing API is open for third-party and external tools while the feature lacks a certification process.
The property is applicable on all the standard DataStore and staging objects. However, it’s not compatible with Inventor enables or Planning enabled function.
Data modeling in BW/4HANA is no longer rocket science. It’s a child’s play because of ADSO functions. Using them diligently and adequately leads to huge time and efforts savings in data modeling tasks while enjoying unmatched simplification and ease.
ADSO functions and its offering have made SAP BW/4HANA stand out from the crowd as a dependable data warehousing solution. With attributes like 100% accuracy in the transactions and analytics, using it is certainly the best bet to make.
With this solution, it’s easy to modify and leverage the current outdated landscape and embark on an impressive data warehousing journey. However, having professional and verified assistance to install, monitor, and manage SAP BW/4HANA matters the most.
At Stridely Solutions, one has the facility to ensure assiduous utilization of SAP BW/4HANA as there are seasoned SAP experts by your side. The entire data modeling journey become effortless than before.