Co-authored with Klaus Nagel; originally published here – from where it disappeared when the site got reorganised.
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 3rd party 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.
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 alpha-conversion, 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 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 façade for SAP BO Web Intelligence on BW.
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, let’s 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. the OLAP 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 concept are 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, like compounding, 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 complex calculations that need to be done on top. Simple conversions, like currency conversions, or a simple formula won’t 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 “SQL-affine” 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 SQL-access 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.
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.
- Generating HANA Models for BW InfoProvider:
- OSS note 1764251 – Documentation- Importing BW Models in SAP HANA Modeler
- The mixed scenarios – reporting on HANA models in BW: http://www.experiencehana.com/docs/DOC-1463
- The HANA-EDW strategy: to be published soon
- The OLAP-Compiler blog:
- OSS note 1682131 – SAP BW tables in SAP HANA Information Views not supported
- BW-on-HANA FAQs: http://www.saphana.com/community/learn/solutions/net-weaver-bw/bwonhanafaq
- Videos on how to generate HANA views from BW models via the HANA modeler: