Skip to Content

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.

Simplification BW74.png

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.


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.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Kevin Small

    Thanks for posting this. A couple of questions:

    1) Do you know if the ADSO allows field associations to InfoObjects in the same way Composite Providers and Open ODS Views do?

    2) Can I swtich a single field in an ADSO to be an InfoObject without losing data?

    1. Former Member Post author

      Hi Kevin,

      1) Associations as in Open ODS views do not exist here, it is either InfoObject Identification or Field identification. No associations to Open ODS views seem to be possible.

      2) Yes, this is possible, but you need to take data types and length in account here. There is no warning there when changing it losing data in that field when you have a mismatch. Also, it is only possible for fields that are not key fields.

      Kind regards,

      Sjoerd van Middelkoop

  2. Former Member

    Great Post!

    I’m in a system w/ the latest service packs but I’m not having any luck creating an ADSO. Do you have a procedure to follow?  When i create an open ods view from rsa1 > and select advanced dso > a dso named object is required. When i try to create an ADSO from HANA Studio > BW Modeling > Infoprovider Folder > it asks for an InfoProvider or Model … no luck there either …

    Thanks for the help!


    1. Former Member Post author

      Hi Charles,


      Creating an ADSO should be pretty straight forward, just go to the path you described, and to an InfoArea of your choice. Right click the InfoArea, select new > Advanced Datastore Object

      Then enter your technical name and description. Object or model templates are optional, not required.

      Good luck!

      Sjoerd van Middelkoop

    1. Former Member Post author

      Hi Robert,

      Nice seeing you here as well 😉

      When creating an Advanced DSO in BWMT, the option called ‘Model Template’, all the way at the bottom of the prompt, allows you to select one of the templates when clicking Browse.

      The model templates are:

      – Data Acquisition / Persistent Staging area

      – Corporate memory

      – Corporate memory with compression

      – Corporate memory with compression and delta load

      – Data Propagation Layer

      – Reporting on active data only

      – Reporting on union of active table and inbound queue

      Classic objects:

      – Standard DSO

      – Write-optimized DSO

      – InfoCube

      Kind regards,

      Sjoerd van Middelkoop

  3. Former Member

    Hi Sjoerd van Middelkoop,

    Nice article! What about SPOs on Advanced DSOs? Is it supported? I don’t have authorization yet to create an ADSO but just curious as to how does ADSO handle huge volume of data.

    Thank you & Regards,


  4. Former Member

    My question is based on a failed request using ADSO, am unable to find the red request so i can delete and rerun the DTP step.
    Please assist on how to go about.

    I used the following table to try and look for the request: RSMONICDP and RSICCONT


Leave a Reply