Einleitung  

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 vom Beratungsunternehmen NextLytics und Softwareanbieter 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:

• Investition in BW-Modelle: Oft wurde viel Aufwand in die Entwicklung spezifischer BW-Modelle gesteckt, die komplexe Business-Logiken und individuelle Datenflüsse – teilweise mit umfangreicher ABAP-Logik – enthalten.

• Eingeschränkte Verfügbarkeit von CDS-basierten Extraktoren: In Fällen, in denen SAP-basierte Quellsysteme noch nicht die erforderlichen CDS-Extraktoren bereitstellen (z.B. bei SAP ECC-Systemen), müssen klassische S-API-Extraktoren genutzt werden. Es wird jedoch davon abgeraten, diese direkt an SAP Datasphere anzubinden, da Einschränkungen bestehen, beispielsweise wenn DataSources zwingend Selektionsfelder benötigen oder bestimmte Delta-Verfahren nicht unterstützt werden.

• Mangel an spezifischen Kompetenzen: Häufig verfügen Teams über umfangreiche BW- und ABAP-Expertise, während Know-how zu SQL oder Python, die in SAP Datasphere genutzt werden – nicht ausreichend vorhanden ist, um die Modelle nativ neu zu erstellen.

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.

Zielbild und Vorgehensweise

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:

• Migration der Modelle und Datenflüsse bis zum Composite Provider

2. Entwicklung und Übertragung von Master-Queries:

• Abbildung aller globalen und lokalen berechneten und eingeschränkten Kennzahlen sowie aller für das Reporting relevanten Merkmale
• Erstellung pro Composite-Provider
• Übertragung mittels Shell Conversion

3. Generierung der Analytics Models:

• Entity-Import der Master-Queries
• Automatische Erstellung der Analytics Models basierend auf importierten Queries

4. Umstellung des Reportings:

• Umstellung des query-basierten Reportings auf Analytics Models in den verschiedenen Frontend-Tools

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:

• Weitere Non-SAP Quellsysteme
• Detailliertes Layer-Konzept
• SPACE-Konzept für die Zusammenarbeit von Central IT und Fachbereichen
• Implementierung von Berechtigungen über Data Access Controls
• Berücksichtigung spezifischer Anforderungen je nach Datenabnehmer (z.B. via ODBC oder OData)

Für detaillierte Informationen können Sie sich gerne den NextLytics-Blogbeitrag zur Referenzarchitektur SAP Datasphere ansehen: Blog Nextlytics: Datasphere Referenzarchitektur – Überblick & Ausblick

Praktischer Einsatz der Performer Suite im Projekt

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:

1. Risikominimierung durch schrittweise Umstellung
2. Frühzeitige Stabilisierung der neuen Umgebung
3. Kontinuierliches Lernen und Optimieren der Vorgehensweise
4. Flexibilität, um auf Herausforderungen zu reagieren, ohne das Gesamtprojekt zu gefährden

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:

1. InfoProvider (InfoObjekte, aDSOs, Composite Provider)
2. Übertragung nativer DDIC-Objekte via ABAPGit in den ABAP Stack der BW Bridge  (z.B. Lookups auf Z-Tabellen in Transformationen, Auslagerung von Routinen-Coding in ABAP-Klassen)
3. Transformationen
4. DTPs und Prozessketten

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.

• Für Ad-hoc Analysen bot die Suite (speziell der System Scout) schnelle Einblicke in Datenflüsse, die sich als detaillierter und benutzerfreundlicher erwiesen als die Datenfluss-Ansicht in den BW-Modelling-Tools.
• In Fällen, in denen Modelle nicht migriert, sondern archiviert wurden, nutzten wir die Suite zur schnellen Erstellung von kompletten Modell-Dokumentationen
• Für die Entwicklungstests war die Suite besonders nützlich, um schnell zu ermitteln, welche InfoProvider über welche Prozessketten geladen werden. Diese schnelle Übersicht hat uns dabei geholfen, den Testprozess für die Entwicklungstests effizienter zu managen.

Herausforderungen und Erkenntnisse im Projektverlauf

Im Laufe des Projekts stießen wir als Berater 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.

Fazit und Ausblick

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 (NextLytics) 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:

• Mehr ABAP-basierte Informationen in der Datenfluss-Analyse, insbesondere im Hinblick auf die ABAP Cloud Sprachsyntax. Es wäre beispielsweise sehr hilfreich, wenn man in der Datenfluss-Analyse sehen könnte, welche Transformationen ABAP-Coding verwenden, das nicht ABAP Cloud-kompatibel ist.

• Es ist erfreulich zu sehen, dass bluetelligence massiv in den Ausbau ihrer Analysen Richtung SAP Datasphere und SAP Analytics Cloud investiert. Neben Views werden künftig auch Analytics Models und Task Chains über die Performer Suite analysierbar sein, was in Migrationsprojekten beim Abgleich der alten BW-Welt mit der neuen Datasphere-Welt helfen wird. Mit unserer aktuellen Version des Tools konnten wir uns leider nur gegen das alte BW-System verbinden, nicht jedoch gegen Datasphere bzw. BW Bridge.

• Ideal wäre es natürlich, wenn der Migration Booster, der als Migrationssupport für BW zu BW/4HANA dient, künftig auch für BW Bridge-Projekte genutzt werden könnte. Dieser ermöglicht im Vergleich zum SAP Conversion Tool eine deutlich komfortablere und gezieltere Migration und erlaubt auch die Vergabe neuer Namenskonventionen. Ob SAP hierfür die APIs auf der BTP bereitstellt bzw. ob der Markt für BW Bridge-Migrationen groß genug ist, um eine solche Investition zu rechtfertigen, ist fraglich. Aber man darf sich ja noch was wünschen, ist ja bald Weihnachten 🙂

Zum Schluss an dieser Stelle noch der Hinweis seitens bluetelligence, dass Sie über das bei der Migration eingesetzte Tool, den System Scout, hier mehr erfahren: