Skip to Content

The “advanced” DataStoreObject – renovating BWs persistency layer

With BW7.4 SP08 another “feature package” was delivered with a lot of new functionality and optimizations based on the HANA platform (see In accordance with the BW strategy to deliver the HANA-based innovations and renovations non-disruptively to our customers the SP08 delivered a first step in renovating our Persistence Layer. With the possibilities of HANA we are able to consolidate all BW InfoProviders with persistent data into a single object with a single and simple data base layout. This is similar to the consolidation and simplification in the Virtual Layer based on the CompositeProvider.


Since its properties, table layout and services are closest to today’s DataStoreObject we simply kept the name. Only if we need to explicitly distinguish between the current object and the new object we add “advanced” DataStoreObject or “classic” DataStoreObject. This also emphasizes the role of BWs DataStoreObject as THE central building block for a Data Warehouse architecture.


Major features

New intuitive Eclipse-based modeling UI

The UI renovation continues. The ultimate goal: bring the heavy-weight modeling UIs to the Eclipse-world and the administration and monitoring UIs to the Web. With the Eclipse-UI for the advanced DSO it is now possible to model all InfoProviders of a complete end2end scenario in the BW Modeling Tools (from an OpenODS View, to the advanced DSO, CompositeProvider and BW Query). All this is deeply integrated and aligned with the HANA Studio and Modeler for all “mixed-case scenarios” and a unique modelling experience.


Combine field- and InfoObject-based modeling

The “higher” up in your architecture an InfoProvider is located the more important are the rich features of BWs masterdata modeled in an InfoObject (like re-usability, data consistency, visibility, and quality). But for new scenarios the InfoObject approach is a high hurdle, since it requests a top-down approach right from the start. With the Open ODS View we introduced in BW7.4 SP05 already a virtual field-based approach to integrate data without the need of having InfoObjects. With the advanced DSO this is now also possible for the Persistence Layer. I.e. you can load data into BW without assigning InfoObjects to each and every field without losing functionality.

In combination with the Open ODS View this approach allows you to integrate new data easily and fast, switching seamlessly from an e.g. even virtual data access to a managed persistence with an increasing level of data integrity. All this especially tabbing into “non-classic BW data” with the support additional data types and adapters.


High frequent data loads – based on optimized request management

The request management is, if you like, the cornerstone of BWs managed approach to Data Warehousing since it organizes availability and status of the data from the time it is requested of the source system up to the caching by the Analytic Manager (aka OLAP Engine) or the delta buffers of the integrated planning. With the size of the BW systems growing and growing, the complexity increasing and the demand for more and more (close-to-) real-time scenarios we decided to re-write our request- and process-management for the advanced DSO.

The current request management still works for the “classic” objects (DSOs, InfoCubes, …) and a single dataflow can work with both types as well. The “new request ID” (internally called “TSN” – Transaction Sequence Number) is no longer an INT4 value, but a timestamp plus a generated, increasing postfix. This not only removes the 2 billion limitation (for the system-wide number of requests), but also allows for new logic and new semantic derived directly out of the request. The new request management comes with a new “manage UI” directly accessible from the Data Warehousing Workbench that allows you to quickly navigate through very large sets of requests and protocols and perform manual tasks or monitoring activities.

Reporting performance optimizations

With the goal to replace the InfoCube we also had to make sure that some of the more complex (or “exotic”) reporting scenarios perform well. Two features are important to achieve this goal. Only in case of an INNER JOIN between the table with the facts and the masterdata table, can HANA perform optimal and BW can push OLAP operations to HANAs Calculation Engine. The check whether or not an INNER JOIN can be used (instead of a LEFT OUTER JOIN) is the BW referential integrity check during loading or activating the data (aka SID-creation, but is much more than just determining an INTEGER value). This check exists in the classic DSO as well (the so-called “BEx-flag” – the “create SIDs” option). But for the advanced DSO it is possible to set this flag not only on InfoProvider level, but individually per characteristic of the DSO. The data integrity check then is only executed on the selected characteristics.

The second feature is also related to the JOIN with the masterdata tables. Also HANA benefits from the fact that for an InfoCube JOINs to the masterdata tables are via INT4 values, compared to STRING JOINs for a DSO. In rare cases the performance difference can be crucial, e.g. if you have a compound, high-cardinality InfoObject like 0MAT_PLANT and the reporting mostly includes navigational attributes of this InfoObject and therefore forces this JOIN to be executed very often. In such cases you can, for individual InfoObjects(!), turn on the persistency of the InfoObject-SID in the DSO tables. An additional column will then be created in the active data table to hold the SID and will be filled during data activation.


And More

Just to mention a few additional highlights:Up to 120 key fields are supported. Template-based design using references to classic BW InfoProviders types or best-practice LSA++ templates. Integrated Remodeling for structural- or type-changes. DB-partitioning on all key fields. … and so on …



The advanced DSO will be the central persistency object in BW-on-HANA replacing especially InfoCube, classic DSO, HybridProvider and PSA. While there are still some gaps to cover the complete functionality, we recommend considering the advanced DSO for all new projects as the central (and only) persistency object. A widespread conversion of existing scenarios into advanced DSO is currently not recommended, but should be done only case-by-case and demand-driven. We plan to provide a conversion tool to support the conversion of objects in future SPs. The current persistency objects are of course still supported and do co-exist with the advanced DSO. There are no plans to change this.


New minor features will be added and some gaps will be closed in subsequent SPs (SP10, SP11, SP12) – a list can be found attached to note 2070577. Another “feature package” of the BW7.4 release is planned with SP13 (scheduled for Q4 2015). This “feature package” shall then close all major gaps between today’s functionality for InfoCubes, DSOs, PSAs and the advanced DSO. Additionally the advanced DSO is planned to support several new features like Dynamic Tiering (fka ExtendedStorage) support, direct- and Bulk Load enablement, … . And a conversion tool will then also allow you to convert existing InfoProviders into an advanced DSO.


Please check note 2070577 for the details according to your support package level. Additional and detailed information can be found in the SAP online help.

See here for a short video demonstrating the most important aspects.

You must be Logged on to comment or reply to a post.
  • Hello Klaus,

    regarding this statement -

    "With the advanced DSO this is now also possible for the Persistence Layer. I.e. you can load data into BW without assigning InfoObjects to each and every field without losing functionality."

    Does this mean an Advanced DSO can be modelled using a mix of infoobjects and fileds OR does it mean either infoobject modelling or field based modelling?



    • Hi Benedict,

      you can model a mix of InfoObjects and fields with only type description. In the above screenshot you see a advanced DSO where most fields have InfoObjects assigned, but there is also field COUNT without InfoObject. That's the cool stuff:-)

      Best regards, Klaus

  • Hi Klaus

    I am on 7.4 SP 9 and trying ADSO . After creating ADSO and created one Transformation and ran the DTP.  I can see the data loaded to Inbound Table.  But in DSO Manage Screen cannot find the "Activate"  data button. This is not available in Context Menu either.  

    I can see data in /BIC/A<name>1 but not in /BIC/A<name>2 which is logical.  Then I activated data from process chain and can see data in /BIC/A<name>2 . 

    What I am missing ?




    • Hi Anindya,

      this is an "aggregated" display of the loaded requests (see "Group by Day" Button to change this). Simply double-klick on the line and you will get the detailed list of requests with load- and activation-requests, logs, and actions buttons. You can personalize these settings in case you always want to see the detail list first instead of an aggregated list.

      Best regards, Klaus

      • Thanks Klaus

        I can see those now . Perfect!

        Will "Activate Data"  button  be available from context menu in future releases ?  And not sure why "Administer Data Target"  from process chain showing no request although I have data in that DSO.



        • Hi Anindya,

          the jump from the process chain still goes to the "old" request manage UI since there can be several DataTargets associated. We will adopt this in the coming releases.

          Best regards, Klaus

  • My settings for DSO is as below, which I think should behave as Standard DSO ( Classic)


    However, when I open "Administer Data Target"  from Process Chain step , no Request Id is shown although I have data in Active Table.




  • I am just learning how to work in HANA Studio and I am confused as to what I can do in HANA standalone and what I can only do in BW.  I have loaded data into HANA standalone using DXC.  I have created an ADSO using BWMT.  How do I create transformations from HANA standalone datasource to my ADSO?  Is this even possible?



    • Hi Sandy,

      also this is generally possible (e.g. via DBConnect), I would not recommend to use DXC in this scenario. DXC was implemented for the use cases where you want to utilize the BW DataSource logic into a standalone HANA DB, e.g. to implement HANA Views on top of it that you can consume then e.g. with Lumira.

      As you have a BW on HANA system and want to load into ADSO, there is no advantage in taking this costly detour.

      You should simply connect the source system at your BW system, replicate the BW data source(s) into BW and load the data via transformation/DTP into your ADSO.

      Best regards,


  • hi,

    my data request in the ADSO had been successful however, the activation has failed,
    Now it doesnot show any log of the errror due to which i am unable to find the issue or fix the activation error in this ADSO.
    Could you please  assist?

    Regards, Aparajit

  • - > Depending on the properties of the advanced dso not all of the tables are actively used

    Hi, where can I read about this tables  ?

    Regards, Alexander

    • Hi Alexander,

      I am not sure what kind of information you are looking for. We do not document the generated tables for BW objects since they are access via APIs and not directly by users/customers. If you want an overview of these tables, you find the list in the "properties" tab of the Modeling Tools for advanced DSOs with a link to SE11 for each table.

      Best regards, Klaus BWMT_ADSO_DDIC.JPG

      • Hi Klaus,

        Can I ask some questions for the reporting view and extraction view?

        if you look into those views, they are both based on Inbound table, but as you know, for example, like standard dso case, the extraction and report should be done from active table not from inbound table(because it is blank after activation), why this is designed like this? can you explain?

        • Hi,

          We create these DDIC views to have a well-defined source for both, extraction and reporting. Since the actual source table is dependent on the settings for a specific DataStore, we're replacing the database view according to the settings. To see the difference, you can have a look at dbacockpit or SAP HANA Studio.

          Best regards


          • Hi alexander,

            Thanks for your fast response.

            I know that based on different setting in HANA studio, the data base view could be different, but at least for standard DSO, both reporting and extraction should be done from active table not from inbound table as shown in below picture, but for my case, even I select the setting as standard DSO in hana studio, the reporting view and extraction view is based on inbound table, how to explain this?


          • Hi,

            what you're referring to is the DDIC representation of the view (SE11). The DDIC representation always points to the inbound table - independently of the ADSO settings.

            When we activate the ADSO, we activate the DDIC representation (this step generates a database view), then we drop the database view and re-create it according to the ADSO settings. Thus the DDIC and database representation of the view may differ for some scenarios. To verify this, please open the database view /BI*/A[DataStore][6|7] in dbacockpit or SAP HANA Studio (not SE11).

            Best regards


  • Hi everyone,

    "a widespread conversion od existing scenarios into A DSO is currently not reccomanded, but should be done only case-by-case and demand-driven. We plan to provide a conversion tool to support the conversion of infoobjects in future SPs".

    Is there any news about the sentence above?

    Does any conversion tool have been provided?



    • Hi Stefano,

      A transfer tool for the conversion of classic DataStores to DataStores (advanced) is planned for the next 7.50 feature package which is planned for SP4 (mid. of July this year).

      Best regards


  • Hi Klaus,

    I understand SAP has introduced capability to use ADSO for planning purpose. To this end, could you help me clarify below questions please?

    -When Advanced DSO used for Planning, would you need to define Aggregation level on Advanced DSO or Composite Provider?

    - Similar to Planning DSO (currently exist in 7.4 version), When Advanced DSO used for Planning, is it mandatory to fill all keys of DSO?

    - Similar to standard planning DSO introduced in 7.3 / 7.4 of BI, would Advanced DSO have the functionality to record commentary in Manual input?

    -When Advanced DSO used for Planning, would it record/update manual input as Insert only as oppose to Insert, Change, Delete function typically used in DSO?

    - Similar to Infocube, would it be able to capture delta in OLAP cache?

    Appreciate your response.



    • Hi,

      Thank you for your interest in the ADSO.

      We provide the planning feature for ADSOs that behave like an InfoCube (property "All Characteristics are Key, Reporting on Union of Inbound and Active Table"). For that flavor of DataStore, you don't have to deal with key fields since all characteristics are automatically handled as key. The manual input is recorded as "insert only".

      An aggregation level can be created based on the ADSO and based on a CompositeProvider. We recommend using a CompositeProvider since it's the only way to use navigational attributes.

      Commentary is not supported for this use case, the OLAP cache is able to capture delta data.

      We're planning to release the planning feature for ADSOs for direct update for the next 7.50 feature package which is planned for SP4 (mid. of July this year).

      Best regards


      • Hello Alexander.

        How are you?

        FOllowing the same line of thought I have a quesiton that is:

        We have two versions of BW 7.5: 'SAP BW 7.5 powered by  HANA' - where classic BW objects are allowed, such as aggregation levels - and version SAP BW 7.5 edition for SAP HANA add-on - that from my understanding does not allows the creation of classic BW objects.

        So my question is If I have the add-on version how do I do planning? Because I can't retract data to BW via aggregation levels they are classic BW objects.

        Thank you

        Maria Catarina Silva

  • Hello Klaus,

    Thank you for the document on ADSO.

    Is the Inbound table nothing but the New Data table of Standard DSO (Classic)?

    Is there any difference in the way how the data progresses across the three tables (Inbound, Active & Change log)?


    Vinoth V

    • Hi Vinoth V,

      Yes, the inbound table of DataStore objects (advanced, ADSOs) is equivalent to the activation queue of classic DataStores (ODSOs). However, the inbound table is not only used as queue for activations. In contrast to ODSOs, it’s the main storage for objects without an activation step (“write-optimized” or “corporate memory” use-case).

      Best regards


  • Hi Klaus, you wrote in

    Reporting performance optimizations:


    " In such cases you can, for individual InfoObjects(!), turn on the persistency of the InfoObject-SID in the DSO tables. An additional column will then be created in the active data table to hold the SID and will be filled during data activation."

    I cant see these columns in active data table in se11. Maybe there is another table with this information (not /bi0/s*) ?

    Thx, Mikhail.

    • Hi Mikhail,

      the SID-columns are part of the inbound table, active data table and change log. When looking at these tables in SE11, you'll see field names like O__[Name of InfoObject].

      As prerequisite you need to choose "Master Data Check During Load/Activation and Persist SID in DataStore" for a particular InfoObject in the Eclipse Modelling Tools.

      Best regards


  • Hello Klaus,

                        Am trying to create ADSO in Eclipse BWMT ... when i tried to add Info objects( Add info objects tab) it's not showing me all the existing info objects list in my BW system .

    Can you please advice what could be the reason ?



  • Hi Klaus,

    I have a question regarding remodelling of an DSO(advanced). Is it possible to remodel a DSO(advanced) designed to behave as a Standard DSO(template activate data) into Infocube type(All char are keys, reporting on Inbound and active table) DSO(advanced)?

    • Dear Manpreet,

      thank you for your interest in the DataStore object. Currently we don't support remodelling activities that lead to a changed behavior when data gets extracted. Thus converting a standard DataStore (extraction from change log) into a InfoCube-like DataStore (extraction from inbound table) is currently not possible.

      Best regards


      • Hi Alexander,

        I have one more question regarding the reporting and extraction Views that are generated for aDSO ( , what is the exact purpose of them? I do understnad that they are more targeted to be used using OpenSQL but I am not sure exactly how, also are the other tables( Active, Inbound, and Changelog) not accesible by OpenSQL if i generate a HANA view for the aDSO?



        • Dear Manpreet,

          we generate these views to have a well-defined interface for our internal DataStore extractor and query (see my answer from Mar 4, 2016 7:51 AM). The views should not be used by external users.

          Best regards


  • Hi Klaus & Alexander,

    thank you for the great document. I have a question regarding the Performance Optimization when creating the SID, if you could help me to understand it.

    My question has to do, with the reporting and building queries on top of ADSO (Data Mart Template). Will the queries be faster reporting on ADSO (Data Mart Template) or it is faster to build a CompositeProvider on top of this ADSO and build the queries on top of the ComposteProvider?

    Thank you in advance.

    Best Regards,


    • Dear Regys,

      thank you for your questions. We recommend using a CompositeProvider for your queries. We position the CompositeProvider as the main reporting entity for BW on SAP HANA whereas the DataStore object (advanced) is the main persistency entity. All reporting related settings (like enabling navigation attributes) can only be changed in the CompositeProvider. From a performance perspective, I would expect to see more or less the same response time.

      Best regards Alexander

      • Hi Alexander,

        do you know why navigational attributes cannot be activated in ADSOs?

        Why had this not been implemented in BW 7.40?

        For "prototyping" and fast query development to quickly check results this was quite helpful... and creating an additional CP only for that brings no real added value?!

        Thanks, Martin

          • Hi Martin,

            I don't think it's a bug. This was done on purpose, as mentioned in Note 2070577 : The focus of the advanced DSO is the persistency of the data. Extended reporting capabilites, e.g. navigational attributes, can be defined using the Composite Provider.

            When you think about it, prototyping a business scenario now takes (a lot) less than 1h. So 2 more minutes to create a composite provider on top won't make much difference ; ). Knowing that every temporary development quickly becomes a permanent one, the composite provider layer allows you to preserve your prototyping query even if your "temporary" DSO ends up changing (which, let's be honest, is the case 99% of the time in prototypes...).

          • Hi David,

            I agree, you can justify like this... then what is your explanation for those? 😉

            - I did not find a process chain variant to delete overlapping requests, like possible in regular cubes

            - I did not find a possibility to create an Export datasource to replicate into another BW System, for data extraction into it.

            - It looks like you can archive ADSOs only from 7.5, if I'm wrong, please let me know!

            Maybe there are corrections for it now. In 7.40 SP13 it is not available.

            I really can't see, what is "advanced"...

            BR, Martin

          • What's "advanced" in my humble opinion is the fact that SAP managed to introduce a new type of DSO where we don't need any infoobjects to store data, while making sure that these new aDSOs would be able to co-exist with older elements that used to live and breathe only through infoobjects and that they did so without disrupting the ecosystem of thousands of customers relying on BW day in and day out. I'm not sure how long you've been in BW to appreciate/realize the challenges of doing such a shift but for those who started with early BW releases, this is worth the term "advanced". 

            I agree with you that some features are missing but I've rarely seen a completely new technology being introduced with all the bells and whistles available on day 1.  Think of it this way : If someone was to create a new fully electric car that can do 0-60 in 2.5sec with 500km of real-life driving range, would you complain because there are no cupholders in the backseat?

            I saw that you posted some of your suggestions on the idea place. That's the best thing you can do and chances are that they'll be included at some point. SAP is improving software a lot faster than they used to. I've found workarounds for the few things I needed that were missing but I have to admit that the "delete overlapping request" was quite useful...

            KR, D.


    A quick note: Have been using BW740 Sp12 now for an year…What a pain is aDSOs. The great visibility of “Manage” screen if an old DSO has been taken away. We cannot see “DTP filters” , “source” on requests loaded. You can get Source name by double clicking on individual loaded requests one by one…a step backwards(still no DTP filters can be seen)!!!!  Once you get request number, We cannot track requests using RSRQ. if data being loaded from multiple sources, Manage screen is absolutely useless for aDSOs. Also when we try to go to DTP monitor from aDSO MANAGE screen, it always goes to actual DTP (and not monitor) if request is already activated.


    Please let us know if there is any delivered tool to view these details for Multiple requests together like we were able to see in standard old DSO.

    Overall our time spent in Support activities have been significantly increase after moving to 740 Sp12. 

  • Hello!

    A question regarding possible limits of key figures upon using ADSO and activating data (system support level SAPKW74013).

    In my scenario I'm using ADSO with template "classic objects - Infocube". The model consists of 20  characteristics and 83 key figures. Before I activate data all key figures are populated as desired.

    After activation of data key figure 54 upto 83 are simply set to zero value (= complete data loss). Characteristics and key figures 1 upto 53 are transferred fine. This happens independent of the amount of data I'm activating.

    So question is if there is any limitation in terms of key figures while activation data for ADSO.

    Thanks a lot.



  • Hi,

    first of all very good blog, thanks!

    I have two questions:

    1. Is there a way to maintain SID-settings on ADSO level (like possible with DSO), i can only do changes in details tab on characteristic level?

    2. Is it correct that the join with master data is performed over the characteristic values for DSO and ADSO and not with SID-values? Only exception is, if in ADSO setting „Save SID in Datastore“ was done?