HANA-Native Reporting on

BW Data in #BWonHANA
Positioning
created by Thomas Zurek on Mar 13, 2013 3:26 AM, last modified by Jens Rolke on Feb 5, 2014 11:25 AM

by Klaus Nagel, Thomas Zurek

An important part of the whole BW-on-HANA story is the option to create scenarios where data owned
and modeled within BW and data owned and modeled within native HANA tools interact. This is what we
call mixed scenarios. The interaction can happen in both directions, from HANA to BW and vice-versa, and
there are options to physically move the data or to virtually expose the data see picture 1 for an
overview.

Picture 1: The mixed scenarios in BW-on-HANA.

In this paper, we focus on the option of exposing BW data natively in HANA as HANA views that point
directly to the data and tables managed by BW. This enables HANA-native consumption of BW data
(picture 2). Rather than describing in detail how this works see below for links to more details - we intend
to position this functionality and describe when this option makes sense and when not. This covers not
only the currently available features, but also the mid-term plans and long-term strategy for BW-on-HANA.

Picture 2: Consuming BW InfoProvider data natively in HANA

Goal and Intention

The goal is to provide a clean interface between the BW-managed schema and an area that is managed
outside BW, e.g. by other tools or by a project team taking over management and semantics that are built
on top. The interface intends to make it very clear where BW's services end and where manual or 3rdparty
enhancements start. In that way, it gives room and provides freedom for arbitrary designs and scenarios
which goes along with the respective responsibility for those enhancements. It is clear that the generated
HANA views are limited and cannot expose all semantics defined and available in BW. However, they
provide a well-defined and phantastic opportunity for arbitrary and externally managed scenarios.

As-Is
Since HANA SPS5 and BW7.30 SP8, it is possible to use the BW model import wizard in the HANA Studio.
It generates a HANA view based on the BW InfoProvider metadata directly on the BW tables. The HANA
view partially contains some BW-specific metadata, like key figures with currency-dependency, the alphaconversion, but also an automatic filter on the visible data. If requested, HANA analytic privileges can be
generated based on the BW analysis authorizations. See links under 1. for details. The HANA views can
be generated for (HANA-optimised) DSOs, InfoCubes, and QueryProvider-snapshots.
The major use case for these generated HANA views is to enabling non-OLAP, search & discover clients
like SAP Lumira (fka Visual Intelligence) and SAP BO Explorer directly on BW data. In some cases, it can
also be used for the "SQL-like" consumption of BW data (in contrast to OLAP-consumption) and then
replace e.g. the SAP BO Data Federator faade for SAP BO Web Intelligence on BW.

Next Steps
With BW7.40 SP5 (planned for Dec 2013), this HANA view generation will be extended by a new option.
It will be possible to trigger the generation (and re-generation) directly during the BW InfoProvider
activation, i.e. the HANA view is part of the BW InfoProvider life cycle and the fact that a BW InfoProvider
has a dependent HANA view is part of its metadata (which can be delivered, transported etc).

Additionally, the HANA Analytic Privileges are automatically mapped against the BW Analysis
Authorizations at query runtime and updated as part of the BW life cycle management. This HANA view
generation can be enabled for most of the BW InfoProviders, including the new CompositeProvider.
This broadens the scope to a real application interface similar to the existing RSDRI-interface of BW.
New and existing applications can now program against these generated HANA views since their
structure and naming is stable and part of the BW life cycle management and shipment. Nevertheless it is
still an access to BW's raw data not an access to BWs Query/OLAP layer with additional calculations
and conversions.

What is it not
For clarity, lets start out with what this functionality is NOT. It is NOT meant as the general replacement
of the BW OLAP Engine. The latter is very much alive, will be enhanced and evolved towards an Analytic
Manager - see e.g. theOLAP Compiler.
That renaming very much describes the new scope in the context of BW-on-HANA: instead of processing
only the base (commutative) aggregations in the DB server and all subsequent calculations in the
application server, the BW Analytic Manager is a broker that compiles an execution plan (or OLAP
calculation graph) and delegates operations in the right sequence to HANA for optimal performance. This
way, the huge efforts that customers have invested over many years into creating thousands of fine-tuned
models and queries that hold their analytic IP that distinguishes themselves from their competitors is safe.
Those models, queries , KPI definitions, security and audit setups that have undergone many reviews,
careful fine-tuning and other optimisations, can be leveraged non-disruptively using the same BW
processing paradigm but doing the actual processing and heavy lifting inside HANA. Complex business
queries are translated into statements against the raw data in the database without giving up on the
huge performance improvements HANA can bring to analytics. The first steps in this direction are already
visible with the push-down of restricted keyfigure calculations, hierarchy aggregation, currency conversion
and exception aggregation etc. And more will come with each new release. This new architecture is
labeled as the OLAP layer concept and is motivated in this blog.
In addition to the strategic evolution of the BW OLAP Engine towards the Analytic Manager, it is a crucial
element of the entire BW-on-HANA story as a highly integrated (E)DW solution. It is a critical strength of
BW that its complete reporting (and planning) layer is not decoupled from the data warehousing layer but
tightly integrated. They share not just the same metadata, but also build on a deep understanding of the
processes that are running in one or the other. Simply take the consistency mechanisms, technically built
around 0REQUID, that span both, the reporting and data warehousing layers. It is not the intention (and
actually impossible) to list all the ways of how these layers interact in this document. When you think
about leaving one layer out you should think twice and keep in mind that you miss many things only
when they are gone.

Some key areas that have to be thoroughly evaluated are:

BW analysis authorizations concept versus HANA analytic privileges BW works with the barrier concept, HANA
with automatic filtering,

disconnected content/model life cycle, especially if extended models are created on top of the generated HANA
views, but also related to locking, naming convention, impact analysis, ,

BW managed data life cycle and aging mechanism like nearline-storage and the active/non-active data conceptare
only visible and fully functional using the BW reporting layer,

BW's partitioning and derived pruning mechanism are optimised for loading and reporting this is missing if the
reporting layer is detached,

planning and write-back in general is not enabled on HANA views, and furthermore requires an in-depth
integration of the layers as it is provided with BW-IP/PAK and BPC,

internal and external value representations: simple value conversions like alpha conversion and currency shifts are
available, but others, e.g. customer-coded exits, cannot be automatically transferred, but have to be re-modeled in
HANA,

enhanced semantics of InfoObjects cannot be completely or partially inherited by the generated HANA views,
likecompounding, default-client formatting, inventory-logic or exception aggregation for keyfigures. This needs to
be re-modeled in extended HANA views or in the client consuming the HANA views,

handling of hierarchies is deeply embedded with the BW Analytic Manager and is a core feature and strength of
BW-on-HANA. Hierarchies cannot be exposed via generated or extended HANA views (at least midterm),

Since the BEx query basically is the parameterisation of the BW Analytic Manager, the BEx query itself will
continue to exist and we will also invest in it to make sure it keeps up with the evolution and innovation
around it.

So, what is it then?

It is an alternative access method to rawBW data which, in the higher layers of the (E)DW is clean,
harmonised and integrated for consistent analysis and reporting! It perfectly suites the discover and
exploration type of clients which, due to their access pattern, require an extremely thin stack to achieve
the performance necessary for such kind of end user interaction. This thin stack not only excludes BW,
but excludes basically any middleware and all complexcalculations that need to be done on top. Simple
conversions, like currency conversions, or a simple formula wont cause an issue. But models with complex
formulas, stacked aggregations (exception aggregation), inter-dependencies, inter-cell calculations,
sequence constraints etc. will most likely not perform as well as expected as soon as the data volume
grows into the tens or hundreds of millions of rows. For the latter scenarios, we recommend building
specific, materialised data marts using QueryProvider-Snapshots or standard BW InfoProviders with
transformations and generate HANA view on top of these.
Additionally, it is possible to have selected vertical scenarios where a direct consumption with a "SQLaffine" client (e.g. SAP BO Web Intelligence) shows a better performance and the lack of calculation
features and the lack of integration is acceptable.
SAP and non-SAP applications that used (or would use) the RSDRI-Interface of BW can move to a SQLaccess against the generated HANA views not so much due to performance reasons, but rather to
enable SQL features that are not exposed by the RSDRI-Interface.

Final words
BW-on-HANA is the strategic (Enterprise-) Data Warehouse solution from SAP offering a highly
integrated platform for Data Warehousing, reporting and planning. BW is the bracket around the layers,
processing and orchestrating the data management and exposing and integrating new features of an
(E)DW and options based on our innovation platform HANA.

Links:
1.

Generating HANA Models for BW InfoProvider:

a.

http://www.saphana.com/docs/DOC-2771

b.

http://www.saphana.com/community/blogs/blog/2012/09/27/modeler-unplugged-episode-11--importing-bw-modelsas-native-hana-models

c.

OSS note 1764251 - Documentation- Importing BW Models in SAP HANA Modeler

2.

The mixed scenarios reporting on HANA models in BW: http://www.experiencehana.com/docs/DOC-1463

3.

The HANA-EDW strategy: to be published soon

4.

The OLAP-Compiler blog: http://scn.sap.com/community/hana-in-memory/blog/2013/02/18/the-olap-compiler-in-

5.

OSS note 1682131 SAP BW tables in SAP HANA Information Views not supported

6.

BW-on-HANA FAQs: http://www.saphana.com/community/learn/solutions/net-weaver-bw/bwonhanafaq

7.

Videos on how to generate HANA views from BW models via the HANA modeler:

a.

http://www.saphana.com/community/blogs/blog/2012/09/27/modeler-unplugged-episode-11--importing-bw-models-

bwonhana

as-native-hana-models
b.

http://www.saphana.com/community/blogs/blog/2012/10/04/modeler-unplugged-episode-12--understanding-hanamodels-imported-from-bw
23233 Views Categories: SAP BW powered by SAP
HANATags: data_modeling, explorer, business_warehouse, bw_7.3, bwonhana