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 und 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, die wiederum ihre Daten in ein Data Warehouse weiter­gibt. 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. Zudem musste sicher­ge­stellt werden, das 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:

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.

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.

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.

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.

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.

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

Share on linkedin
Share on xing
Share on facebook
Share on twitter
Share on whatsapp
Share on email

Weitere spannende Themen aus unserem Newsroom

Rückblick zum StammdatenForum in Düsseldorf

Erfahren Sie welche Entwicklungen zum Thema Stammdaten, Data Governance und...

Mehr lesen

Datenqualität in einer Datenmigra­tion sicherstellen

Migra­tionen werdem vom Thema Daten­qualität begleitet. Dabei ist die Proble­matik...

Mehr lesen

Q-THOR auf dem Stamm­daten Forum in Düsseldorf​

Q-THOR ist als Standard-Software für Datenqualitätssicherung Sponsor des Stammdaten Forums...

Mehr lesen