Daten­zu­liefer­ungen stan­dar­di­sie­ren, auf­bereiten und qualitäts­sichern

Unser Kunde aus dem Finanz­­bereich wollte Daten­­zu­lieferun­gen in sein Data Ware­house stan­dardi­sieren und sie in einem zwischen­geschalteten HANA Sys­tem auf­­bereiten und qualitäts­­sichern. Ziel war es alles für ein Near­time Repor­ting im Data Ware­house und Ad Hoc Re­porting­möglich­keiten für die Fach­be­reiche in der HANA DB vor­zube­reiten.

Hier zeigen wir einen Ausschnitt aus der Gesamtarchitektur, die im Rahmen vieler weiterer Projekte umgesetzt worden ist. Im Folgen­den lesen Sie, wie wir aus einem Oracle System ca. 700 Ta­bellen mit einer Quell Grö­ße von ca. 2TB in nahezu Echtzeit angebunden haben und welchen Herausforderungen wir uns hierbei stellen mussten. Zum Zeit­punkt dieses Aus­schnit­tes war bereits ein MSSQL System über Log-basierte Smart Data Integration (SDI) Replikation in die Archi­tek­tur ein­gebaut worden.

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

Herausforderungen: Beladung regulieren – Veränderungen erkennen

Der Zugriff durfte nur auf den Standby Knoten des Oracle Systems statt­finden, um den Haupt­knoten nicht zu belasten. Dieser Standby Knoten war nur Read Only geöffnet. Die SDI Standard­möglich­keiten für Realtime erfordern einen Schreib­zugriff auf dem Quell­system. Für die Datenanbindung musste eine Möglichkeit im SAP Kontext gefunden werden, die trotz Read Only Mode des Sekundärknotens eine schnelle Verbindung sicherstellt. Zudem musste für das Folgesystem ersichtlich sein, welche Daten sich durch die Beladung geändert haben.

Lösung - Smart Delta!

Von der Anbindung mittels SAP SDI bis hin zu einer UI5 App zum Monitoring des Status. Wir haben eine ganzheitliche Lösung entwickelt. Erfahren Sie in den folgenden Schritten, wie die Heraus­forderungen gelöst wurden.

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.

 

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

Wiederverwendbarkeit

Bei unseren Lösun­gen achten wir stets auf eine hohe Wieder­verwend­barkeit bei unseren Kunden. Hier war archi­tekto­nisch SAP SDI bereits ge­setzt und für alle geplan­ten Szena­rien ein­setz­bar. Bei der Ent­wicklung wurde be­reits auf die Kompatibili­tät HANA 1 zu HANA 2 geachtet sowie der mög­liche XSA Ein­satz vor­bereitet. Mittels SAP SDI wurden MSSQL, Oracle, S4/HANA sowie BW on HANA Systeme an die HANA Zwischen­schicht an­geschlossen. Zudem wurde neben dem Delta­ver­fahren der SAP Standard für Realtime Connection ver­wendet. Dieser Standard ist ebenfalls über das Tools steuer­bar.

Fazit

Mit unserer Smart Delta Lösung war es uns in wenigen Schritten mög­lich, die Daten­­zu­lieferun­gen unseres Kunden in sein Data Ware­­house zu standar­di­sieren. Dazu konnten wir die Da­ten in einem zwischen­­ge­schalte­ten HANA System auf­­bereiten und quali­täts­­sichern – und das in Neartime.

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

Case Study: SAP HANA als Reporting Platform

Erfahren Sie, wie mit SAP HANA als Reporting Platform Ad...

Mehr lesen