Wer schon einmal ein SAP BW-Migrationsprojekt begleitet hat, weiß: Je größer und komplexer das System, desto wichtiger ist es, effizient und möglichst standardisiert vorzugehen. Die Migration von SAP BW nach SAP Datasphere stellt Unternehmen außerdem noch vor die Herausforderung, von Ihrer gewohnten On-Premise-Lösung in eine Public-Cloud-Umgebung zu wechseln. Dieser Transformationsprozess erfordert nicht nur eine sorgfältige Planung, sondern auch ein klares Zielbild, wie man die Vorteile der neuen Cloud-Technologie optimal nutzen und gleichzeitig bewährte Geschäftslogiken bewahren kann.
Für letzteren Aspekt bietet sich die SAP BW Bridge an – sie fungiert als Bindeglied zwischen den Systemen und ermöglicht die Migration bestehender Modelle und Geschäftslogiken. In diesem gemeinsamen Blogbeitrag von NextLytics und bluetelligence soll es anhand eines Praxisbeispiels aus einem Projekt darum gehen, wie dieser Ansatz erfolgsversprechend durchgeführt werden kann. Denn: Die Bridge zu nutzen bedeutet natürlich, teilweise auf Vorteile zu verzichten, die ein Greenfieldansatz in Datasphere verspricht. Dem gegenüber bietet sie als „schnellere“ Migrationsoption“ jedoch viele Vorteile, die es abzuwägen lohnt. Für den Einsatz der BW Bridge sprechen insbesondere folgende Gründe:
In unserem folgenden realen Projektbeispiel trafen all diese Faktoren zu. Es handelte sich um ein umfangreiches, historisch gewachsenes BW-System eines Energieversorgers mit hochspezialisierten Modellen, die den Besonderheiten des komplexen und stark regulierten Energiemarktes Rechnung tragen. Das Projektziel bestand darin, die bestehenden Modelle, Business-Logiken und Datenflüsse zu erhalten und lediglich den Reporting-Layer in SAP Datasphere neu abzubilden. In diesem Kontext erwies sich auch der Einsatz der Performer Suite von bluetelligence als entscheidender Erfolgsfaktor für eine effiziente und zielgerichtete Migration.
Bevor wir das detaillierte Zielbild des Projektes vorstellen, ist es wichtig, eine Besonderheit der BW Bridge in Verbindung mit SAP Datasphere zu erläutern. Obwohl Queries bei der Migration in die BW Bridge übertragen werden können, können sie nicht wie im klassischen BW-System ausgeführt oder als Quelle für andere Datenziele verwendet werden. Stattdessen werden Queries in der BW Bridge als Metadaten bereitgestellt. Das bedeutet, sie können importiert und als Grundlage für den Entity-Import in SAP Datasphere genutzt werden. Diese Eigenschaft spielt eine zentrale Rolle in unserer Vorgehensweise.
Das folgende Schaubild veranschaulicht das Zielbild des Projekts:
Im Rahmen des Projektes wurden mehrere zentrale Schritte definiert, die für die Migration von SAP BW nach SAP Datasphere entscheidend waren.
1. Toolgestützte Übertragung via Shell Conversion:Durch den gezielten Einsatz des Entity-Imports konnten wir einen Großteil der erforderlichen Objekte automatisch generieren lassen und damit den Zeitaufwand für die Modellierung in Datasphere erheblich reduzieren.
Die Darstellung in dem Schaubild ist bewusst vereinfacht und fokussiert sich auf die Kernaspekte der Migration. Das vollständige Konzept umfasst zusätzliche wichtige Komponenten:
Für detaillierte Informationen können Sie sich gerne unseren Beitrag zur Referenzarchitektur SAP Datasphere ansehen: Datasphere Referenzarchitektur - Überblick & Ausblick
Master-Query-Analyse
Eine der zentralen Herausforderungen des Projekts bestand also darin, die Kennzahl-Definitionen als Vorlage für die Master-Queries zu erstellen – dafür mussten wir die Strukturen einer Vielzahl an Queries aus dem BW-System des Kunden analysieren. Schon in der Planungsphase war uns klar, dass wir dafür eine leistungsstarke, toolgestützte Lösung benötigen würden. Als Partner von bluetelligence kannten wir die Stärken der Performer Suite und entschieden uns daher für den Einsatz einer zeitlich begrenzten Lizenz im Projekt.
Ziel war es, pro Composite Provider eine Master Query zu erstellen, die alle globalen und lokalen berechneten und eingeschränkten Kennzahlen sowie alle für das Reporting relevanten Merkmale enthält. Um nur die für das Reporting relevanten Kennzahlen zu übernehmen, analysierten wir zunächst mit der System Scout Analyse Data Loads and Usages alle in den letzten 18 Monaten ausgeführten Queries:
Diese Analyse lieferte uns pro Composite Provider eine Liste aller relevanten Queries. Für eine zentrale Auflistung der Definitionen aller globalen und lokalen berechneten und eingeschränkten Kennzahlen griffen wir auf den Query SetCard Designer zurück. Wir erstellten eine SetCard, in der wir alle erforderlichen Informationen der in den Queries verwendeten Kennzahlen erfassten:
Mit Hilfe des Docu Performers (ein Tool der Suite) konnten wir anschließend die Queries gemäß unserer SetCard-Vorlage nach Excel exportieren. Dabei war es wichtig, die Einstellung One file per documentation zu deaktivieren, um nicht für jede Query eine separate Excel-Datei zu erzeugen. Das Resultat war eine konsolidierte Übersicht der Kennzahl-Informationen pro Composite Provider. Diese Übersicht nutzten wir als Vorlage für die Erstellung der Master-Queries.
Planung der Migration und Datenfluss-Analyse
Zu Beginn der Migration entwickelten wir einen strukturierten Wellenplan, der auf eine schrittweise Umstellung während der Projektlaufzeit setzte, anstatt eines einzigen großen Big Bang am Ende. Dieser Ansatz ermöglichte es uns, Reporting-Szenarien iterativ von SAP BW nach SAP Datasphere zu migrieren, zu testen und User Acceptance Tests (UAT) mit den Fachbereichen durchzuführen.
Diese Strategie bot mehrere Vorteile:
Der Kunde nahm in einem ersten Schritt die Aufteilung der Wellenplanung auf Ebene von BW InfoAreas vor. Basierend auf diesen Vorgaben identifizierten wir die betroffenen CompositeProvider mithilfe der Entity-Listen in der Performer Suite. Wir erstellten Listen dieser Provider, angereichert mit zusätzlichen Attributen, und stellten sie dem Kunden zur Verfügung. Dies ermöglichte eine präzise Nachjustierung der Planung, da nicht alle CompositeProvider aus einer InfoArea aufgrund von Abhängigkeiten zwangsläufig in der gleichen Welle migriert werden konnten.
Unsere Aufgabe war es, die Datenflüsse je Composite Provider vollständig und reibungslos mit dem BW Conversion-Tool als Shell-Conversion zu migrieren. Obwohl das Conversion Tool Abhängigkeiten durch eine Scope-Analyse selbst ermitteln kann, erwies es sich als sinnvoll, die Objekte manuell auf mehrere Conversion Tasks zu verteilen. Die automatische Scope-Analyse liefert oft sehr umfangreiche Objektlisten, was das Risiko von Abbrüchen bei komplexen Abhängigkeiten erhöht. Zudem werden bestimmte Abhängigkeiten, wie Lookups in ABAP-Transformationen, nicht automatisch erkannt.
Unsere Lösung bestand darin, den Scope pro Conversion-Schritt manuell zu definieren, um damit eine bessere Handhabbarkeit zu erreichen und die Migrationskomplexität zu reduzieren. Basierend auf dieser Vorgehensweise entwickelten wir folgende Priorisierung für die Migration:
Die DDIC-Objekte mussten manuell auf der BTP ABAP Cloud Umgebung der BW Bridge angepasst und aktiviert werden. Diese Umgebung ist restriktiver als ABAP Classic und erlaubt nur von SAP freigegebene APIs. Die meisten bestehenden ABAP-Entwicklungen erforderten daher ein erhebliches Refactoring.
Für die Erstellung der Scope-Listen benötigten wir pro Composite-Provider eine vollständige Auflistung aller Objekte des Datenflusses, einschließlich Transformationen und DTPs. Hierfür nutzten wir die Datenfluss-Analyse in der Performer Suite. Diese ermöglichte es uns, alle Objekte des Datenflusses einem Szenario (in unserem Fall einer Migrationswelle) zuzuordnen.
Anschließend konnten wir in der Entity-Liste der Performer Suite alle Objekte durch Selektion auf das entsprechende Szenario auswählen und als Liste ausgeben.
Diese Listen dienten als Arbeitslisten für die Migration und wurden mit zusätzlichen Informationen (z.B. Transformation verwendet ABAP-Coding) und dem Migrationsstatus angereichert. Dieser Ansatz erlaubte uns eine transparente und strukturierte Verwaltung der zu migrierenden Objekte für jede Welle.
Weitere Anwendungsbereiche im Projektverlauf
Die Performer Suite erwies sich als vielseitiges Werkzeug in unserem Migrationsprojekt. Besonders wertvoll waren die einfachen Möglichkeiten, schnell Listen von BW-Objekten für verschiedene Zwecke zu erstellen.
Im Laufe des Projekts stießen wir trotz Tool-Support natürlich auch auf Herausforderungen und Limitationen. Dies betraf vor allem Einschränkungen seitens SAP, aber auch Möglichkeiten, die die Performer Suite (noch) nicht bietet.
Der Export der Query Set Cards erwies sich für 3.x Query-Versionen als problematisch, was manuelle Überprüfungen erforderlich machte. Bei größeren Query-Selektionen traten gelegentlich Abbrüche auf, sodass wir die zu einem Composite Provider gehörenden Queries auf mehrere Export-Jobs aufteilen mussten. Die Konsolidierung der einzeln dokumentierten Queries auf einem Sheet erforderte zusätzlichen Aufwand, den wir durch ein selbst entwickeltes Makro bewältigten. Eine zielgerichtetere Analyse aller globalen und lokalen Kennzahlen eines Composite Providers, beispielsweise als System Scout Analyse, wäre hier zukünftig wünschenswert.
Das größere Hindernis für unseren Ansatz der Master-Queries waren die umfangreichen Restriktionen beim Entity-Import in Datasphere, die in einer SAP Note detailliert aufgeführt sind (https://me.sap.com/notes/2932647). Der Importprozess erwies sich als intransparent, da nicht ersichtlich war, welche Probleme auftraten und manuelle Korrekturen erforderten. Einige Features verhinderten den Import komplett, andere wurden übersprungen, was zu unvollständigen Kennzahldefinitionen führte. Besonders gravierend waren die Einschränkungen bei den unterstützten Formeloperatoren. Die Beschränkung auf lediglich die Grundoperationen (+, -, *, /) macht den Entity-Import für Queries in der Praxis nahezu unbrauchbar. Reale Queries weisen häufig Komplexitäten auf, die weit über diese einfachen Operationen hinausgehen. Angesichts dieser Probleme erwies sich die manuelle Anlage der Kennzahlen in Datasphere letztendlich als effizienter. Wir beschränkten den Entity-Import auf die Composite Provider, aus denen wir dann die Analytic Models erstellten, und legten die Kennzahlen manuell in den Analytics Models an. Dabei nutzten wir die Listen der Query Set Cards als Grundlage, die wir für die Master Queries erstellt hatten.
Bei der Erstellung der Objektlisten für die Migrationswellen stießen wir in der Performer Suite auf eine weitere Herausforderung: Die Datenfluss-Analyse ermöglichte keine direkte Zuordnung der DTPs zu den Szenarien. Wir mussten in der Entity-Ansicht über die Parent-Spalte iterativ die InfoProvider aus dem Szenario abprüfen, um festzustellen, welche DTPs zu welchen InfoProvider gehören, und diese dann nachträglich dem Szenario zuordnen. Eine einfachere Funktionalität zur ganzheitlichen Erfassung aller Komponenten eines Datenflusses, einschließlich DTPs, ohne die Notwendigkeit von Workarounds, hätte den Prozess erheblich vereinfacht und beschleunigt.
Abschließend lässt sich sagen, dass der Einsatz der Performer Suite sich in unserem Projekt als äußerst wertvoll erwiesen hat, um den manuellen Aufwand und potenzielle Fehlerquellen zu reduzieren und den gesamten Migrationsprozess zu beschleunigen. Die Projektlizenz bot den Vorteil, dass wir nur eine temporäre Lizenz für den spezifischen Anwendungsfall erwerben mussten. Unser Anspruch war es nicht, die Performer Suite in den Alltag der IT zu integrieren, sondern sie gezielt für unseren Zweck zu nutzen. Daher war auch kein Expertenwissen in allen Facetten des Tools erforderlich.
Wir sind uns bewusst, dass wir möglicherweise noch mehr hilfreiche Informationen aus dem Tool hätten herausholen oder direkt mit den Listen im Tool hätten weiterarbeiten können. Oft griffen wir auf die altbewährte Methode zurück, die wir bei Kunden häufig sehen und vor der wir normalerweise warnen: Den Export nach Excel, gefolgt von einer kreativen Weiterbearbeitung der Daten. Aber manchmal muss man eben pragmatisch sein! Wenn es für die Projektbeteiligten, die nicht alle Zugang zum Tool hatten, einfacher war, mit Objektlisten in der vertrauten Umgebung von Excel zu arbeiten, dann war das von unserer Seite völlig in Ordnung.
Neben den bereits genannten Features im Hinblick auf Kennzahlen- und Datenfluss-Analyse sehen wir noch spannendes Potenzial für zukünftige Erweiterungen, die den Nutzen der Performer Suite in solchen Projekten weiter steigern könnten:
Haben Sie Fragen zu SAP Datasphere oder SAP BW Bridge? Versuchen Sie das nötige Know-how in Ihrer Abteilung aufzubauen oder benötigen Sie Unterstützung bei einer konkreten Fragestellung? Wir helfen Ihnen gerne dabei. Nehmen Sie einfach Kontakt zu uns auf!