Über dieses Tool
Eine erste Einführung in dieses Tool finden Sie im folgenden Blogbeitrag:
BW Modernization continued with the SAP BW Query Template Generator
Ein erster Erfahrungsbericht mit Hinweisen auf Installationsprobleme wird hier beschrieben:
Natürlich bietet auch die SAP-Hilfe weitere Informationen:
Query Template Generator for SAP Business Data Cloud
Wie in der Dokumentation beschrieben, generiert dieses Tool alle erforderlichen Artefakte in Datasphere. Dieses Tool migriert keine Daten. Es liegt in Ihrer Verantwortung, anschließend alle Artefakte mit den korrekten neuen Sources in Datasphere zu verbinden. Da ein typisches Model aus einer Vielzahl von Dimensions besteht, ist die entsprechende Liste in der Regel recht umfangreich.
Abbildung 1: Funktionsumfang des Query Template Generators (Quelle: help.sap.com)
Installationserfahrung
Die Installation war recht unkompliziert. Ob alle erforderlichen Resources in Ihrem System verfügbar sind, können Sie einfach prüfen, indem Sie die Transaction RSDWCTG_ADMIN in Ihrem BW System starten. Diese Transaktion kann als Alternative zur Eclipse View für die Administration der Migration verwendet werden. In unserem System war diese Transaktion jedoch nicht vorhanden. Daher mussten wir zunächst die folgenden SAP-Hinweise einspielen:
3724724 – Data Subscriptions 4.0 for BW on HANA and BW/4HANA 2021 and 2023
3757146 – DPG & QTG – Correction collection after TCI 4.0 – 1
3774224 – DPG & QTG – Correction collection after TCI 4.0 – 2
Nach Durchführung aller Schritte der Installationsanleitung aus dem Hinweis
3590400 – Configuring the Data Product Generator and Query Template Generator fo
funktionierte das Tool.
Um das Tool nutzen zu können, benötigt man die neue Berechtigung S_ADT_RES. Mit dieser Berechtigung kann eingeschränkt werden, welche Queries bzw. InfoAreas ein Benutzer migrieren darf.
Migration von Queries
Nun können Sie, wie in der Dokumentation und den oben genannten Blogbeiträgen beschrieben, eine Query zur Migration auswählen.
Die Eingabe ist, wie beschrieben, unkompliziert. Wenn die ausgewählte Query keine nicht unterstützten Funktionen enthält (siehe nächstes Kapitel), können Sie die Migrations Anforderung erstellen und die Migration starten. Die Migration benötigt einige Zeit, um alle Objects anzulegen. Für etwa 150 Objects kann dies bis zu 30 Minuten dauern. Wie eine laufende Migration überwacht werden kann, wird im nächsten Kapitel beschrieben.
Falls einige Objects bereits in Datasphere vorhanden sind, verhält sich das Tool unterschiedlich, je nachdem, ob es über SAP GUI oder Eclipse gestartet wird. Die folgende Option entsteht beim Start über SAP GUI zur Verfügung, jedoch nicht beim Start über Eclipse.
Abbildung 2: Option zur Vermeidung des Überschreibens bestehender Objects beim Start über SAP GUI
Wenn Sie die Option „No Overwrite“ verwenden, zeigt das Protokoll zwar an, dass der Eintrag aktualisiert wurde, die Objekte in der Datasphere bleiben jedoch unverändert und die Migration ist schneller (siehe Abbildung unten).
In Eclipse erhalten Sie dagegen eine detaillierte Warnung darüber, welche Objects bereits existieren und welche überschrieben werden. Die einzige verfügbare Option besteht darin, fortzufahren:
Abbildung 3: Information zu den in Eclipse zu ändernden Objects mit der einzigen Option fortzufahren; keine Auswahlmöglichkeit für „No Overwrite“
Beim Start aus Eclipse werden bereits vorgenommene Änderungen überschrieben. Es gibt keine Möglichkeit, dies zu verhindern (zumindest haben wir keine Lösung dafür gefunden). Die einzige verbleibende Möglichkeit besteht darin, die entsprechenden Objects in Datasphere manuell auf die aktive Lösung zurückzusetzen.
- Verwenden Sie daher immer die SAP-GUI-Version, wenn bereits Änderungen an Master Data vorgenommen wurden, sonst müssen sie manuell jedes Objekt wieder zurück auf die veröffentlichte Version setzen.
Das Tool liefert eine detaillierte Liste der in Datasphere zu erstellenden Objects. Leider ist es nicht möglich, den Target Name vor der Generierung anzupassen. Laut Roadmap ist jedoch die Wiederverwendung von Objects für Q4 geplant. (s. folgenden Roadmap Eintrag:Query template generator: reuse of object store entities)
Abbildung 4: List der zu migrierenden Objekte im SAP – GUI
Nur das Analytical Model und die Fact View erhalten das Prefix. Alle anderen Objekte behalten ihren ursprünglichen Namen.
Abbildung 5: Das Prefix UM_ wird nur dem Analytical Model und der View hinzugefügt, nicht jedoch den InfoObjects, beispielsweise 0COMP_CODE. Nach dem Migration Run müssen die Objects noch deployed werden. Wird die Migration über SAP GUI mit der Option „No Overwrite“ gestartet und existiert bereits ein deploytes Objekt, bleibt dieses unverändert. Im gezeigten Beispiel wurde 0COMP_CODE_TEXT nicht verändert und verblieb im Status deployed. Beim Start aus Eclipse wird das Object hingegen aktualisiert und auf den Status „not deployed“ gesetzt.
Nach erfolgreichem Start erscheint im SAP – GUI eine Meldung mit allen Objekten aus dem Lauf mit dem Hinweis auf ein Update, unabhängig, ob diese angefasst wurden oder nicht!
Abbildung 6: Information im SAP GUI nach dem Start des Runs mit der Option „No Overwrite“. Die Meldung informiert darüber, dass alle Einträge aktualisiert werden, auch wenn dies tatsächlich nicht der Fall ist.
Überwachung einer laufenden Migration
Um zu prüfen, ob die Object Generation noch läuft, können Sie den ODQ Monitor in der Transaction ODQ_TQ_MONITOR verwenden. Für jedes Object wird dort ein eigener Eintrag erzeugt. Die zugehörige ID finden Sie im detaillierten Log des QMT am Ende der Liste (wenn über SAP GUI gestartet).
Requests, die noch auf ihre Ausführung warten, haben den Status „W“. Laufende Requests sind mit „R“ gekennzeichnet. Nach erfolgreichem Abschluss ist das Statusfeld leer.
Abbildung 7: Log mit ODQ Monitor ID
Abbildung 8: Monitor der laufenden Migration Steps in der Transaction ODQ_TQ_MONITOR (in BW/4, über GUI gestartet)
Einschränkungen des Tools
Wenn Sie eine Query auswählen, die Funktionalitäten verwendet, welche von der Migration nicht unterstützt werden, müssen Sie im Log nachschauen, um zu sehen, welche Funktionalität nicht migriert wurde. Im folgenden Beispiel die Meldungen für die Migration einer Query aus dem aus dem Technischen Content (0TCT_MC01_Q0424):
Abbildung 9: Nicht unterstützte Funktionalität im Migrationstool wird als Warnung im Protokoll angezeigt
Folgende Einschränkungen beziehungsweise Limitierungen konnten wir bisher identifizieren:
Achtung: Diese Liste ist mit Sicherheit nicht vollständig und kann sich in zukünftigen Releases ändern!
- Es können nur Queries auf Basis von CompositeProvidern oder MultiCubes migriert werden. Queries auf Aggregationsebenen oder direkt auf einem aDSO werden nicht unterstützt.
- Da Queries auf Aggregationsebenen nicht unterstützt werden, wird auch die Planning-Funktionalität nicht unterstützt!
- Cell Definitions und Exceptions werden ignoriert.
Und hier unsere Positivliste (ebenfalls nicht vollständig):
- Query mit zwei Strukturen
- Currency Conversion
Bisher gefundene Fehler
Das analytische Modell, dass die Query darstellt, wird bei uns nur erzeugt, wenn wir die Migration im BW 7.5 starten. Bei der Migration eines BW/4 Systems fehlt das analytische Modell. Wir warten auf die Antwort von SAP zu unsere OSS – Meldung dazu.
