SAP BW - Warum Sie ein Upgrade in Betracht ziehen sollten, bevor Sie migrieren.
Dieser Blog beschreibt die technischen Herausforderungen bei der Migration UND dem Downgrade von SAP BW 7.5 (SP15) on Hana auf SAP BW 7.4 (SP13) on Hana. Der Fokus liegt dabei auf den Standard SAP BW Modellierungswerkzeugen (Version 1.21.22) und den SAP Hana Studio Entwicklungswerkzeugen (Version 2.3.45) sowie dem Einsatz der BW Integrierten Planung. Bitte beachten Sie, dass es sich hierbei lediglich um praktische Beobachtungen handelt, die weder verallgemeinern noch die Nutzung von SAP BW kritisieren sollen.
Im Laufe der Jahre hat SAP Business Warehouse viele Funktionalitäten angeboten, und wo alte ersetzt wurden, sind neue hinzugekommen. Die Kernprinzipien waren jedoch immer dieselben: eine nahtlose Benutzererfahrung für funktionale und technische Benutzer, unabhängig davon, an welchem Ende des Spektrums man sich befindet.
Während eines unserer letzten Projekte standen wir vor der Herausforderung, aufgrund einer Firmenübernahme ein Downgrade auf eine niedrigere SAP BW-Version durchzuführen.
Neben der Überlegung, wie wir das beste Datenmodell für unserer Benutzer entwickeln können, musste man vorab eine andere Frage stellen: Was ist die beste Möglichkeit, die bestehende BW-Lösung zu migrieren, um die gleiche funktionale und technische Leistung zu erreichen (oder sogar zu verbessern) und gleichzeitig ein Downgrade auf eine niedrigere Softwareversion durchzuführen?
Obwohl ein Upgrade immer auf der Tagesordnung stand, wäre es nicht vor Abschluss des Migrationsprojekts durchgeführt worden. Dies brachte uns in eine interessante Lage und stellte uns vor einigen grossen Herausforderungen. Bald fanden wir jedoch heraus, dass es auf diese Frage zwei einfache Antworten gibt:
Hardware-Spezifikation und Software-Anwendungsversion.
Im Bereich der BW-Entwicklung ist dies kein «irrelevanter Quatsch», also lassen Sie uns die Software-Seite dieser Gleichung untersuchen.
BW Roadmap
Da SAP BW 7.4 nun nicht mehr unterstützt wird, sollten alle Unternehmen, die diese Version noch verwenden, auf SAP BW 7.5 oder SAP BW/4HANA umsteigen oder andere SAP-Alternativen wie Data Warehouse Cloud in Betracht ziehen oder vielleicht einen hybriden Ansatz aus On-Premise und Cloud wählen. Dies kann offensichtliche Einschränkungen in Bezug auf das Budget und die Planung mit sich bringen, weshalb es dringend angeraten ist, die Optionen sorgfältig zu prüfen, bevor sie in einen tatsächlichen Projektplan umgewandelt werden.
Was passiert aber, wenn Sie diese Entscheidung noch nicht treffen können, sondern eine BW-Systemmigration durchführen und andere Altsysteme in Ihre Systemlandschaft einbinden müssen? Dann steht das Releasemanagement ganz oben auf der Liste: Welche Softwareversion verwende ich derzeit, auf welche Version werde ich migrieren und sollte ich vor der Migration ein Upgrade in Betracht ziehen? Lassen Sie uns auf diese Aspekte etwas näher eingehen.
Release Management; die Herausforderungen
Während einige Unternehmen den SAP Solution Manager zur Planung, Verwaltung und Terminierung ihrer Softwarefreigabe nutzen, entscheiden sich andere dafür, ihre Anwendungsversion jährlich zu überprüfen und die jeweils neueste Version anzuwenden, und dann gibt es noch einige, die sich dazu verpflichten, Fehlerbehebungen «im Vorbeigehen» vorzunehmen und ein Upgrade durchzuführen, wenn der Support (fast) ausläuft. Letzteres ist oft auf einen Mangel an Zeit und Planung zurückzuführen und ist eigentlich eine noch zeitaufwändigere und potenziell kostspieligere Angelegenheit. Warum also nicht die ersten beiden Optionen in Betracht ziehen, bevor eine Systemmigration erfolgt?
SAP BW Produktmerkmale
In 7.5 on Hana und BW/4HANA wurden die Modellierungseinheiten vereinfacht, um einen flexibleren und agileren Ansatz bei der Datenmodellierung zu ermöglichen.
Das erweiterte DataStore-Objekt
Jeder BW-Entwickler, der mit den ältesten und neuesten verfügbaren Modellierungsobjekten vertraut ist, wird Ihnen aus einfachen Gründen zur Verwendung der neuesten Objekte raten: Benutzerfreundlichkeit, Flexibilität und um den Weg zu SAP BW/4HANA so reibungslos wie möglich zu gestalten. Hier wird das klassische BI-Artefakt «Data Store Object» (DSO) nicht die komplette Arbeit für Sie erledigen. Ja, es wird Daten nach Bedarf persistieren, aber es ist nicht vollständig HANA-optimiert, und, was noch wichtiger ist, Ihre Möglichkeiten sind im Vergleich zu einem Advanced Data Store Object (ADSO) in Bezug auf seine Modellierungseigenschaften, Daten-Tiering-Eigenschaften und Kompressionsfähigkeiten begrenzt. Und nicht zu vergessen, mit einem ADSO können Sie auch eine feldbasierte Datenbanktabelle ohne Bezug zu einem BW-Info-Objekt erstellen, was die Flexibilität, Verwaltbarkeit und Reichweite des Data Warehouse erhöhen kann.
In einer idealen BW-Umgebung ersetzen wir daher das klassische DSO oder den BW-Infocube durch ein ADSO, aber leider gibt es in SAP BW 7.4 immer noch Gründe, die die Verwendung dieses speziellen Objekts rechtfertigen, z.B.: Was tun Sie, wenn Sie ein «Direct Update DSO» in einem «BW Integrated Planning»-Szenario benötigen und gleichzeitig einen aus einer beliebigen Datenquelle geladenen Anfangsdatensatz erstellen und persistieren möchten? In SAP BW 7.4 (SP13) können Sie keine Quelle-Ziel-ETL-Transformation erstellen, die ein «Direct Update DSO» abbildet, und schon gar nicht, wenn Sie ein ADSO-Objekt verwenden (das «Direct Update ADSO» ist erst ab BW 7.5 SP1 verfügbar), so dass wir gezwungen sind, einen BW-Infocube zu verwenden, was alles andere als ideal ist.
Ebenso ist die Erstellung von Exportdatenquellen (8*) auf einem DSO- oder Infocube-Objekt in BW 7.4 und BW 7.5 immer noch möglich, aber dies wird durch die BW-ODP-Infrastruktur (Operational Data Provisioning) ersetzt, und es wird daher empfohlen, stattdessen den ODP-Mechanismus zu verwenden, wenn möglich. Da ODP zum Zeitpunkt der Migration noch nicht in der Systemumgebung implementiert war, waren wir erneut gezwungen, ein DSO zu verwenden und diese alte «3.x»-Funktionalität zu replizieren. Noch enttäuschender war, dass das ODP-Framework teilweise erst nach dem Go-Live implementiert wurde, was bedeutet, dass wir die 8*-Exportdatenquelle nach der Konvertierung immer noch durch die neueste ODP-Version aus dem ADSO ersetzen sollten.
Um die DSO- vs. ADSO-Debatte abzuschliessen: Wir wurden beim Downgrade auf BW 7.4 nicht gerade mit Optionen verwöhnt.
Damit ist klar, dass das klassische DSO-Objekt seine besten Zeiten hinter sich hat und wir uns nach Möglichkeit in die neue BW-Entwicklungswelt begeben sollten.
Der Composite-Provider
Im vorangegangenen Abschnitt haben wir die Verwendung eines ADSO «befürwortet», aber wir haben noch nicht die Ziellinie erreicht. Das ADSO ist das bevorzugte Modellierungsobjekt, aber was könnte bei seiner Verwendung in einem Composite Provider passieren? Sie mappen/verbinden doch einfach die gewünschten ADSO-Quell- und Zielfelder, prüfen/aktivieren das Objekt und Ihr Composite Provider ist bereit für die weitere Verwendung?
Leider ist das Spiel noch nicht zu Ende, und wir befinden uns jetzt in der «Verlängerung» (im wahrsten Sinne des Wortes), je nachdem, welches Support Package Sie verwenden; zum Beispiel könnte es das Problem geben, das ADSO-Quellfeld-Navigationsattribut auf ein Composite Provider-Zielfeld zu mappen.
Dies könnte zu einem Programmfehler führen und ist nicht zulässig, es sei denn, Sie haben die entsprechenden SAP-Hinweis-Korrekturanweisungen angewendet (siehe SAP-Hinweise 2213428 und 2359931 für eine mögliche Lösung).
Lösung/Workaround? Erstellen Sie einen Composite Provider mit dem entsprechenden ADSO und verwenden Sie diesen innerhalb des Haupt-Composite Providers! Dieser Ansatz ist zwar aus technischer Sicht durchaus möglich, wird aber nicht von jedem befürwortet, und schon gar nicht, wenn der Composite Provider selbst mehr als einen Quellprovider enthält, da dies der Leistung abträglich sein könnte.
Es wird jedoch das oben beschriebene Problem lösen, so dass die Verwendung des ADSO immer noch sehr lebendig ist, so dass wir einen klaren Gewinner haben, wenn auch in einer etwas anderen Form aufgrund der Einschränkungen in BW 7.4 (SP13) bei der Arbeit mit Composite Provider-Funktionen.
Was ist, wenn Sie eine HANA Calculation View innerhalb eines Composite Providers verwenden möchten und die Calculation View Eingabeparameter enthält? In einem normalen Szenario würden Sie einfach die Feldzuweisungen erstellen und das Composite Provider-Objekt ist bereit zur Verwendung? Nun, noch nicht ganz, denn es könnte ein ‹Move Cast Error› (programmbezogener Fehler – siehe SAP-Hinweis 2302832) auftreten. Das bedeutet, dass einige Objekttypen in BW 7.4 SP13 noch nicht vollständig für die Verwendung auf HANA optimiert sind, was ein weiterer Grund ist, die alternativen Support Packages oder die Gesamtversion Ihrer BW-Produktinstallation (erneut) zu prüfen.
Man könnte noch viele weitere SAP-Hinweise aufzählen, die sich mit den Herausforderungen bei der Entwicklung von Queries befassen, z.B. mit der Verwendung von Merkmalshierarchien, bei denen die Pflege/Aktivierung der Hierarchie nicht möglich war (siehe z.B. SAP-Hinweis 2336689), mit der Verbesserung der Query-Performance bei der Anwendung einer Einheitenumrechnung (siehe z.B. SAP-Hinweis 2120776) oder mit der Verwendung des Query Designers anstelle von HANA Studio/Eclipse, um einen schwerwiegenden kritischen Fehler bei der Erstellung von inversen Formeln für eine eingabebereite BW-Query zu vermeiden.
Aber… lassen Sie uns nicht in der Welt der SAP-Support-Hinweise versinken; wie wir wissen, gibt es eine ganze Reihe davon, aber letztlich ist die Botschaft klar: Neue oder erweiterte Funktionen verbessern die Funktionalität, was zu einer stabileren und zuverlässigeren BW-Anwendung führt, und dies stärkt letztlich die Brücke zwischen dem technischen Entwickler und dem funktionalen Benutzer, um die betriebliche Leistung insgesamt zu verbessern.
Schlussfolgerung
Nach dem Motto «Es gibt für alles eine Lösung» war dieses spezielle Downgrade-Migrationsprojekt erfolgreich, doch die daraus gezogenen Lehren liegen auf der Hand und sollten nicht auf die leichte Schulter genommen werden, da sie letztendlich wertvolle Zeit sparen und die Ausgaben senken können.
Die vorangegangenen Beispiele sind ein guter Grund, neue SAP BW Support Packages regelmässig zu prüfen und anzuwenden. Die neuesten Korrekturen und Funktionalitäten sorgen nicht nur dafür, dass weniger technische Probleme/Fehler auftreten und die Behebung weniger Zeit in Anspruch nimmt. Darüber hinaus ist ein solides Release-Management eine wesentliche präventive Wartungsmassnahme, die letztlich den Weg für den Übergang von einem soliden Business-Warehouse-Informationssystem zu einer der fortschrittlichsten und vielseitigsten Warehouse-Lösungen auf dem Markt ebnet: SAP BW/4HANA.
Wenn Sie also noch «alte» BI-Artefakte in Ihrem Business Warehouse haben und ein Patching oder Upgrade in Erwägung ziehen, würden wir Ihnen empfehlen, die neueste SAP-Roadmap-Dokumentation sorgfältig zu lesen, da sie verschiedene Voraussetzungen und andere SAP-Hinweisverweise enthält, um Ihre Datenmodellobjektkonvertierungen auf dem Weg zu SAP BW/4HANA zu beginnen (SAP-Hinweis 2383530 ‹Conversion from SAP BW to SAP BW/4HANA›).
NTT DATA Business Solutions hat einige einzigartige Angebote, um Sie bei der Umstellung Ihrer BW-Landschaft zu unterstützen, damit Sie das Potenzial von SAP BW/4HANA voll ausschöpfen können; eine Lageranwendung der nächsten Generation, die wirklich einen Wendepunkt darstellt.