Skip to Content

How BW-on-HANA Combines With Native HANA

There is a lot of wild guessing on how to combine the native HANA tools and assets – like HANA modeler or SLT* – within a BW-based environment. Initially, one might assume a conflict between a completey managed table schema – as imposed by BW – and an arbitray table schema – as created by SLT, Data Services or any other tool. In this blog, I will indicate how such schemas can happily coexist and consequently complement each other in a BW-on-HANA environment. Before I start please note that the usual disclaimer applies.

The question laid out in the title of this blog is one that will determine our conceptual efforts well beyond the pending HANA and BW 7.30 – Part 2. However, ORANGE will already offer some interesting pieces that have already hit the nerve of some of our pilot customers in a positive sense. In order to understand the extent of this I’d like to start shedding some light into what’s happening:

  • BW – as many other products in the BI and EPM space – follows the approach that data models are created on a conceptual level. The best example is an infocube: the user uses characteristics, key figures, creates dimensions, sets properties etc. to the activate the infocube which, in turn, generates the physical layerunderlying the infocubes, meaning all the tables that represent the infocube physically. This becomes even more apparent when you look at the differences between the infocube in a classic BW (meaning BW sitting on a classic RDBMS) and in an ORANGE system (meaning BW-on-HANA): conceptually, the infocubes are identical but physically they are represented differently.
    Modeling conceptually and generating the physics underneath has a number of advantages like
    • query access generation can be optimized towards one pattern (like a star schema),
    • it is possible to load data into a conceptual / logical object of a fixed structure (see bidirectionalizationof views),
    • the user does not need to understand the implications of physical modeling (like do’s and dont’s, when and where to create indexes etc.),
    • standard patterns (e.g. naming conventions) make it easier to maintain a table schema.

    However, there might be a number of restrictions to such an approach. DBAs who are knowledgeable about table layouts, indexes and other relevant parameters for the physical layer might also argue that a hand-crafted schema can be (manually) optimized much better. This is correct but this becomes hard with data warehouses with 1000s of tables.

  • There is also the opposite approach, namely defining a (conceptual) data model on top of an existing set of (physical) tables. The universe designer, IDT or the HANA modeler are instances of tools that follow this approach. The fundamental advantage is that it is additive, i.e. it complements an existing table schema with some additional meta data. One of the disadvantages is the singularity of the conceptual models. Thus many of the advantages of the managed approach are absent in such a case. This is especially annoying as the layering typically found in data warehouses requires anyway to create new tables – and frequently a lot: 100s to 1000s – for which standard practices need to be defined in order to allow maintaining the system, e.g. for lifecycle activities. Still, for a modest set of tables (e.g. as in a typical data mart) this is certainly a quicker and leaner way.

In summary it is fair to say that both approaches are attractive depending on the scenario. In other words, there is no general “good” or “bad”. To that end, it is appealing to look at ways to allow combining the two appraoches. Therefore, let’s turn to figure 1 and walk you through the general idea:

  • Figure 1 pictures a HANA instance that hosts two schemas:
    • one managed by BW – as indicated by the (LSA) layers and tables for infocubes and DSOs, and
    • an arbitrary schema with some set of tables that have been created and filled via some mechanism like SLT or Data Services.
  • In the arbitrary schema, there exist some join paths, indicated by the black lines between the tables.
  • In the arbitrary schema and using the HANA modeler, tables can be combined to form an analytic view – see the grey polygon – which is basically a cube in the HANA terminology.
  • An analytic view can be analysed (following the green path) using one of the tools indicated on top like Analysis Office(via BICS) or Using Excel on HANA (via MDX).
  • Similarly, the schema on the left hand side is managed by the BW application which provides modeling tools, editors, lifecycle management tools, process definition (for moving data), scheduling and monitoring etc. infrastructure for that schema.
  • The BW-managed schema receives data from SAP extractors, other extractors, files or Data Services. Additionally, data is generated via the planning infrstructure.
  • BW’s analytic engine interpretes the semantics of the data models and translates it to HANA-optimised query accesses which are processed by HANA’s calculation engine. Data is exposed via various interfaces, mainly BICS and MDX (in blue).

Let’s look at 3 “bridges” – see the dark red numbers in figure 1 – that allow to link data from both schemas to each other:

  1. An analytic view can be exposed as a transient infoproviderin BW. Transient means that the analytic view is translated to an infoprovider at query runtime. This, in turn, means that any changes in the analytic view will automatically and immediately be visible in the corresponding transient infoprovider in BW. It is possible to build BEx queries on top of such an infoprovider and to use that query in all sorts of ways.
    Furthermore, it is possible to map an attribute in the analytic view to a characteristic in BW – within the context of the transient infoprovider**. Mapping to characteristics in BW has the advantage that hierarchies, navigational attributes and other features related to the BW characteristics (e.g. security) can be reused. Basically, this combines data / tables in the BW-managed schema with data / tables in the arbitrary schema.
  2. There are the BW workspaces. Here, composite providers can be modeled by an end user. Those composite providers can incorporate, amongst many other artifacts, analytic or calculation views in HANA (i.e. from an arbitrary schema). Please check the material on the BW workspaces for more details on all the options that this feature provides.
  3. Finally, a table, an analytic or calculation view in a HANA schema can be accessed via a BW DataSource. This is based on DB Connect using a second DB connection to the underlying HANA DBMS.

Sketch of a BW / non-BW mixed environment
Figure 1: Sketch of a BW / non-BW mixed environment.

In the longer term, there is certainly much more potential in such an approach. However, for the ORANGE scope and timeline it is a first good shot in my opinion.

* SLT = SAP Landscape Transformation or System Landscape Transformation
** That mapping, by the way, is – unlike the analytic view ⇒ transient infoprovider mapping – persisted and applied every time. Transaction code is RSDD_HM_PUBLISH.

Sketch of a BW / non-BW mixed environment
You must be Logged on to comment or reply to a post.
  • Would I run my "orange" BW on one hana "applicance" sized for my BW system and then run my traditional "HANA 1.0" type scenario using SLT for replication on a second hana "applicance"?

    Or you think SAP will allow us to do both of these scenarios on the same physical HANA box(and support it).

    Thanks as always for sharing your very detailed technical BW/HANA information!

    • Hey Alex,

      Hope you are doing well. you will be able to use a single HANA server  to host both the BW data and the non BW data (loaded using SLT, DS etc).
      Obviously you have to make sure the HANA appliance is sized accordingly.


    • Hi Alexander,
      it is meant that both schemas sit in the same HANA instance. Obviously the underlying appliance needs to be sized in a way that it can host the data volumes and workloads. The blog focuses on the options within the given boundaries.
  • Thank you very much for clarifying my confusion between the two approaches. Its a great blog.

    As per my understanding we can use transient infoprovider as a normal infoprovider in BW. If it is true then can i create a transformation between a infoprovider in BW and transient infoprovider?

    Doing this i would be able to send data from one infoprovider to another based on my requirement.

    Clarify me if my understanding is wrong. Thank you.


    • Hi Shankar,
      a transient infoprovider is like a virtual infoprovider, simply the meta data is transient rather than stale. That means that, yes, from a READ perspective it behaves like any infoprovider. But from a WRITE perspective there is no information, i.e. it cannot be a data target. So you cannot write data into the transient infoprovider; you can only write data directly into the tables that are accessed by the transient infoprovider.
      • HI Thomas,

        Thank you for your quick response.
        I understood and completely agree with what you mentioned. But if i am not wrong the transient infoprovider is just like a multiprovider (both are virtual which does not carry data physically) and as per some of blogs which i went through on BW 7.3, we can create a DTP on top of Multiprovider.

        So this question came to my mind based on the new developments in BW 7.3 thinking that we can create DTP on top of Multiprovider.

        Thank you for your clarification.


        So my last question is

    • Hi Deepu,

      so the virtual provider is an alternative to the transient provider - see "bridge" 1. in the blog. The virtual provider has some advantages over the transient provider: e.g. it can be transported and it can be part of a multiprovider. The disadvantage is that the virtual provider needs to be adjusted if the underlying analytic view (on HANA) is changed; the transient provider, in turn, is automatically adjusted.

      For details have a look at this document:

      Hope this helps.


      • "The disadvantage is that the virtual provider needs to be adjusted if the underlying analytic view (on HANA) is changed; the transient provider, in turn, is automatically adjusted."


        If you someone have time and patient while creating a Virtual Provider can create a Function Module/BAPI and it works 😀


        • Hi Mikhail,

          the virtual provider would be part of your BW-on-HANA system and reaches out - for example - to an analytic view inside a "custom data mart" on the same HANA system. I hope that this is what you were asking.


          • Maybe you know,  in this case are we must  additionaly purchase SAP HANA "Enterprise License"?

            Scenario - BW and "exceptions" applications residing on the same production SAP HANA system:

            SAP does support the deployment of BW residing on the same production SAP HANA system together with other applications listed in the "exceptions" section of SAP note 1661202, but please note the following key considerations:

            - The entire HANA system (including the part utilized by BW) must be licensed under the SAP HANA "Enterprise License" agreement.

            Note 1666670 - BW on SAP HANA - landscape deployment planning

  • Some day would we not have HANA Modeler or similar tools within BW as an additional tool to model analytic and calculation views within the BW managed schema. Then we could lose the distinction and have a more capable BW system that does what it does today and is enhanced with not just the HANA database, but the HANA tools as well.

      • I have attended SAP HANA hands on here and my feeling is that if someone is implementing new BI solution and planning to use HANA why would they go with BW on HANA ?

        As we all know that SAP HANA has non-materialized views and can be changed easily and gives you all kinds of transformation functionality.

        Only thing that might want you to consider going SAP BW on HANA is delivered contents. But in my discussion with instructor he told me that ECC BW extractor will be available to use in SAP HANA directly.

        I am still very confused with the direction of SAP BW product for future. And i love the way dimensional modeling is implemented in SAP BW. but with HANA and BO this modeling is taking same kind of approach, which other vendor like Cognos do.

        Thomas, Do you think it make logical sense for SAP to keep developing SAP BW in future ??? I don't see it ..

  • Hi Thomas,

    This is still  very valid blog for a lot of situations in my opinion. The actual tooling and possibilities however have evolved for quite a bit in the meanwhile. What's your view on this topic now, 3,5 years later?

    Kind regards,

    Sjoerd van Middelkoop

    • Hi Sjoerd,

      you are right. The general theme still exists and has proven to be very successful. In a customer workshop during Teched LV last year, 8 out of 10 customers reported that they ended up with a BW-HANA mixed case approach as described above, meaning that they leveraged BW where it is powerful, used native modeling where appropriate and even combined - e.g. - master data from BW with transactional data in the "HANA-only" schema. I think this is a win-win.

      Tooling, as you comment, has also evolved. HANA studio and the BW modeling tools in Eclipse combine smoothly. Hopefully, we will see the Design Studio modeler there (on the same Eclipse version) too. Then, you have all you need within the same tooling env. And it is a very rich set of tools.

      It is a general theme that drives our development efforts.



  • Hi Thomas,

    I have a procedure in SAP HANA which is generating some calculated fields. I need to populate the the data from this procedure into a table in my BW sytem. How can I achieve that?



  • Can we replicate the ECC tables to BW HANA Schema directly ? I heard the run time license does not allow this to do. I was said i have to load ECC data via slt to DSO directly through ODP instead of Direct replication to HANA schema ? Please throw some light on this please