What is the impact of the Advanced DSO to your existing SAP BW landscape?
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.
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?
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
Great, thanks Sjoerd.
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!
Tim
Hi Charles,
Thanks!
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
Hi,
it is mentioned in this article that SAP has provided specific templates for each use-case. Where can I find these templates?
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
Thanks Sjoerd ; Nicely explained 🙂
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,
Sundar
Just adding details on creation
Step by Step Procedure for Advanced DSO Creation
You might find this Document helpful
SAP First Guidance - Implementing BW-MT for BW-... | SCN
Best Regards Roland
Hi all,
Can I create ADSO for non cumulative key figures?
Thanks,
Sumit
Hi,
Roland below has the right of it, my apologies.
Sjoerd
Hi, yes you can.
Please have a look to the SAP Note 2070577 - (advanced) DataStore Object - availability in BW7.4 SP08, SP09 and SP10
and check the attachment - LimitationList - 20150310.xlsx
You will need at least 7.40 SP10 and HANA Rev. 85.02 for that. As the current Revision for SP08 is 85.04, you can go forward to this HANA Revision.
Best Regards Roland
Hi Sjoerd and Roland,
Thank you for the response. It really helped me.
Thanks,
Sumit
Hello Colleagues,
Is there any specific authorization or role for this in HANA??
Regards,
Akhil
Thanks for the info 🙂
Hi S. van Middelkoop
Is there any limitations on no.of fields/infoobjects for ADSO key fields as well as data fields?
Regards,
Krishna Chaitanya
Hi S.Van Middelkoop How to do the delta loads? regards Raj
Hi
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
Nice Post... 🙂