Für die meisten Anwender eines BW, die in die SAC-Planung einsteigen wollen, wird sich die Frage stellen, wie Daten aus dem BW in die SAC und Plandaten aus der SAC in das BW geladen werden können. Soll die SAC-Einführung nicht mit einem großen „Big Bang“ erfolgen, müssen Daten zwischen der alten und der neuen Lösung transferiert werden.
Ein typisches Szenario für die schrittweise Einführung der SAC besteht darin, sich zunächst auf die Umsetzung verschiedener Planungsszenarien zu konzentrieren und das Reporting weiterhin im BW zu belassen. Dafür müssen die Planzahlen in das BW zurückgeschrieben werden.
Wir haben uns angeschaut, wie gut dies funktioniert und wo Tücken liegen. Die gute Nachricht: es funktioniert. Aber wie immer gibt es ein paar „kleine“ Dinge zu beachten, die diesen Weg in bestimmten Szenarien schwieriger gestalten.
In diesem Blog beschreiben wir unsere Erfahrungen mit dem Übertrag von in der SAC erfassten Planzahlen zurück in das BW.
Überblick
Pro
-
- Im BW kann mit einem BADI eine individuelle Umsetzungslogik implementiert werden
- Die Retraktion kann regelmäig geplant werden
- Für das Jahr 2022 ist ein Pull aus dem BW heraus geplant
- Die Schnittstelle ist ausreichend performant, es konnten 300.000 Datensätze in wenigen Minuten übertragen werden
- Aus dem neuen Datenmodell können auch mehrere Kennzahlen übertragen werden
- Datensätze im Ziel-aDSO werden anhand der Löschkriterien gelöscht
Einschränkungen
-
- Geklammerte Merkmale müssen im BADI sauber aufgebaut werden, da die SAC diese meistens nicht unmittelbar liefert
- Das nachträgliche Anpassen eines Filters oder eines Mappings von einem ODATA – Export-Job ist nicht möglich. Dieser muss jedes mal neu angelegt werden
- Der Export kann nur von einem Administrator gestartet werden. Ein Trigger oder eine Verknüpfung mit einem Knopf im Planungslayout, beispielsweise nach Änderung von Planzahlen, sind nicht möglich
- Kleiner Anpassungen sind bei dem Merkmal für die Version nötig, falls dies ein Schlüsselfeld im Ziel-aDSO ist. (Das führende „public.“ muss bei öffentlichen Versionen entfernt werden)
- Ein Delta-Export muss „manuell“ entwickelt werden. gelöschte Datensätze können aber mit der Exportmethode „Löschen und ersetzen“ anhand von ausgewählten Merkmalen gelöscht werden (s. unten und Hinweis 2998439 – Keine Löschung mancher Zieldaten)
- Das Mapping und die Löschkriterien müssen beim Anlegen sauber notiert werden. Diese kann man anschließend nicht mehr einsehen
- Der Export-Job wird sofort beim Anlegen ausgeführt, man kann die Entwicklung nicht vom ersten Test beziehungsweise Übertrag trennen
Zu beachten
-
- Der Datenexport wird beim Anlegen des Export-Jobs sofort gestartet, sonst haben wir es nicht geschafft, den Job anzulegen. Dennoch erscheint der Job danach in der Übersicht als nicht ausgeführt
- Erfahrungen mit der ODATA-Schnittstelle sind hilfreich beim Einrichten sowie bei der Fehlersuche
- Als Testszenario für den erfolgreichen Export sollte man für ein klassisches Datenmodell einen Abgleichbericht im Excel mit Zugriff auf die Daten im BW und der SAC erstellen. Für das neue Datenmodell funktioniert dies leider nicht, dort muss man die Daten in die SAC zurückladen, um einen Abgleich durchzuführen
Einrichten eines Export-Jobs
Auf der BW – Seite ist ein O-Data Service anzulegen (s. Blog https://www.zpartner.eu/sap-analytics-cloud-sac-planning-write-back-to-sap-bw-with-odata/).
Das Einrichten von Export-Jobs auf der SAC-Seite geht, wie üblich abhängig von der Anzahl der beteiligten Merkmale, schnell. Aber Achtung, hier müssen vorab schon alle Filter festgelegt werden! Soll ein anderes Datenset exportiert werden, muss ein neuer Export-Job eingerichtet werden. Hier muss mit Fehlern gerechnet werden. Ist ein Merkmal falsch zugeordnet, so muss der Prozess von Beginn an durchgeführt werden.
Diese beiden Einschränkungen gestalten den Test sowie die Korrektur der Verbindung herausfordernd. Entweder man arbeitet ohne Filter und exportiert immer alle Daten. Folglich wäre keine Anpassung beziehungsweise Neuanlage des Export–Jobs nötig. Andernfalls müsste ein neuer Test nach jeder Anpassung des Filters durchgeführt werden.
Abbildung 1: Zuordnung der Merkmale zu den Zieldimensionen
Wie bereits erwähnt, kann man sich von einem angelegten Export-Job nicht mehr die Filtereinstellungen und die Zuordnungen anzeigen lassen.
Aktivitäten auf BW – Seite
In einigen Fällen müssen die importierten Daten auf der BW-Seite angepasst werden. Dafür kann der Badi RSBPC_ODATA_EXPORT im Erweiterungsspot RSBPC_ODATA verwendet werden. Bei uns war dies in folgenden Fällen nötig:
-
- Geklammerte Merkmale – Hier muss der Klammervater ergänzt werden, dies erkennt die Schnittstelle nicht automatisch
- Zeitmerkmale – Hier efolgt keine automatische Ableitung, sollten unterschiedliche Zeitmerkmale im Ziel-aDSO vorkommen (z.B 0CALYEAR neben 0CALMONTH)
Eventuell ist das a-DSO entsprechend anzulegen, um dies zu vermeiden und stattdessen die Navigationsattribute von 0CALMONTH zu verwenden - Version – wird aus einer öffentlichen Version exportiert, was vermutlich meistens der Fall sein dürfte. Dann ist dieser Text „public.“ vorangestellt und muss im BW entfernt werden, damit es nicht zu einem Fehler kommt
- Die geschäftsspezifischen Umsetzungen sind hier erfolgt
- Da berechnete Kennzahlen nicht exportiert werden können, sind diese hier berechnet worden
Delta – Verfahren
Bei der Erstellung des Export–Jobs kann man festlegen, nach welchem Merkmal die Daten im Ziel-aDSO vorab gelöscht werden. Damit kann sichergestellt werden, dass in der SAC gelöschten Einträge auch im Ziel-aDSO gelöscht werden, wenn die Daten mehrmals übertragen werden. Hierfür ist ein sauberes Konzept nötig.
Abbildung 2: Auswahl der Merkmale für die Löschselektion
Möchte man ein echtes Delta-Verfahren sowie nur die geänderten Daten übertragen, muss man dies selbst über ein geeignetes Datenmodell ermöglichen. Eine Möglichkeit besteht darin, vorab ein künstliches Delta zu erzeugen. Dies funktioniert, indem man zwei zusätzliche Modelle erstellt. In dem ersten speichert man den Stand nach der letzten Übertragung (After Image), in dem zweiten (Delta Daten) die Differenz zwischen dem „After Image“ und dem aktuellen Stand. Anschließend muss sichergestellt werden, dass die Delta-Daten sauber exportiert wurden, bevor ein neues After Image erzeugt wird.
Trigger des Exports
Momentan kann der Export nur von einem User mit Administrator-Berechtigungen erfolgen. Dieser kann den Job sofort ausführen, einmalig oder periodisch einplanen. Bei einer periodischen Einplanung sind keine weiteren Einschränkungen oder Ausnahmen vorgesehen, dieser erfolgt 24/7. Damit ist momentan für die zeitnahe Übertragung der Daten maximal eine stündliche Wiederholung möglich (s. Screenshot). Da in diesem Fall immer noch keine automatische Delta–Übertragung erfolgt, wird das System herausgefordert.
Den Export kann man nicht über einen Button auf der SAC-Oberfläche starten. Ein Pull aus dem BW ist erst für 2022 angekündigt.
Abbildung 3: Einplanungsmöglichkeiten eines Export-Jobs
Test & Abgleich der Daten
Da für jede Filteranpassung oder Korrektur in der Export-Schnittstelle diese komplett neu angelegt werden muss, sollte man sich von Beginn an überlegen, wie der erfolgreiche Export schnell geprüft werden kann. Entweder man sieht unmittelbar den Import in die SAC vor und macht dort einen Vergleich oder man verwendet das AfO Plugin und vergleicht die Datentöpfe auf geeigneter aggregierter Ebene im Excel. Aber Achtung: dies erfolgt nur dann, wenn man das klassische SAC-Modell verwendet, da weder AO noch das SAC-Plugin für Excel aktuell das neue Modell unterstützen:
Hinweis 3085993 – Troubleshooting guide for SAC, add-in for MS Office
Tipps
An folgenden Punkten mussten wir Einstellungen über die Punkte aus dem Blog von ZPARTNER (s. unten) anpassen, damit der Export funktionierte:
-
- In der Transaktion /IWFND/MAINT_SERVICE ist sicher zu stellen, dass ein Systemalias für RSBPC_ODATA_EXPORT_SRV vorhanden ist (s. Hinweis 2527329)
- In der O-Data-Verbindung muss die URL mit HTTPS angegeben werden, wenn im Cloud Connector nur die HTTPS-Verbindung eingerichtet ist. Beim Testen des Services RSBPC_ODATA_EXPORT_SRV wird der Link ohne SSL verwendet
- Die Fehlermeldung „Job während der Ausführung eines Plugins fehlgeschlagen.“ in der SAC verweist auf einen Fehler im SAP-Gateway. Dieses Log kann man mit der TA/IWFND/ERROR_LOG anschauen
Man sollte im Hinterkopf haben, dass der erste Export schon beim Anlegen des Export–Jobs gestartet wird. Die Anzahl der Übertragenen Sätze wird angezeigt, aber dennoch wird der neu angelegte Export-Job als noch nicht ausgeführt markiert.
Abbildung 4: Meldung der ersten erfolgreichen Übertragung nach Anlage des Jobs, der dennoch als „Noch nicht ausgeführt“ markiert wird
Unserer Tests wurden mit folgendem Systemstand durchgeführt:
SAC 2021.14.10 (Client)
SAC 2021.14.7 (Server)
BW/4 SAP_BASIS 753 0005
BW/4 SAP_GWFND 753 0005
SAP – Hinweise
SAP beschreibt diese Punkte teilweise in seinen Hinweisen:
-
- 2838883 – SAC-BW-Writeback – Teil 1
- 2847623 – SAC-BW-Writeback – Teil 2
- 2942754 – SAP-Analyitcs-Cloud-Writeback in BW 750 -> min. SP 18 nötig!
- 2913078 – Unterstützung der Option „Löschen und ersetzen“
- 3026199 – Tips and Tricks of Analyzing BW Data Integration with SAC issues
- 2998439 – Keine Löschung mancher Zieldaten
- 2936269 – Kein Speicher bei dem Export
- 3011069 – Checkpoints: Export Import between BPC and SAC
- 1797736 – SAP Gateway Troubleshooting Guide
- 2527329 – No System Alias found for Service ‚<service name>‘ and user ‚<current user>‘
Fazit
Erfreulich ist, dass die Schnittstelle funktioniert. Sind die Planzahlen nicht „zeitgleich“ mit der Erfassung in der SAC im BW nötig, dürften die erwähnten Einschränkungen kein großes Problem darstellen. Allerdings sollte das Datenmodell nicht zu viele Merkmale enthalten, da das Mapping öfters durchgeführt werden muss. Diese Grenze ist abhängig von der persönlichen Ausdauer. Will man allerdings die Daten ohne zu großen Zeitverzug direkt nach der Erfassung auch im BW sehen, wird man vermutlich auf eine andere Lösung umschwenken.
Andere Blogs zu diesem Thema
https://blogs.sap.com/2019/10/09/export-data-from-sac-model-to-odata-service/
https://www.zpartner.eu/sap-analytics-cloud-sac-planning-write-back-to-sap-bw-with-odata/
Ansprechpartner
Hendrik Feenders
Senior Consultant
Dr. Ulrich Meseth
Senior Consultant
