7/21/2014 How BW-on-HANA Combines With Native HANA | SCN

http://scn.sap.com/people/thomas.zurek/blog/2011/11/01/how-bw-on-hana-combines-with-native-hana 1/5

Getting Started Newsletters Store

Products Services & Support About SCN Downloads

Industries Training & Education Partnership Developer Center

Lines of Business University Alliances Events & Webinars Innovation

Log On Join UsHi, Guest Search the Community

Activity Communications Actions

Brow se

thomas.zurek

Previous

post

Next

post

0 Tweet 1

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:

How BW-on-HANA Combines With Native HANA

Posted by Thomas Zurek in thomas.zurek on Nov 1, 2011 3:37:02 AM

Share 7 1Like

7/21/2014 How BW-on-HANA Combines With Native HANA | SCN

http://scn.sap.com/people/thomas.zurek/blog/2011/11/01/how-bw-on-hana-combines-with-native-hana 2/5

Average User Rating

(7 ratings)

My Rating:

0 Tweet 1

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.

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.

8921 View s

Share 7 1Like

16 Comments

Like (0)

Alexander Schuchman Nov 1, 2011 6:09 AM

Would I run my "orange" BW on one hana "applicance" sized for my BW system and then run mytraditional "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(andsupport it).

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

Balaji Krishna Nov 1, 2011 2:36 PM (in response to Alexander Schuchman)

Hey Alex,

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

Regards,

7/21/2014 How BW-on-HANA Combines With Native HANA | SCN

http://scn.sap.com/people/thomas.zurek/blog/2011/11/01/how-bw-on-hana-combines-with-native-hana 3/5

Like (0)

Balaji

Like (0)

Thomas Zurek Nov 2, 2011 12:23 AM (in response to Alexander Schuchman)

Hi Alexander,it is meant that both schemas sit in the same HANA instance. Obviously the underlyingappliance needs to be sized in a way that it can host the data volumes and workloads. Theblog focuses on the options within the given boundaries.Thomas

Like (0)

Chintada Shankar Nov 4, 2011 9:05 AM

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 istrue 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.

RegardsShankar

Like (0)

Thomas Zurek Nov 4, 2011 9:13 AM (in response to Chintada Shankar)

Hi Shankar,a transient infoprovider is like a virtual infoprovider, simply the meta data is transient ratherthan 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 youcannot write data into the transient infoprovider; you can only write data directly into thetables that are accessed by the transient infoprovider.RegardsThomas

Like (0)

Chintada Shankar Nov 4, 2011 11:31 AM (in response to Thomas Zurek)

HI Thomas,

Thank you for your quick response.I understood and completely agree with what you mentioned. But if i am not wrongthe transient infoprovider is just like a multiprovider (both are virtual which doesnot carry data physically) and as per some of blogs which i went through on BW7.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.3thinking that we can create DTP on top of Multiprovider.

Thank you for your clarification.

RegardsShankar

So my last question is

Like (0)

Deepu Sasidharan Apr 20, 2012 9:54 PM

Hi Thomas, The scenario mentioned in the youtube video below uses Virtual Provider to connect from BW toHANA, is this a new functionality or same as the BW Workspace option mentioned in your blog? http://www.youtube.com/v/PSolvEVN_O4?autoplay=1 Thanks,

Deepu

Like (0)

Thomas Zurek Apr 23, 2012 9:02 AM (in response to Deepu Sasidharan)

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 betransported and it can be part of a multiprovider. The disadvantage is that the virtualprovider needs to be adjusted if the underlying analytic view (on HANA) is changed; thetransient provider, in turn, is automatically adjusted.For details have a look at this document: https://www.experiencesaphana.com/docs/DOC-1463Hope this helps.Thomas

7/21/2014 How BW-on-HANA Combines With Native HANA | SCN

http://scn.sap.com/people/thomas.zurek/blog/2011/11/01/how-bw-on-hana-combines-with-native-hana 4/5

Like (0)

Pheno SAP Jun 30, 2012 11:30 PM (in response to Thomas Zurek)

"The disadvantage is that the virtual provider needs to be adjusted if the underlyinganalytic view (on HANA) is changed; the transient provider, in turn, is automaticallyadjusted."(Thomas) If you someone have time and patient while creating a Virtual Provider can create a

Function Module/BAPI and it works (headache)

Like (0)

Mikhail Budilov Jul 6, 2012 12:27 AM (in response to Thomas Zurek)

Hi Thomas. Is the virtual provider on HANA view in this case has a type - "Definition: "CustomData Marts"" from note Note 1661202 - Support for multiple applications on SAPHANA ?

Like (0)

Thomas Zurek Jul 6, 2012 8:41 AM (in response to Mikhail Budilov)

Hi Mikhail,the virtual provider would be part of your BW-on-HANA system andreaches out - for example - to an analytic view inside a "custom datamart" on the same HANA system. I hope that this is what you wereasking.Thomas

Like (0)

Mikhail Budilov Jul 6, 2012 9:38 AM (in response to Thomas Zurek)

Maybe you know, in this case are we must additionalypurchase SAP HANA "Enterprise License"? Scenario - BW and "exceptions" applications residing on thesame production SAP HANA system: SAP does support the deployment of BW residing on the sameproduction SAP HANA system together with other applicationslisted in the "exceptions" section of SAP note 1661202, butplease 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 deploymentplanning

Like (0)

Mikhail Budilov Oct 25, 2012 6:17 PM (in response to Mikhail

Budilov)

I find out. Yes we must purchase Enterprise edition in this case.

Like (0)

Vineet Gupta Jul 6, 2012 4:00 PM

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

Like (0)

Thomas Zurek Jul 9, 2012 3:42 PM (in response to Vineet Gupta)

Hi Vineet,this is roughly the direction that we are also discussing.RegardsThomas

Yadw inder Sandhu Oct 3, 2012 7:18 PM (in response to Thomas Zurek)

I have attended SAP HANA hands on here and my feeling is that if someone isimplementing new BI solution and planning to use HANA why would they go withBW on HANA ? As we all know that SAP HANA has non-materialized views and can be changedeasily and gives you all kinds of transformation functionality. Only thing that might want you to consider going SAP BW on HANA is deliveredcontents. But in my discussion with instructor he told me that ECC BW extractor

7/21/2014 How BW-on-HANA Combines With Native HANA | SCN

http://scn.sap.com/people/thomas.zurek/blog/2011/11/01/how-bw-on-hana-combines-with-native-hana 5/5

Follow SCNSite Index Contact Us SAP Help Portal

Privacy Terms of Use Legal Disclosure Copyright

Like (0)

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 lovethe way dimensional modeling is implemented in SAP BW. but with HANA and BOthis modeling is taking same kind of approach, which other vendor like Cognosdo. Thomas, Do you think it make logical sense for SAP to keep developing SAP BWin future ??? I don't see it ..