Live-Re­porting auf SAP HANA für unter­schied­liche Reporting Tools er­mög­lichen

Unser Kunde aus dem Finanz­bereich wollte den Ad Hoc Berichts­an­forder­ungen der Fach­bereiche gerecht werden. Ziel war es, neben dem eta­blierten Standard­reporting flexible Möglich­keiten für schnelle Analysen schaffen.

Das Setting

Der Kunde hatte mehrere Zu­liefer­systeme an eine SAP HANA an­ge­schlossen. Diese wiederum gibt ihre Daten in ein Data Warehouse weiter. Aufgrund der Speicher­größe (6TB), der an­ge­bun­denen daten­liefernden Systeme und der Per­formance sollte die SAP HANA als Reporting Platform für diese Analysen ver­wendet werden.

© 2021. BIG.Cube GmbH. Alle Rechte vorbehalten.

Heraus­forderung

Die An­forderung seitens des Kunden war die Imple­men­tierung einer ge­nerischen Schnitt­stelle dieser Reporting Platform, die von mehreren Tools ver­wendet werden konnte. Zusätzlich sollten über diese Schnitt­stelle nur die Objekte sichtbar sein, die für die zu­greifende Person frei­gegeben waren.

Da viele Systeme an die Reporting Platform als Daten­zulieferer an­ge­schlossen waren, sollte die Schnitt­stelle auch für große Daten­mengen und viele Abfragen opti­miert werden. Und das unter optimaler Aus­nutzung der Performance der HANA. Zuletzt musste sicher­ge­stellt werden, dass der Betrieb anderer, paralleler Anwendungen auf der HANA nicht be­ein­flusst wurde.

Lösung

Von der An­bindung mit SAP SDI bis hin zu einer UI5 App, um den Status zu über­blicken, haben wir eine ganz­heitliche Lösung konzi­piert und imple­men­tiert. Erfahren Sie in den fol­genden Schritten, wie die An­forder­ungen an die SAP HANA Reporting Platform von uns um­gesetzt wurden:
1. Wahl der Zugriffs­art
Die schnellste Art des Zu­griffs er­folgte über JDBC/ODBC Zu­griffe. Da der Kunde die SAP HANA bereits als Um­gebung für native HANA Ent­wicklung nutzte und so bereits ein User­management für die HANA imple­men­tiert hatte, wurde dieser Ansatz gewählt. Die beim Kunden ein­ge­setzten Frontend­tools unter­stützten alle diese Lösung.
2. Datenban­kuser – Wer verw­al­tet die Rollen?
Normaler­weise ist in solchen Fällen zu­sätzlich ein ABAP System mit installiert. Hier jedoch handelte es sich um ein rein HANA Nativ gen­utztes System, welches bereits an die User Inter­face Schnitt­stelle des Unter­nehmens ange­schlossen war. Zudem lief auf der Daten­bank eine HANA Native An­wendung. Daher war sowohl das Wissen als auch die Technik bereits vor­handen.
3. Daten­räume schaffen

Mit Privi­legien auf unter­schiedliche Daten­gruppen wurde der Daten­raum je Nutzer­gruppe aufge­teilt und zu­gänglich gemacht. Dabei wurden sowohl all­gemeine Rechte auf Tabellen als auch ana­lytische Privilegien zur Redu­zierung der bereit­gestellten Daten auf Zeilen­ebene vergeben.

4. Calculation Views-Per­formance Boost
Um die Daten aus den Zu­liefer­systemen mit denen aus der HANA Nativen App zu ver­binden, wurden  Calculation Views benutzt. Zudem wurde auch dort für die Zugriff­steuerung mit Analytischen Privilegien ge­arbeitet. Eine weitere Nutzung der Calculation Views war der Aufbau von immer wieder ver­wendeten Daten­räumen, die für Ab­fragen benutzt wurden. Durch die Calculation Views und deren Input Parameter, konnte die Be­rechnung des Er­gebnisses auf der HANA durch­ge­führt werden und musste nicht durch die Front­end­tools erfolgen. So konnte eine deutliche Performance­steigerung bei der Berichts­aktualisierung er­zielt werden.
5. Ver­schiedene Fron­tend Tools
Von den unter­schied­lichen Fach­bereichen und den ver­wendeten Tools konnte unsere Schnitt­stelle gleicher­maßen ver­wendet werden. Zum Bei­spiel Microsofts Power BI, R mit Shiny Apps sowie alle anderen Tools mit ODBC/JDBC Verbindungs­möglich­keit.
6. HANA Work­load Mana­ge­ment

Die Größe der Re­porting HANA mit 6TB reinem InMemory Speicher plus die zu­sätzlichen Cold Storages mit 4TB haben es er­möglicht, in der Pilot­phase auf größere Ein­griffe in das Work­load­mana­gement zu ver­zichten. Trotzdem sind Limits bei der Ab­frage­größe (hier 256GB) ges­etzt worden. Das System wird laufend über­wacht. Sollte eine steigende Aus­lastung fest­gestellt werden, werden die Workload Klassen aktiviert und somit auch die System­stabilität weiter­hin sicher­ge­stellt.

Alle Bilder auf dieser Seite © 2021. BIG.Cube GmbH. Alle Rechte vorbehalten.

Fazit

Durch unseren ge­nerischen Ansatz konnten alle Tools über die gleiche Schnitt­stelle Daten be­ziehen. Mit dem Aufbau der durch Calculation Views vor­be­rei­teten Daten­räume konnten über 90 Prozent der An­fragen schnell mit optimaler Aus­nutzung der HANA ver­ar­beitet werden. Zudem wurde durch die Verfüg­barkeit des kompletten Daten­haushalts höchste Flexi­bilität für mögliche Ab­fragen ge­schaffen – ohne dass
die IT unter­stützend tätig werden musste.

Verfasst von Daniel Fröhler

Beitrag teilen

Weitere spannende Themen aus unserem Newsroom

Wir gehören zu „Deutschlands besten Arbeitgebern“

Als einer der Top-100-Arbeitgeber Deutschlands mit erneuter „Great Place to...

Mehr lesen

Unser Herzensprojekt: Die Stiftung AKM in München

Schon seit einiger Zeit unterstützten wir als BIG.Cube GmbH die...

Mehr lesen

BIG.Cube ist ein Great Place to Work – Bayern und ITK

Die BIG.Cube wurde dieses Jahr von Great Place to Work...

Mehr lesen