Case Study: SAP HANA as a Re­porting Plat­form

The fastest way of access was via JDBC/ODBC accesses. Since the client was already using SAP HANA as an environment for native HANA development and had thus already implemented user management for HANA, this approach was chosen. The front-end tools used by the client all supported this solution.

Normally, an ABAP system is also installed in such cases. Here, however, it was a purely HANA native system that was already connected to the company’s user interface. A HANA native application was also running on the database. Therefore, both the knowledge and the technology were already in place.

With privileges to different data groups, the data room was divided and made accessible per user group. Both general rights to tables and analytical privileges to reduce the data provided to row level were assigned.

Calculation Views were used to connect the data from the supplier systems with that from the HANA native app. Analytical privileges were also used there for access control.
Another use of the Calculation Views was to build recurrent data spaces that were used for queries. Through the Calculation Views and their input parameters, the calculation of the result could be done on HANA and did not have to be done through the front-end tools. This led to a significant increase in the performance of report updates.

Our interface could be used equally by the different departments and the tools used. For example, Microsoft’s Power BI, R with Shiny Apps and all other tools with ODBC/JDBC connectivity.

The size of the reporting HANA with 6TB of pure InMemory storage, plus the additional cold storages with 4TB, made it possible to forego major interventions in workload management during the pilot phase. Nevertheless, limits have been set for the query size (here 256GB). The system is continuously monitored. If an increasing workload is detected, the workload classes are activated and thus system stability continues to be ensured.