SAPDie SAP SE mit Sitz im baden-württembergischen Walldorf ist ein… Datasphere bietet eine sehr leicht nutzbare Oberfläche zur Entwicklung von Datenmodellen. Gerade bei Einführungsprojekten mit einer sehr hohen Anzahl von Datenmodellen, gerät die Oberfläche aber schnell an Ihre Grenzen, weil der Entwicklungsprozess viel Zeit erfordert.
Über das Command Line Interface (CLI) von SAP Datasphere, gibt es einen alternativen Weg Spaces inkl. Datenmodellen zu konfigurieren. Wir zeigen anhand des Beispiels unseres Automation Frameworks, welche Chancen sich durch das CLI ergeben und automatisieren Teile der Datenmodellierung in SAP Datasphere.
Problemstellung
SAP Data WarehouseEin Data Warehouse ist für die Ausführung, Überwachung und Steuerung… soll eingeführt werden. Zu Beginn sollen Tabellen aus den Quellsystemen in zentralen Ingest Spaces je Quellsystem bereitgestellt werden. Natürlich lassen sich notwendige Remote Tables etc. manuell entwickeln. Mit steigender Anzahl an Tabellen, entsteht ein zunehmend hoher Aufwand für die manuellen repetitiven Arbeiten. Hinzu kommt die Anforderung, dass Veränderungen in den Strukturen der Quelltabellen in Datasphere ebenfalls übernommen werden sollen. Dies kann durch Entwicklungsprozesse und manuelle Tätigkeiten erledigt werden.
Allerdings wäre der Prozess zur Erstellung aller notwendigen Spaces inkl. Remote Tables je nach Anzahl sehr langwierig. Fachbereiche müssen länger auf Ergebnisse warten und können später einen Nutzen aus Datasphere ziehen. Daher stellt sich die Frage, ob es nicht einen besseren Weg gibt als wiederkehrende Aufgaben manuell durchzuführen.
Exkurs Command Line Interface (CLI)
Die Oberflächen von SAP Datasphere sind leicht und intuitiv bedienbar. Dies ist sehr gut für kleinere Arbeitspakete sowie insb. das Business. Andererseits wäre es optimal, wenn Datasphere noch einen alternativen programmatischen Ansatz bieten würde Entwicklungen in Datasphere durchzuführen.
Hier setzt das Command Line Interface (CLI) an. Das CLI ist ein eigenständiges Node.js-Modul und auf npmjs.com verfügbar. Das CLI erlaubt den Zugriff auf Datasphere Tenants per Kommandozeile. „Massenarbeiten“ oder wiederkehrende Aufgaben, die manuell viel Arbeit erfordern lassen sich so beschleunigen. Beispiele sind etwa
- Lesen der Space Definition (Tabellen, Mitglieder, etc.)
- Erstellung von Spaces, Tabellen, Views, etc.
- Zuordnung von Nutzern zu Spaces
Ausführlich hat Jascha Kanngiesser die Möglichkeiten auch hier beschrieben. Als Format wird JSON genutzt, d.h. die Definitionen liegen in diesem Format vor. Nachfolgend stellen wir ein paar Beispiele für Anwendungsfälle vor:
Integration in Git
In SAP Datasphere gibt es aktuell keine Versionsverwaltung von Entwicklungsobjekten, wie Entwickler sie aus der Softwareentwicklung kennen wie bspw. bei Verwendung von GitGit stellt ein Softwarerepository da, welches in der Softwareentwicklung einen…. Über das CLI kann die Definition von Spaces exportiert werden in eine JSON Datei. Werden die JSON Dateien in Git abgelegt, erhält man eine bewährte Versionsverwaltung. Eine Automation der Versionierung (Export JSON und Import Git) ist denkbar durch Dritt-Lösungen (z.B. ISR Automation Framework), aber nicht out-of-the-box vorhanden. Eine Git Integration in der Oberfläche von Datasphere ist derzeit nicht dagegen absehbar.
Entwickler-Spaces / One Tenant Strategie
Aufbauend auf einer funktionierenden Git Integration gilt das vorliegende Szenario. Aktuell wird in Datasphere nichts gesperrt, wenn ein Entwickler bspw. eine View bearbeitet. Dies bedeutet, dass ein zweiter Entwickler gleichzeitig die gleiche View bearbeiten kann. Dies bringt einige Einschränkungen mit sich bzw. erfordert klare Entwicklungsprozesse.
Interessant wäre das nachfolgende Szenario:
Entwickler ziehen sich die Definition des produktiven Space (JSON) aus Git und es wird unter einem anderen Namen (z.B. DEV1_<SPACE_NAME>) ein Space erzeugt zur Entwicklung. Die Entwicklung wird durchgeführt und abgenommen. Anschließend wird ein Merge in Git durchgeführt mit möglichen anderen Entwicklungen eines Releases. Die abgestimmte Space Definition wird anschließend per CLI eingespielt in dem produktiven Space. Einige Schritte müssten hierbei automatisiert werden, um effizient zu arbeiten (z.B. Namensänderung Entwickler-Space, Erzeugung Entwickler-Space, etc.).
Man kann eine „One Tenant“ Strategie verfolgen oder auch mit mehreren Tenants arbeiten. Das Szenario finden wir sehr spannend, weil dadurch auch große Entwickler-Teams parallel arbeiten können und es nicht im Chaos endet.
Leider scheitert das Szenario aktuell daran, dass der Merge der JSON Dateien nicht möglich ist. Daher zeigt das beschriebene Vorgehen lediglich das Potential der Lösung. Es ist interessant, ob der Merge künftig möglich sein wird. Dann lassen sich auch größere Entwicklungsteams gut koordinieren.
Alternatives Transportwesen
Das Transportwesen in SAP Datasphere ist sehr einfach bedienbar. Zu beachten bei den Namenskonventionen ist, dass die technischen Namen auf dem Quell- und Ziel-Tenant identisch sein müssen. Dies bedeutet, die Connections und Spaces müssen den gleichen Namen haben wie auf der Produktion. Ein Renaming oder Mapping gibt es nicht. Häufig gibt es die Anforderung in den Connections Systemkürzel als Namen zu benutzen genauso wie bei Ingest Spaces. Nun könnte es verwirrend sein, dass auf dem Dev / QA Tenant Connections und Space Namen mit produktiven Systemkürzeln existieren.
Mit dem CLI lässt sich ein „Renaming“ realisieren. Auf dem Dev/QA Tenant wird die Definition per CLI exportiert. In den JSON Datei(en) müssen die Objekte entsprechend umbenannt werden und anschließend in der produktiven Datasphere importiert werden per CLI. Dies ist sicherlich ein sehr einfaches Beispiel, zeigt aber das man über die CLI eine hohe Flexibilität erhält für komplexere Szenarien.
Generell sollte auch in diesem Szenario eine Automatisierung vorgesehen werden für den Prozess, um manuelle Aufwände aber auch Fehler zu vermeiden. Gleichzeitig ist denkbar, dass man das Deployment in einen CIContinuous Integration, bedeutet die kontinuierliche Zusammenführung von einzelnen Entwicklungsständen (Feature…/CD Prozess integriert um derartige Anpassungen und das Deployment selber automatisiert durchführt.
Automation der Modellierung und Quality Checks
Kommen wir zurück zu der Problemstellung, bei der eine Masse von Objekten in Datasphere angelegt werden müssen. Wenig überraschend sehen wir dies auch als sehr guten Anwendungsfall für das CLI. Was lediglich benötigt wird, sind die passenden JSON Dateien für den Import in Datasphere. Untenstehend ist ein Auszug einer solchen JSON Datei aufgezeigt.
Die manuelle Erstellung einer JSON Datei inkl. Namen der Tabellen etc. beschleunigt erstmal nichts. Insb. wenn weitere Views erstellt werden sollen, die auf den Remote tables basieren und alle Columns definiert werden sollen. Sinnvoll wird das erst, wenn die Erstellung der JSON Dateien und möglichst auch Einspielung in Datasphere automatisiert wird. Die Automation des Prozesses kann durch das ISR Automation Framework erfolgen.
Das Automation Framework ist eine node.js Applikation, welche lokal oder auf einer virtuellen Umgebung läuft. Die Erstellung der Datenmodelle in SAP Datasphere lassen sich durch das Framework und dem CLI in wenigen Minuten durchführen. Neben der initialen Anlage kann ebenfalls ein automatischer regelmäßiger Abgleich von Quell- und Zielstrukturen implementiert werden.
Nachfolgend skizzieren wir, wie das Framework zusammen mit SAP Datasphere zusammenarbeitet und die Datenmodelle in SAP Datasphere generiert:
1) Admin Space
Fachlich wird in einer Excel Datei definiert, welche Quelltabellen aus welchem System benötigt werden. Diese Datei wird als Kontrolltabelle(n) gespeichert in einem dedizierten Space. In den Kontrolltabllen steht, welche Remote tables / Views in welchen Spaces in SAP Datasphere angelegt werden sollen.
2) Anforderung ermitteln
Die Kontrolltabellen stellen die Anforderung für das Automation Framework dar. Per openSQL Zugriff auf den Admin Space wird abgefragt, welche Objekte in SAP Datasphere erzeugt werden sollen.
3) Metadaten ermitteln
Das Framework ist ebenfalls verbunden mit den Quellsystemen. Dadurch ist es möglich, dass die Metadaten der Quelltabellen abgefragt werden können. Bspw. wird so auch validiert, dass es eine Tabelle überhaupt gibt aber auch welche Spalten enthalten sind.
4) Erstellung von JSON-Datei für das Command Line Interface
Mit Hilfe der bisherigen Schritte können automatisch die notwendigen JSON-Dateien generiert werden. Dazu läuft ein Script durch, welches die notwendige Syntax der JSON Datei von Datasphere kennt und das JSON erzeugt.
5) Erzeugung von Datenmodellen in SAP Datasphere
Schließlich wird die JSON Datei über das Command Line Interface in SAP Datasphere eingespielt und alle Objekte werden erzeugt. Auch Abhängigkeiten zwischen Spaces lassen sich erzeugen, wenn bspw. Views in einem Consumption Space auf die Remote Tables in Ingest Spaces zeigen sollen.
Untenstehend ist ein Screenshot aus der Oberfläche zu sehen, in der die notwendigen Informationen gespeichert werden.
Automatische Prozesse sollten ungeachtet dessen überwacht werden. Über das CLI kann die Space Definition nach dem Import in Datasphere abgefragt und mit dem erwarteten Ergebnis abgeglichen werden (siehe Screenshot unten). Im Falle von Replikationen lassen sich die Qualitätsprüfungen ausweiten auf einen Vergleich der Quell mit der Zieltabelle und ähnliche Tests.
Haben wir Ihr Interesse geweckt? Lesen Sie auch unseren Referenzbericht zu einem großen Datasphere Projekt bei dem über die Automation der Modellierung eine erhebliche Beschleunigung erreicht werden konnte.
Fazit
Das Command Line Interface bietet ein hohes Potential für komplexe Szenarien und Automatisierung von Tätigkeiten. Es ist spannend, wie sich die Funktionsvielfalt des Command Line Interface entwickelt wird. Viele Szenarien zur Automatisierung und Abbildung komplexer Szenarien lassen sich so angehen. Das Beispiel des ISR Automation Frameworks zeigt anschaulich, das durch die Nutzung des CLI hohe Einsparpotentiale möglich sind etwa bei:
- Generierung von Spaces
- Generierung von Datenmodellen
- Generierung von Usern
- Abgleich der Quellsysteme mit den Datenmodellen der Datasphere
- Durchführung von Qualitätsprüfungen
Wir hoffen, wir konnten mit unserem Beitrag einen guten Überblick geben zu den Potentialen des Command Line Interfaces.
Christopher Kampmann
Senior Manager
SAP Information Management
christopher.kampmann@isr.de
+49 (0) 151 422 05 448
