Anda di halaman 1dari 10

Reporting on HANA models in BW -on-HANA

Contents
Author...................................................................................................................................................... 1 Introduction............................................................................................................................................. 1 Mixed Scenarios ...................................................................................................................................... 1 Transient Provider based on HANA models ......................................................................................... 2 How are authorizations handled? ....................................................................................................... 3 CompositeProvider how to connect to BW data? ............................................................................ 5 Virtual Provider based on HANA models ................................................................................................ 6 Usage recommendations ........................................................................................................................ 7 General aspects of BW reporting on complex HANA models .............................................................. 8 Outlook .................................................................................................................................................... 9 References ............................................................................................................................................. 10

Author
Klaus Nagel: Development Manager, TIP In-Memory Platform BW (SAP AG). Klaus Nagel joined SAP 10 years ago and started as a Developer in the BW team. He now holds the position of Development Manager and leads the BW&HANA Data Management team.

Introduction
You can deploy (operational) DataMarts on SAP HANA loading data via SLT (real-time data replication) or SAP BO DataServices. And use the SAP HANA Modeler to create so-called Analytic Views or Calculation Views. These DataMarts are consumed directly using HANAs SQL or MDX interface. With BW7.30 SP05 and HANA SP03 HANA can be deployed as the database of BW replacing the traditional relational databases and making a BW Accelerator superfluous.

Mixed Scenarios
In certain cases it is possible to run HANA as database for BW and the HANA Modeler-defined (operational) DataMarts in one instance (see SAP note 1661202 for the most up to date list of supported scenarios [4]). The data is then separated by different HANA database schemas. For an overview and introduction have a look at the SDN blog by Thomas Zurek [3]. See e.g. [5] for more information, how-to and best-practices for HANA models.

The question arises how in these mixed scenarios HANA-modeled operational Data Marts can participate from BW services and be integrated with BW managed data? BW offers in these mixed scenarios a completely new and promising way of: Integrating HANA DataMart scenarios with o the established BW reporting environment (clients, monitoring, user management, ), o with the consolidated, staged BW data, Leveraging new ways of loading and modeling data directly in HANA for BW

Figure 0: Two schemas (BW and non-BW) in one HANA instance. The current BW version offers two features for integrating HANA views: Transient Providers supporting Ad hoc scenarios thus a volatile context Virtual Provider supporting central modeling scenarios thus a more stable context

Transient Provider based on HANA models


A so-called Transient Provider is an InfoProvider in BW that is not modeled in the classic sense in BW, but generates its BW InfoProvider metadata out of the metadata (e.g. the describing InfoObjects) of the source. Of course also a Transient Provider is defined by InfoObjects but these InfoObjects are also transient, i.e. also generated from the definition out of the metadata of the source fields. The concept of Transient Provider is new with BW7.30 and as of today there are several types of Transient Providers implemented in BW (you can find more information on this topic e.g. here [1]). Transient Providers can be used similar to other BW InfoProviders for reporting, either directly or by creating BEx Queries on top. Their biggest advantage is that the metadata in BW is not persisted, but always generated at runtime, i.e. if the source metadata is changed the Transient Provider is adapted automatically. The Transient Provider is therefore especially helpful in ad-hoc and/or frequent changing scenarios (e.g. when integrating local, departemental data). BEx Queries built on top can adopt to changes automatically as far as possible, e.g. no longer available characteristics are automatically deleted from the Query, but Queries with complex formulas and restrictions may not be able to adopt. If BW runs on HANA as database (in the later BW-on-HANA), it is possible to publish HANA models (Analytic or Calculation Views, not Attribute Views) as a Transient Provider, i.e. you have to say I want to use this HANA model also in BW without this step you would otherwise see all HANA models e.g. in the BEx Query Designer. To publish a HANA model in BW, you simply execute the

transaction RSDD_HM_PUBLISH, select the HANA model (using the F4-help) and then save. You then have a Transient Provider with the characteristics coming from the dimensions of the HANA model and the keyfigures coming from the measures. You can now create BEx Queries on top and report on the data using the standard clients on top of BW. Notes and restrictions: You only see those HANA models that are visible for the generic R/3 user in HANA. The access to the HANA database and metadata happens via the R/3 user, not the named user. So, in order to have a HANA model available for BW reporting the Analytic Privileges in HANA have to be granted to the R/3 user. The complete name of the HANA model must not be longer than 63 characters (DB schema, package name, model name). The technical name of the Transient Provider is then: @3 + HANA model name/alias where the alias can be set in the above transaction. The column names of the HANA model (dimensions and measures) must be UPPER CASE and the name must not be longer than 63/52 characters (dimensions without/with description) and 57/55 characters (measures without/with currency conversion). In case a column name fulfills the length restrictions for BW InfoObjects, the transient InfoObject names are derived, otherwise a technical alias is chosen. The names are then: Providername + @ + column name/Alias

For a deeper integration with BW it is also possible to attach a little BW metadata enrichment to this type of Transient Provider. This enrichment allows for example to assign real BW InfoObjects to a transient InfoObject of the Transient Provider, i.e. to a characteristic or keyfigure of the corresponding dimension/measure of the HANA model. This enrichment is defined on the tabs in the transaction. The details can be found in the SAP online-help. In short, a transient InfoObject in the Transient Provider can reference to a real InfoObject and thus inherit its Meta- and Masterdata (like description, texts, display properties, display attributes and hierarchies). I.e. you can create a BEx Query on pure HANA data and model, but use a BW hierarchy and the BW hierarchy processing! Note: Navigational attributes of an assigned InfoObject cant be used directly (this would require an additional modeling step to turn on/off the navigational attributes). Instead you can create a CompositeProvider combining the Transient Provider with the Masterdata Provider in order to use also the Navigational Attributes of an InfoObject for reporting (see more on CompositeProviders with Transient Providers below).

How are authorizations handled?


As mentioned above, to be able to publish a HANA Model in BW the generic R/3 user has to be enabled with full access rights to the model (see also note 1612696). But for the actual read access during Query execution the named user in BW is the relevant user: The Analytic Privileges for this user in the HANA model are checked, and, if a BW InfoObject is assigned, the Analysis Authorizations in BW are also checked. If a characteristic of the Transient Provider has both, restrictions based on Analytic Privileges and Analysis Authorizations, the filter conditions are combined via a UNION (i.e. the user must have access either based on the Analytic Privileges or the Analysis Authorizations to see data). In case the check is negative, i.e. the query filters do not match the authorization restrictions, access to the data is denied (as it is standard behavior for BEx Queries).

Note: The technical name of a Transient Provider based on a HANA model always starts with @3. This naming convention can be used to create BEx Query Design and Execution authorizations (authorization object S_RS_COMP, S_RS_COMP1). A simple flow is sketched in Figure 1: At Query runtime the BW Analysis Authorizations are processed: For characteristics with a BW InfoObject assigned, the Analysis Authorizations of the BW user are matched against the Query filter. Then the Analytic Privileges for the BW user are read from the HANA model and matched against the Query filter. If any of the checks fails, the Query is aborted, else the data is read (with access via the R/3 user). Note: This means, that in HANA a user ID has to exist equal to the user ID in BW and this user must have access to the HANA model (there is currently no user ID mapping between the NW application server and HANA). Analytic Privileges in HANA work as automatic filters, i.e. the filters in the Analytic Privileges are added to the filters of the read access. The BW Analysis Authorizations work as boundaries, either the user is allowed to see all data of his read request - or none. In order to be consistent, the Analytic Privileges of a HANA Model are handled as the BW Analysis Authorizations in case of consumption via BW.

Figure 1: Analysis Authorizations during Query runtime.

CompositeProvider how to connect to BW data?


The CompositeProvider is a new Provider type in BW7.30 designed to easily connect BW-managed data to non-BW-managed data leveraging the full power of SAPs in-memory technology (either BWA or HANA). You find more details about the CompositeProvider in [1] and [2]. The non-BW data can be an Analytic Index created with the Analysis Process Designer (APD) or an Excel file easily uploaded with the Workspace Designer or a Transient Provider based on a HANA model. To model such a CompositeProvider you can either use the BW backend transaction RSLIMO/RSLIMOBW or the Workspace Designer (an easy to use, Browser-based tool). Figure 3 shows the graphic preview in the Workspace Designer where a MultiProvider and a Transient Provider are connected via UNION and additionally data coming from an Excel file is added via an INNER JOIN.

Figure 2: Composite Provider combining a Transient Provider, based on a HANA model, a MultiProvider and a local Provider, based on data uploaded from an Excel sheet. Shown in the BW Workspace Designer.

Virtual Provider based on HANA models


The concept of Virtual Providers in BW is well described. It offers a very flexible way of integrating data not stored in BW Objects into the consistent BW world. With BW-on-HANA we offer a new type of Virtual Provider, the so-called Virtual Provider based on a HANA model. As of now only Virtual Providers based on Analytic or Calculation Views are possible. See section Outlook for plans to make Virtual Masterdata Providers based on Attribute Views in HANA. You model such a Virtual Provider like any other Virtual Provider, i.e. you add InfoObjects as characteristics or keyfigures, but instead of assigning a DTP or a function module, you assign a HANA model to the Provider. Then you map each InfoObject needed for querying to a field of the HANA model (note: not each field of the HANA model has to be mapped to a characteristic or keyfigure, you can leave out some as well). You can turn on Navigational Attributes for the Virtual Provider as usual. Then you can map the Navigational Attribute also to a field in the HANA model in the Provider specific properties if you do not map it, the data comes from the Masterdata tables in BW. Note: If you filter or group by a Navigational Attribute in a Query the JOIN between the facts (the HANA model) and the Masterdata can be pushed to the HANA Engine (as opposed to the behavior for classic Virtual Providers). But since the referential integrity between values in the HANA model and the BW Masterdata cant be guaranteed, this has to be processed as an OUTER JOIN which has a less optimal performance than an INNER JOIN. We are planning some additional modeling capabilities to improve the handling in some cases, see below for the planned additional features. Such a Virtual Provider can be transported as usual, it can be used in a MultiProvider and BEx Queries can be built on top, just like for any other Virtual Provider. Note that it is not necessary that the HANA model is available in the target system of a transport. The activation of the Virtual Provider will work, but will issue warnings saying that the HANA model is missing. This decouples both objects and lets you transport in either sequence. Analysis Authorizations are handled complete by BW, based on the modeled InfoObjects, i.e. possible Analytic Privileges in the HANA model are not taken into account. But the HANA model itself has to be accessible for the R/3 user of course. Performance: The data read access at Query runtime is not via SQL, but it uses the same special Analytics API that we use to access data in InfoCubes, DSOs, and MultiProviders. This enables the BW Analytic Manager to push down operations to HANA instead of performing them in the application server.

Figure 3: Maintenance Screen for Virtual Provider. Mapping of InfoObjects to fields in the HANA model.

Usage recommendations
In general, the concept of the Transient Provider has the biggest appeal in the context of ad-hoc models with frequent changes and a limited durability. The fact that no, or only very few, metadata is persisted in BW, but generated on the fly allows very quick turn-around times and a trial-and-error approach. But this freedom and flexibility comes of course at a price and the price here is durability, consistency and coherence. You cant transport a Transient Provider and so you have to publish the HANA model in each system where you want to use it. For the more long term and stable requirements we instead propose the new VirtualProvider, based on HANA model.

General aspects of BW reporting on complex HANA models


What type of HANA model should be used for reporting in BW? HANA offers highly sophisticated modeling capabilities and a lot of openness, e.g. by defining a SQL-script node in a Calculation view. Reporting on such a complex model in BW can have some surprises, since both layers have engines (the BW Analytic Manager (aka OLAP Engine) and the HANA Calculation Engine) that are not fully aware of the processing steps of each other. This leads to problems e.g. if operations are not commutative. Example: Start with a simple table in HANA that contains the fields year, product, number of items, amount paid as below: Year 2010 2010 2010 2011 2011 2011 Product A B C A B C Number of items 3 5 3 7 4 2 Amount paid 24 30 9 35 12 8

Now we create a HANA model, here a Calculation View, on top with the dimensions (characteristics) year and product, and the measures (keyfigures) number of items and amount paid. Then we define a calculated measure in the HANA model item price with the simple formula item price = amount paid / number of items. A simple SELECT * statement on this model would show the following table: Year 2010 2010 2010 2011 2011 2011 Product A B C A B C Number of items 3 5 3 7 4 2 Amount paid 24 30 9 35 12 8 Item price 8 6 3 5 3 4

Then we publish this HANA model to BW or create a Virtual Provider based on this. Then we define a BEx Query what is the average item price per product. As a control number we calculate this average once directly out of the keyfigure item price, but also using a calculated keyfigure defined in the BEx Query Designer amount paid / number of items. The result looks then like this: Product A B C AVG( item price) 6.5 4.5 3.5 AVG(amount paid / number of items) 59/10 = 5.9 42/9 = 4.67 17/5 = 3.4

So you see that the two columns differ which is due to the fact that the sequence of the division in the formula and the aggregation must be processed in the right order. The BEx Query keyfigure

AVG( item price) calculates first the Division per Year and Product, then the Sum over the Years. The BEx query keyfigure AVG(amount paid / number of items) calculates first the Sums over the Years and then does the Division. This is of course a very simple and easy to understand example, but the cases can be much more complex if the calculation in the HANA model contains a Script node or a statistics function and the BEx Query in BW might contain much more complex formulas, exception aggregation, currency and unit handling etc. So as a general recommendation we state, that you should keep the model in HANA as simple as possible and model the calculations instead in the BEx Query. If you require functionality that the BEx Query does not offer or which does no perform well as it is not yet pushed down to the HANA engine at runtime, you can model it in the HANA calculation view, but then should only use simple aggregation BEx Queries on top.

Outlook
The following features are planned for future SPs (please note the usual disclaimer about planned features). Simplified modeling: After modeling the Virtual Provider with all its InfoObjects it will be possible to generate a proposal for the mapping to the fields of the HANA model. Performance improvements: In case all characteristic values booked in the HANA model are already available in the BW Masterdata tables (i.e. referential integrity is assured), an INNER JOIN instead of an OUTER JOIN can be performed at query runtime between HANA model and BW Masterdata. This is in many cases faster. Additionally in such a case, not only the keys, but also the SIDs of BW can be read directly by joining from the HANA model to the SID table of the InfoObject. Then also the hierarchy processing can be pushed down as it relies on the SIDs. To achieve this optimal query runtime behavior, there will be the option to say that the data is referentially integer and thus an INNER JOIN can be performed, when mapping an InfoObject to a field in the HANA model in the Virtual Provider. The default will still be the OUTER JOIN. Composite Provider: It will be possible to include the Virtual Provider based on a HANA model also in a Composite Provider (just as the equivalent Transient Provider). Virtual Masterdata: The Virtual Provider reads transactional data from the HANA model and combines it with the BW Masterdata. But the other way around can be of interest as well, i.e. the transactional data is already available in BW, but the Masterdata comes directly into HANA. For these cases, we will offer the option to have InfoObjects where the Masterdata comes from a HANA model (in this case an Attribute View). These InfoObjects can be used in all BW InfoProviders. It will also be possible to mix these cases, e.g. having a Virtual Provider based on a HANA model with InfoObjects that read their Masterdata from a HANA model.

References
*1+ Whats new with BW7.30 and BWA7.20 SDN article: http://www.sdn.sap.com/irj/sdn/bwa?rid=/library/uuid/70950003-f7ef-2d10-b1bc-ee483800b25c *2+ BW Workspace SDN article series: http://www.sdn.sap.com/irj/sdn/bw73?rid=/webcontent/uuid/707d0dfa-feb9-2e10-d98b-e2612c18e216 [3] How BW-on-HANA Combines With Native HANA SDN blog by Thomas Zurek http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/27139 *4+ SAP Note 1661202 Support of several applications on one HANA https://css.wdf.sap.corp/sap(bD1kZSZjPTAwMQ==)/bc/bsp/spn/sapnotes/index2.htm?numm=00016 61202 [5] Reference for HANA models: http://service.sap.com/hana --> SAP HANA Modeling Guide