You are on page 1of 5

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 Us Hi, Guest Search the Community
Activity Communications Actions
Browse
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
1 Like
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 Views
Share 7
1 Like
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 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!
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 BW
data 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 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.
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 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.
Regards
Shankar
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 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.
Regards
Thomas
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 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.
Regards
Shankar
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 to
HANA, 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 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: https://www.experiencesaphana.com/docs/DOC-
1463
Hope 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 SAPJun 30, 2012 11:30 PM (in response to Thomas Zurek)
"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."
(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: "Custom
Data Marts"" from note Note 1661202 - Support for multiple applications on SAP
HANA ?
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 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.
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 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
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 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.
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.
Regards
Thomas
Yadwinder 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 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
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 SCN
Site 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 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 ..