Professional Documents
Culture Documents
HANA (High Performance Analytical Appliance) is a product based on New DB that allows the implementation of analytical application that processes a huge amount of data in real time. The Gateway HANA integration exposes HANA content as OData services. For this a generic Minimal Gateway application has been developed on the Gateway Hub, i.e. a local MGW application. The application is a prototype only. Additionally references between other Gateway content and HANA content are possible. Therefore the prototype allows federation between HANA content and Minimal Gateway Content. Gateway retrieves the data from HANA via ABAP Database Connectivity (ADBC). ADBC is an object-based ABAP API for programming relational database accesses, which in its class and model structure follows the JDBC (Java Database Connectivity) diction. For some of the following discussion the different table types in HANA should be known Replicated tables like for example the MM material table MARA Analytic Views are like cube model where Transaction Data is connected to attribute view o o They can have multiple dimensions Data can be sliced and diced (e.g. Grouped by attributes)
Calculation View are based on analytic views enriched with custom functions and calculations o They can be used to define a two dimensional list from a Analytic View
1.1 Prototype
A prototype has been developed in system U3F.
1.1.1 Overview
The HANA integration is based on the SAP Data Channel (Minimal Gateway) for local applications. It is developed on the Gateway hub against interfaces not exposed to stakeholders. The main building blocks are "HANA Model Provider" (Class ZHANA_CL_HANA_MODEL_ADP) "HANA Business Data Provider" (Class ZHANA_CL_HANA_MGW_RUNTIME) HANA Database Connector (Class ZHANA_CL_HANA_DATABASE_READER)
Internal/Confidential
Page 2 of 11
1.1.4.3 Metadata
The metadata (entity description) is derived from the corresponding HANA metadata. More precisely it is read from a query result. A query requesting only one entry from the database is executed and the metadata of the result set is read. This information is merged with the data stored in table ZHANA_DBTAB_NAME and then adapted to the corresponding MGW format.
1.1.4.4 Feeds
To retrieve a feed an ADBC query statement matching the OData request is composed and executed.
1.1.4.5 Entities
To retrieve an entity an ADBC query statement is composed and executed requesting only one entry.
Internal/Confidential
Page 3 of 11
One Service Group One Object Model per HANA database table. The following tables need to be maintained o /IWFND/I_MED_OHD o Defines the model identifier and set active
All models are assigned to the same Service Group. This is done via table o /IWFND/I_MED_SRG Maps models to service groups
While the routing is not done via System Aliases still a GSDO Group is needed to which the Service Group is assigned.
1.2 Conclusions
1.2.1 Limitations / Requirements
The following limitations and requirements have been identified.
1.2.1.1 ADCB
ADCB is the one big question mark for this integration approach. 1.2.1.1.1 Authorization
HANA supports user based authority checks. These authority checks are filters that are merged to an executed query. However this requires user based connectivity between Gateway and HANA. This is currently not available. 1.2.1.1.2 Tools
Connections are created by creating an entry in table DBCON via SE16. 1.2.1.1.3 Scalability
Only a limited fixed numbers (20?) of ADBC connections can be open in parallel from a SAP system. Currently no connection pooling is available.
Internal/Confidential
Page 4 of 11
1.2.1.1.4
The Gateway retrieves the data from HANA via ADBC. HANA currently only supports Linux (and Windows?), but not for example Solaris for ADBC. Hence the Gateway ABAP server needs to be running on Linux (or Windows?). 1.2.1.1.5 Future
(To the author of this document) The future support and development of ADBC is not clear. 1.2.1.1.6 Features needed from BASIS
The limitations listed above need to be overcome o o o o User based authorization Tool for connection setup ADBC scalability Supported operation systems (This is rather a limitation of the new DB database driver than ADBC)
A method to calculate a MGW (OData) compatible name from a String A possibility for an admin to enhance the generically created transient model
A possibility for an admin to enhance the generically created transient model o o Hide certain fields Define a white-list of fields to be exposed. All other fields are not exposed
1.2.1.4 Labels
The metadata retrieved from HANA does not contain label information. It might be possible to read a descriptive XML from a HANA database table which contains label information. But even if that is possible no translation would be available. 1.2.1.4.1 Features needed on Gateway
Internal/Confidential
Page 5 of 11
Two workarounds seem reasonable: The prototype uses database table ZHANA_DBTAB_NAME on the Gateway to store for each model (i.e. each HANA database tables) the fields which shall be exposed as key fields Flag all characteristics as key. o o Attributes (Characteristics) are descriptions of key figures, such as Customer ID, Material Number, Sales Representative ID, Unit of Measure, and Transaction Date. Measures (Key figures) are numeric values or quantities, such as Per Unit Sales Price, Quantity Sold, and Sales Revenue.
To retrieve an entity an ADBC query statement is composed and executed requesting only one entry. If the correct characteristics are supplied this is sufficient.
There is one specific table which contains a metadata XML tables and views. o o No library is available retrieve this metadata. A Gateway application would have to parse this XML itself. It needs to be checked if field labels are available
The ADBC libraries return for every Query result also the corresponding metadata. o o o No field labels are available It needs to be checked if this returns metadata if the query did not find any record This can be fairly slow way when only the metadata is needed
Internal/Confidential
Page 6 of 11
It should be possible to assign Object Models to Service Groups during runtime via APIs. A related requirement for many generic Integration scenarios would be some kind of WhiteList. HANA as well as Enterprise Search or Analytics (BW) will most likely host hundreds of potential data sources. Once these can be loaded into Gateway dynamically some selection / registration mechanism is needed allowing an administrator to expose any of these data sources individually.
1.2.1.10 Composition
The following iPhone application has been built for a Sapphire demo based on the prototype Search for customers (Entity Customer) o Based on a specific customer MGW application
Display for a selected customer a list of the 5 products with the highest revenue (Entity Revenue) o Based on a model of the generic HANA application
Display some detail information for a selected product (Entity Product) o Based on a specific product MGW application
To link the HANA model to the Product Details the generically generated Object Model description needs to be enriched with the association information (define the link). To achieve this a new Model Provider class was needed. This class inherits from the original HANA Model Provider class to access the coding describing the Revenue Entity. Specific coding describes the two other entities. A similar concept was needed for the Business Data Provider. 1.2.1.10.1 Features needed on Gateway It should be possible to assign different models from different sources to one Service Group. It should be possible to define associations (links) between models on a Service Group level, i.e. within one Service Group (and for that Service Group only). It should be checked, if it is needed to allow the definition of associations (links) between models on a model level.
Internal/Confidential
Page 7 of 11
This could be added by the Gateway. o This would need some additional configuration on the Gateway
This can be overcome by defining corresponding simplified Calculation Views on HANA. o This has been done for the prototype.
But this merging of HANA and none HANA data is not trivial and hence rather a task for SAP development. It would need to be checked if and how this could be developed and shipped
Use HANA as provider to particular GW object's properties (HANA can deliver KPI information based on analytical information to a Gateway object) o The idea of the prototype is to only provide a generic framework allowing a customer to easily expose HANA database tables which have o Been shipped with a different life cycle Have been created by the customer
But this merging of HANA and none HANA data is not trivial and hence rather a task for SAP development. It would need to be checked if and how this could be developed and shipped
Use HANA (or more precisely the underlying newDB) may serve as offlining capability for GW caching o Simple two dimensional data (which is all what is needed for any reasonable Gateway caching) can be read from normal SAP database tables with at least similar speed as from a HANA database. HANA has been designed for multi dimensional mass data analysis, which of course is not needed for Gateway caching.
Internal/Confidential
Page 8 of 11
Use HANA ideally also exposes itself via SAPDATA to allow homogenous access to all data sources of SAP and allow a consistent way for GW to access the information accordingly were needed/reasonable o The Prototype and this document are about the question how to expose HANA data via the Gateway. The question what could be done on HANA has not been addressed.
The current analytics functionality is a part of IW_CBS. Consequently the integration of High Performance Analytical Appliance should be assigned to the same layer. This allows us to deliver the integration with a later Gateway content pack as well. (Decision pending)
1.3 Summary
From a design perspective the generic integration of HANA as described in the document is a very good fit for the MGW (OData Channel). The current questions around ADBC are the one major obstacles to develop a Gateway quality product based on the ideas of the prototype Developing a generic tool to retrieve a SQL statement for an OData request would be a major part but can be accomplished fairly easy. The major lesson learned from the prototype for the Gateway is that following aspects should become more flexible or should be double checked: o o o The use of Service Groups (e.g. should this be a repository object?) The definition of Object Models (E.g. it should be possible to create and assign them to Service Groups during runtime) Composition and configuration
Internal/Confidential
Page 9 of 11
1.4 Alternative
There is at least one reasonable alternative architectural approach to integrate HANA. Instead of accessing HANA directly via ADBC rather integrate the Gateway with HANA implicitly by integrating with Analytics. HANA 1.5 will support Analytics. Advantages ADBC will not be used Tool support like for example the Query Designer Analytics shall be integrated into Gateway anyway. So with this one stone 2 birds would be killed.
1.5 Appendix
1.5.1 Links
Hana Input
http://ldai1u3f.wdf.sap.corp:50050/sap/opu/sdata/sap/ZHANA/$metadata?sapclient=100&$format=xml MARA
1.5.1.1.2
1.5.1.1.3
1.5.1.2
Classes in U3F(100)
ZHANA_CL_HANA_MODEL_ADP o Class for BAdI Impl.: ZHANA_BI_HANA_MODEL_ADP o MWG Adapter providing the metadata (Model descriptions) ZHANA_CL_HANA_MGW_RUNTIME o Class for BAdI Impl.: ZHANA_BI_HANA_MGW_RUNTIME o MGW Adapter providing the runtime data(O-Data requests) ZHANA_CL_HANA_DATABASE_READER o Retrieves data and meta-data from HANA database
Internal/Confidential
Page 10 of 11
Internal/Confidential
Page 11 of 11