What is the impact of the Advanced DSO to your existing SAP BW landscape?

[Former Member]

As described in my previous blogs (What’s new in SAP BW 7.4 SP8 and ADSO: Installation), SP8 for SAP BW 7.4 has introduced BW’s newest modeling object: the Advanced DSO. The Advanced DSO is BW’s new major modeling object that will play a central role in any SAP BW on HANA data model.

Image 1: Simplification of BW modeling objects

LSA vs LSA++

In classical non-HANA BW environments, the Layered Scalable Architecture (LSA) approach has been around for quite some time now. Focusing on creating a persistent corporate memory and creating datamarts for specific information needs, most SAP BW data models have been created using several persistent data layers.

When running BW on HANA, there is much less need for multiple layers of persistence. From both a performance aspect and modeling perspective, HANA offers possibilities to do a lot of joins/unions or even calculations using non-persistent objects such as CompositeProviders or even Open ODS views. The new modeling principles when running on HANA are bundled in the LSA++ approach.

So what is the actual impact of the introduction of the Advanced DSO to the LSA++ principles? Not much from an architectural point of view. The only real thing that changes here are the building blocks used in the persistent layer(s) in your data model.

For in-depth information about LSA vs LSA++ please see this presentation by Juergen Haupt

Advanced DSO as the main persistence object

The ADSO is the only object you need for persistence. That promise from SAP raises the immediate question how to deal with the specific characteristics of the classical modeling objects in BW.

•          The field-based structure of the PSA
•          The fast, no activation required loading of the WO-DSO,
•          The 3-table approach in standard DSO’s
•          The ‘every characteristic is key’ approach of the InfoCube.

The Advanced DSO manages to replace all of these objects by basically being all of them. In the ADSO settings you can make settings to have the ADSO behave like either one of these objects. SAP has provided specific templates for each use-case.

•          Data Acquisition Layer
•          Corporate memory
•          Data Propagation Layer
•          Reporting Layer

Each of these templates are made up out of a specific combination of settings. The data propagation layer for example would require you to check the checkboxes below. These settings create an object with an active table to report on, and a change log table for further data provisioning. Basically creating a classical Standard DSO.

Image 2: Settings for ADSO with Data propagation template

Image 3: Schematic overview of an Advanced DSO with Data Propagation settings

Added value

So what is the actual added value of the Advanced DSO, compared to the ‘classical’ objects? There is a number of reasons to use ADSO’s for new developments:

• Simplification of object types. Over the years, new functionality in SAP BW often meant new object types with their own strengths and weaknesses. If these objects had added value, that meant remodeling, reloading, added complexity. The ADSO is your object for persistence now, with settings to fine-tune it to your specific needs.
• Flexibility in data modeling. Because the ADSO is manageable by settings, you can start out modeling your ADSO using the Reporting Layer settings. If requirements change or you come across new insights, you can now simply change your settings to change that object into the propagation layer for example. No new object needed, this can even be done without losing data in most cases.

Concluding:

What is the impact of the introduction of the Advanced DSO to your existing landscape? Well, for starters it changes the way of working for most developers. Providing the flexibility for prototyping and iterative development by changing into settings-based object typing and field-based modeling can be complimentary to using Open ODS views for these use cases. As for immediate impact on existing data models: SAP does not offer migration tools or anything for this and advises customers to wait until this is available. The best advice is: use the ADSO for new developments, but leave existing developments as-is.