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.

Für die An­bindung wurde mit SAP SDI eine SAP eigene in die HANA inte­grier­te Lö­sung zur Daten­­anbin­dung gewählt, die bereits für die An­­bin­dung eines MSSQL Systems ver­wendet wurde. Da­durch konnte die Lade­tech­no­lo­gie verein­heit­licht und Betriebs­­auf­wände gespart werden.

Um die Date­nmen­ge, welche über­­tra­gen wird zu re­duzie­ren und die Geschwin­dig­­keit zu erhöhen, wurde das Delta­feld im Quell­­system bestimmt und basie­rend darauf eine Delta­­logik implemen­tiert. Diese lädt ledig­lich die ge­­änder­ten Daten seit der letzten Extrak­­tion. Um die Be­las­tung des Agen­ten und der HANA zu steuern, wurden die Tabellen mittels T-Shirt Sizes in Klassen von S bis XL ein­­geteilt. Durch Ein­­stellun­gen der maxi­mal parallel lau­fenden Größen kann je nach verfügbarer Hard­ware die Aus­­las­tung des Systems und die Geschwin­dig­­keit der Daten­­aktuali­sierung ge­steuert werden. Ebenfalls ein­stell­­bar ist die erwartete Fre­­quenz von Delta und Delete Ab­holung. Auch hier kann ab­hän­gig von der Infra­s­truk­tur die Per­for­mance opti­miert werden.

Für die Be­la­dung wurden SDI Flow­graphen verwendet, die optimal für die Filte­rung der Da­ten und teilweise kompli­zierte Delta­ermitt­lung geeignet sind. Die letzte Beladun­g wurde als Input in den Flowgraphen über­­geben, der dann die Ergebnisse in die HANA ge­laden hat. Die Ergeb­nisse wurden um ein Änderung­s­datum an­ge­reichert, welches das darauf auf­­bauende Data Warehouse weiter ver­­wenden kann.

Um die Betriebs­­aufwände und die Auf­­wände für neu an­zubindende Tabe­llen zu re­du­zie­ren, wurde eine SAP UI5 App ent­wickelt. Die­se legt auto­­matisiert die Flow­graphen an und er­stellt dazu­gehörige .hdbviews sowie Calcu­lation Views bzw. passt diese an. So sind die Auf­­wände bei Änderun­gen der Da­ten­­struktur minimal. Zudem hat sich der Auf­wand im Betrieb für die Er­­stellung und Wartung der Flow­graphen, Tabellen und Calcu­lation Views deutlich reduziert.

Damit auch der Über­blick über den Sta­tus der Daten­­anbin­dung jeder­zeit gewähr­­leistet ist, wurde hier ebenfalls eine UI5 App er­stellt. Diese ist zusätzlich noch an eine auto­ma­tische Ticket­­erstellung in Azure DevOps sowie an einen Mail­versand an­­geschlossen. Gerade durch den Switch des Kunden von HANA 1 auf HANA 2 mit Ver­bleib auf XS Classic Objek­ten und dem Weg­­fall des klassischen Admin Cockpits war ein Über­blick über die Rep­­lika­tion drin­gend nötig. In das Cockpit wurden aber auch weitere Funk­t­ionen inte­griert wie z.B. die T-Shirt Size der Tabellen ändern, die Tabellen Prio­ri­täten fest­legen, Tabellen­­gruppen­­defini­tion oder schneller Zugriff auf eventuelle Fehler­­meldun­gen.