Kombination des Data Product Generators und des Query Template Generators 

Die Aufgabe

Schauen wir uns erst einmal an, was wir tun müssen. Das folgende Bild gibt einen Überblick über die nötigen Aufgaben: 

Abbildung 1: Überblick über den Query Template Generator (QTG) in Kombination mit dem Data Product Generator (DPG)

Im QTG wird ein Analytic Model erstellt, das eine Fact View und Dimensionen verwendet, die auf leere Tabellen verweisen. Diese Tabellen müssen so ersetzt werden, dass sie die vom DPG generierten Tabellen lesen. Später können diese Tabelle dann noch mit den Quellen für neue Daten verknüpft werden. 

• Unterschiedliche Benennung der Dimensionen  

• Content-Dimensionen besitzen im QTG eine führende 0, im DPG nicht  

• Kundendimensionen besitzen im DPG das Präfix /BIC/, im QTG nicht  

• DPG speichert Objekte im Data-Lake-Filespace, QTG im HANA-Datenbankbereich  

• Falls in der Query kein technischer Name vergeben wurde, wird im QTG stattdessen eine GUID verwendet und generiert. Die Identifizierung der korrekten Kennzahlspalten in der Query kann dadurch eine Herausforderung darstellen. 

• Der QTG erzeugt für alle InfoObjects und Attribute des zugrunde liegenden InfoProviders, z.B. einen Composite Provider Artefakte in der Datasphere. Diese Artefakte werden erzeugt, unabhängig davon, ob sie in der Query verwendet werden oder nicht. Selbst bei kleinen Modellen werden viele Objekte generiert, z.B. bei unserem Testfall mit wenigen Dimensionen hat QTG über 50 Objekte in Datasphere erzeugt. Alle diese Artefakte müssen später manuelle den Tabellen zugeordnet werden, die die migrierten Daten enthalten.. 

Schauen wir uns nun all diese Herausforderungen einmal genauer an. 

Auswahl der Query

Da die Zuordnung aller Attribute etwas aufwendig ist, sollten wir uns zunächst ansehen, welche Query migriert werden soll und wie wir uns darauf vorbereiten können. 

Wozu wird die migrierte Query in unserer neuen Umgebung verwendet? Mit dem QTG wird für jede Query ein Analysemodell erstellt. Dieses Modell wird dann innerhalb der SAC als Datenquelle verwendet. Somit müssen wir nicht jede einzelne Query migrieren, die zur Vereinfachung der Berichterstellung erstellt wurde und sich lediglich in den ausgewählten bzw. gefilterten Dimensionen usw. unterscheidet. Stattdessen sollten wir uns auf sehr wenige Queries pro Infoprovider konzentrieren, die alle Filter- und Berechnungslogik in den Spalten und Strukturen enthalten.  

Vorbereitung der Query

Bei der Vorbereitung einer Query für die Migration sollten wir folgende Punkte berücksichtigen: 

• Technische Bezeichnungen der Strukturelemente in der Query 

• In der Query angezeigte freie Dimensionen und Attribute 

Technische Namen von Strukturelementen 

Falls Ihre Query Strukturen oder eingeschränkte Kennzahlen enthält, verwendet das QTG entweder einen in der Query vorhandenen technischen Namen als ID für die Elemente im Analysemodell. Ist kein technischer Name angegeben, verwendet das QTG eine GUID zur Benennung. Wenn Sie dieses Analysemodell anschließend in SAC nutzen, sehen Sie bei der Arbeit damit nur die generierten IDs. In der Tabelle wird die korrekte Beschreibung angezeigt, leider jedoch nicht im Layout der Tabellendefinition. Um nicht raten zu müssen, welches Strukturelement was enthält, sollten Sie bereits in der Query-Definition technische Namen pflegen. Diese Namen werden dann anstelle der generierten IDs verwendet, was die Tabellendefinitionen vereinfacht. 

Abbildung 2: Gleiches Ergebnis für Strukturelemente mit und ohne technischen Namen, jedoch kryptische IDs bei fehlenden technischen Namen.

Freie Dimensionen und Attribute

Auch wenn das QTG Artefakte für ALLE abhängigen Objekte in Datasphere und der Faktenansicht generiert, markiert es nur diejenigen, die in der Query verwendet werden, als im Analtic Model  sichtbar – und somit später auch in SAC, wenn die Daten genutzt werden. 

Daher fügen Sie entweder alle relevanten Dimensionen als freie Dimensionen in die Query ein und zeigen alle Attribute an, die Sie später in SAC in der Query anzeigen möchten. Sollten Sie dies versäumen, können Sie dies später auch im Analytic Model nachholen. 

Korrektur des Fakten Views

Teilen und zuordnen der Dimensions- – Namen 

DPG speichert unsere Daten im Data-Lake-Space, während sich unser Analysemodell für das QTG in einem HANA-Datenbank Space befindet. Als Erstes müssen Sie also die benötigten DPG-Tabellen mit dem Space teilen, den Sie für das QTG verwendet haben. 

Der nächste Schritt besteht darin, die unterschiedlichen Logiken für technische Bezeichnungen zwischen QTG und DPG abzubilden. Aus welchem Grund auch immer hat sich SAP dafür entschieden, zwei unterschiedliche Logiken für die Zuordnung technischer Bezeichnungen zu verwenden. 

Abbildung 3: Abweichungen bei technischen Namen zwischen QTG und DPG

Wir haben dieses Problem für die Faktentabelle gelöst, indem wir eine View (fact) erstellt haben, der dem vom DPG erstellten View ähnelt, wobei wir jedoch die „FROM“-Auswahl durch unsere getielte Tabelle ersetzt haben. Falls Ihr Modell Navigationsattribute verwendet, müssen Sie möglicherweise mehrere Tabellen anpassen. 

Nun weist der View einen Syntaxfehler auf, da die Spalten in den DPG-Tabellen unterschiedliche Namen haben. Passen Sie nun die Spaltennamen entsprechend an, lassen Sie den AS-Feldnamen jedoch unverändert. 

Abbildung 4: Korrigierter View (Fact) zur Auswahl aus der DPG-Tabelle – Tabelle hinter FROM ersetzt und den korrigierten Feldnamen (0 entfernen oder /BIC/ hinzufügen) 

View im Analytischen Modell ersetzen

Öffnen Sie als letzten Schritt das vom QTG erstellte analytischen Modell und ersetzen Sie die Fakten-Datenquelle per Drag & Drop durch die soeben erstellte Faktenansicht. Wenn alle Spalten gefunden werden können, sollte eine Meldung ähnlich der folgenden angezeigt werden. 

Abbildung 5: Bestätigungsdialog nach Austausch der Datenquelle

Einfach ersetzen und dann veröffentlichen. Nun steht Ihr auf Ihrer Query basierendes Datenmodell zur Nutzung bereit. In der Datenvorschau können Sie das Ergebnis überprüfen. 

Die Impact– Analyse zeigt unseren einfachen Datenfluss für den Testfall. 

Abbildung 6: Impact-Analyse des migrierten Analytic Models mit der DPG-Tabelle

Mit diesen Änderungen können Sie bereits einen SAC-Bericht zu den Daten erstellen und alle Werte sollten wie erwartet angezeigt werden. Allerdings stehen Ihnen für Ihre Dimensionen keine Text und Attribute zur Verfügung. 

Korrektur der Dimensionen

Schauen wir uns nun an, wie man die Dimensionen ändert. Wenn Sie sich die Abhängigkeitsanalyse für unser einfaches Modell (nur zwei Dimensionen und die Zeit) ansehen, erkennen Sie bereits zahlreiche Abhängigkeiten. Wir müssen alle erforderlichen Quelltabellen ersetzen. Es empfiehlt sich, zunächst zu prüfen, welche Dimensionen und Attribute in Ihrem Datenmodell und Analysemodell tatsächlich benötigt werden. Alle anderen Tabellen können Sie entweder ignorieren oder deren Abhängigkeiten entfernen. 

Abbildung 7: Abhängigkeiten eines durch den QTG erzeugten Modells

Wenn Sie versuchen, die Quelle in dem grafischen Editor für den View der Dimension zu ändern, kann die View nicht veröffentlicht werden, da bei der Änderung der Quelle alle Zuordnungen zu den Attributen verloren gehen. 

Wir haben folgende Lösung gefunden: 

• Exportieren der JSON – Definition der Dimensionsansicht 

• Quelltabelle und Feldzuordnung in der JSON-Datei ersetzen 

• JSON-Definition hochladen 

Schauen wir uns die Schritte einzeln an. 

Der Export der JSON-Definition ist ganz einfach: Nutzen Sie dazu die Exportfunktion im grafischen Editors des Views. 

Nun müssen Sie die JSON-Datei öffnen und die Quelltabelle durch Ihre Tabelle des DPG ersetzen (die Sie ebenfalls vorher mit dem richtigen Space teilen müssen) sowie die verwendeten Felder durch die korrekten QTG-Bezeichnungen ersetzen, wobei Sie die 0 entfernen oder /BIC/ hinzufügen müssen. 

Dies muss zweimal erfolgen: einmal in der Definition der Query hinter „query“ und ein zweites Mal in der Definition der SQL-Ansicht, die in der grafischen Benutzeroberfläche hinter dem Tag @DataWarehouse.sqlEditor.query angezeigt wird. 

Überprüfen Sie außerdem, ob Datentyp und Länge der Spalten übereinstimmen. Da beide Tools dieselbe BW-Quelle auslesen, sollte dies eigentlich der Fall sein. Beim Buchungskreis stimmten alle 15 Spalten überein, doch die Hierarchietabellen zeigen, dass dies nicht als selbstverständlich angesehen werden kann (siehe unten). 

Abbildung 8: Korrigierte Tabelle und Attribute in der Query-Definition

Abbildung 9: Erforderliche Änderungen in der SQL-Editor-Definition

Wenn Sie den Import von der Übersichtsseite des Data Builders in Ihrem Space starten, werden Sie gefragt, ob auch die abhängigen Objekte aktualisiert werden sollen. Da wir lediglich die Quelle ersetzt und die Ausgabestruktur der Ansicht nicht verändert haben, haben wir dies abgelehnt. 

Abbildung 10: Bestätigungsdialog beim Import der korrigierten JSON-Datei

Wenn Sie bei der Bearbeitung keine Fehler gemacht haben, sollte die Quelle der Dimension ersetzt worden sein. Stellen Sie sicher, dass die Attribute im Analysemodell markiert sind. Nun sollten Sie diese beim Anlegen einer Tabelle im SAC auswählen können. 

Nach der Umstellung werden die vom QTG generierten leeren *_LT-Tabellen nicht mehr verwendet und werden auch nicht mehr benötigt. Sie zu löschen ist wahrscheinlich reine Zeitverschwendung, da sie beim nächsten Lauf des QTG für eine andere Query erneut erstellt werden. 

Texte und Hierarchien

Texte

Das gleiche Verfahren gilt für die Texte. In unserem Beispiel ist der Text des Buchungskreises im BW als sprachunabhängig definiert. Der DPG exportiert daher die Texttabelle 0COMP_CODE_text korrekt ohne Sprachschlüssel. Der QTG berücksichtigt dies nicht und generiert die Textansicht 0COMP_CODE_TEXT mit einem Sprachschlüssel (LANGU) als Teil des Schlüssels. Um beides in Einklang zu bringen, müssen Sie entweder die Sprache im JSON auf einen festen Wert setzen oder die Sprache aus der Ansicht entfernen – die dann ebenfalls aus allen Beziehungen entfernt werden muss, was wahrscheinlich sehr aufwendig ist. Texttabellen, die im BW sprachabhängig sind (z. B. die Texte des Hierarchieverzeichnisses), verfügen auf beiden Seiten über einen Sprachschlüssel.

Hierarchien

Der Export von Hierarchien mit dem DPG ist seit Juni 2026 möglich. (SAP Help: Data Product Generator – Hierarchies). Wir haben Hierarchien für 0COMP_CODE mit dem DPG analog der SAP Hilfe exportiert (Wichtig: Quelltyp auf “Snapshot” umstellen). Der DPG erzeugt vier Tabellen pro Infoobjekt, die 1:1 den Views entsprechen, die der QTG erzeugt. Aber leider unterscheiden sich einige Felder in der Länge. Daher ist hier etwas mehr als das simple zuordnen der Korrekten Felder nötig, es muss vorher die Feldlänge und die abweichende Logik angepasst werden. Daher haben wir nicht weiter versucht die Zuordnung bei den Hierarchien vorzunehmen. Vielleicht wird SAP ja die Logik beider Tools abstimmen, so dass eine Zuordnung mit einem vertretbaren Aufwand möglich wird.

Wo wir helfen können 

Das manuelle Zuordnen der Faktenansicht und der Dimensionen ist möglich. Sobald Ihr Modell jedoch eine gewisse Komplexität aufweist, ist die manuelle Korrektur von Namen und Tabellen sehr zeitaufwendig und birgt das Risiko von Tippfehlern. Wir haben daher unsere KI-Agenten darauf trainiert, diese Arbeit zu übernehmen. Alle in diesem Blog gezeigten manuellen Schritte wurden parallel von uns und vom Agenten ausgeführt. Darüber hinaus überprüft der Agent das Ergebnis und stellt besser als wir selbst fest, ob die Ergebnisdaten den Erwartungen entsprechen.