SAP Datasphere JSON Hack: Umwandlung grafischer Views in SQL Views

Grafische Views und SQL Views sind wesentliche Tools für die Datenmodellierung in SAP Datasphere, die jeweils unterschiedliche Stärken und Schwächen aufweisen. Grafische Views bieten eine visuelle, benutzerfreundliche Oberfläche, die sich ideal für unkomplizierte Datenverarbeitungs-Tasks für technisch nicht versierte Benutzer eignet, während SQL Views eine komplexere Logik und eine verbesserte Leistungsoptimierung unterstützen. Beide Typen haben ihren Platz in einer Datenlandschaft, aber wenn sich die Geschäftsanforderungen ändern, kann es notwendig werden, von einem zum anderen zu wechseln. Ein häufiger Grund für diesen Wechsel sind die Einschränkungen, die mit grafischen Views im Vergleich zu SQL Views einhergehen. Weitere Hintergrundinformationen hierzu finden Sie im Blog "SAP Datasphere: SQL oder grafische Views? Eine fundierte Entscheidung treffen", der einen detaillierten Vergleich der View-Typen in SAP Datasphere bietet.

Zweck des Blogs

In diesem Blog wird eine Methode vorgestellt, mit der grafische Views in SQL Views konvertiert werden können, ohne dass abhängige Objekte durch das Löschen/Bearbeiten und Neuerstellen vorhandener Objekte beeinträchtigt werden. Durch die Nutzung einer Technik, die die Bearbeitung von CSN/JSON-Dateien vorsieht, ermöglicht dieser Ansatz einen reibungslosen Übergang, ohne bestehende Verbindungen zu beschädigen, was ein entscheidender Vorteil für fortgeschrittene Datenprojekte ist. Fast alle Objekte in Datasphere verfügen im Hintergrund über eine CSN/JSON-Datei, die alle erforderlichen Informationen über das Objekt enthält. Diese kann extrahiert, bearbeitet und wieder hochgeladen werden. Beim Bearbeiten eines Objekts in Datasphere wird im Hintergrund im Wesentlichen auch nur die CSN-Datei geändert und dann neu hochgeladen. Durch den Export der CSN-Datei aus Datasphere können Sie diesen Prozess zu Ihrem Vorteil nutzen, indem Sie die JSON-Datei direkt bearbeiten und so Zeit sparen. Ein häufiger Anwendungsfall wird in diesem Blog beschrieben. Ziel ist es, eine schrittweise Anleitung für den Hack zur Umwandlung grafischer Views in SQL Views in SAP Datasphere zu präsentieren, bei der alle abhängigen Objekte stabil und unverändert bleiben.

Szenario

In komplexen Datenmodellen weisen Views oft zahlreiche Abhängigkeiten auf, was es schwierig macht, sie zu löschen und neu zu erstellen, ohne verknüpfte Objekte zu stören, insbesondere in einer späten Entwicklungsphase, in der viele Objekte über Assoziationen oder Joins miteinander verbunden sind.

Problem: Stellen Sie sich einen ausgereiften Datasphere Space vor, in dem eine grafische View mit mehreren abhängigen Objekten und Layern verknüpft ist. Das direkte Löschen dieser View, um sie als SQL View neu zu erstellen, könnte zu Dutzenden von unterbrochenen Abhängigkeiten führen, was der Grund dafür ist, dass Datasphere das Löschen nicht zulässt. Wenn Sie dies tun könnten, würde dies sowohl zu Datenverlust als auch zu einem langwierigen Neukonfigurationsprozess führen.

Standardlösung: Eine Lösung wäre hier die Verwendung eines Zwischenobjekts, das als temporärer Platzhalter für die grafische View dienen kann. Dazu können Sie eine Vorschau des SQL Codes der grafischen View anzeigen und daraus eine neue SQL Version mit einem neuen eindeutigen Namen (z. B. „Products_2“) erstellen.

Sobald die SQL View fertig ist, können Sie die ursprüngliche View aufgrund ihrer Abhängigkeiten nicht sofort löschen, um sie zu ersetzen. Sie müssten jede Referenz des ursprünglichen Views durch die neue SQL Version in allen abhängigen Objekten ersetzen. Danach können Sie den ursprünglichen grafischen View löschen und dann eine neue Version davon mit dem ursprünglichen Namen („Products“) und der gewünschten SQL Form neu erstellen. Schließlich würden Sie wieder alle Vorkommen der temporären Tabelle durch den neu erstellten View ersetzen.

Wenn Ihr View jedoch in vielen Objekten verwendet wird, kann dieser Ansatz sehr zeitaufwendig sein.

Hack-Lösung

Die folgenden Schritte beschreiben, wie Sie die vorhandene grafische View durch eine SQL Version ersetzen können, ohne dass dies Auswirkungen auf andere Objekte hat.

Schritt 1
In Datasphere können Sie die CSN-Datei eines Views exportieren. Der erste Schritt besteht also darin, die CSN-Datei eines Views lokal zu exportieren, indem Sie in der zu konvertierenden Ansicht auf „Export to CSN/JSON File“ klicken. Diese Datei enthält alle Konfigurationen und Logik im JSON-Format

Schritt 2
Sobald Sie die JSON-Datei lokal gespeichert haben, öffnen Sie sie und suchen Sie den Abschnitt am Ende mit dem Namen „editorSettings“. Sie müssen lediglich den Teil entfernen, der sich auf Ihre spezifische View bezieht. In diesem Beispiel entfernen Sie die Zeilen 731–737. Diese Codezeilen fehlen in einer SQL View.

Speichern Sie dann diese geänderte Datei unter einem neuen Namen (z. B. „Products_2“), damit die ursprüngliche CSN-Datei unverändert bleibt, falls Sie sie später doch noch benötigen.

Hinweis/Warnungen: Der Abschnitt „editorSettings“ enthält die grafische Konfiguration für alle anderen grafischen Views, die mit Ihrem Objekt im selben SPACE verknüpft sind. Löschen Sie nur die für Ihr Objekt spezifischen Zeilen (in diesem Beispiel „PRODUCTS“) und lassen Sie den Rest intakt. Wenn Sie den gesamten Block löschen, wird die grafische Funktionalität aller zugehörigen Objekte entfernt.

Finden Sie heraus welches Produkt sich am besten für Ihre Data-Warehousing-Strategie eignet!

Schritt 3
Jetzt müssen wir die neu bearbeitete Datei wieder in Datasphere importieren.

Wählen Sie in Data Builder „Objekte aus CSN-/JSON-Datei importieren“ und wählen Sie die Datei aus, die Sie hochladen möchten.

Wählen Sie in der Liste der Objekte nur das gewünschte Objekt aus (in diesem Fall „PRODUKTE“) und klicken Sie auf „CSN-Datei importieren“.

Hinweise/Warnungen: Nachdem Sie auf „CSN-Datei importieren“ geklickt haben, werden Sie möglicherweise gefragt, ob Sie abhängige Objekte aktualisieren möchten. Wählen Sie je nach Bedarf „Ja“ oder „Nein“. Wahrscheinlich möchten Sie „Nein“ drücken, da Sie normalerweise nicht in andere Objekte als das zuvor bearbeitete eingreifen möchten.

Letzter Schritt

Innerhalb weniger Sekunden sollten Sie eine Benachrichtigung erhalten, dass der Import der JSON-Datei abgeschlossen ist. Sie können nun Ihre View öffnen und im SQL Format begutachten, bevor sie die Änderungen implementieren („deployen“).

Vergewissern Sie sich, dass das Ergebnis Ihren Erwartungen entspricht. Wenn nicht, können Sie denselben Importvorgang (Schritt 3) verwenden, um die Originaldatei zu reimportieren, damit das Objekt in seinen ursprünglichen Zustand zurückversetzen und den Vorgang von vorne beginnen.

Einschränkungen

Wenn man sich die JSON-Datei einer grafischen View ansieht, wird schnell klar, dass ein Wechsel von SQL zu einer grafischen View nahezu unmöglich ist, da der in Schritt 2 gelöschte Code manuell erstellt werden müsste.

Alternative CSN-Funktionen

In Szenarien, die dem oben genannten ähneln, kann diese Funktion auf jedes Datasphere-Objekt mit einer anderen kompatiblen Struktur angewendet werden. Sie können beispielsweise eine Tabelle durch eine andere Tabelle mit zusätzlichen Spalten ersetzen.

Die Verwendung dieser CSN-Technik erfordert sorgfältige Vorgehensweise, kann aber potenziell viel Zeit und Aufwand sparen.

Dieser Hack kann zwar sehr zeiteffizient sein, birgt aber auch erhebliche Risiken. Ohne sorgfältige Aufmerksamkeit können Benutzer versehentlich hunderte von Objekten auf einmal manipulieren und ändern, was möglicherweise zu unbeabsichtigten Inkonsistenzen im gesamten Projekt führt. Wir empfehlen, diesen Ansatz nur zu verwenden, wenn eine Ausfallsicherung vorhanden ist und die damit verbundenen Risiken vollständig bekannt sind.