Manuelle Aufwandstreiber während einer SAP BW/4HANA Inplace Migration

Manuelle Aufwandstreiber während einer SAP BW/4HANA Inplace Migration

PRODATO ist Ihr verlässlicher Partner für SAP BW/4HANA. In diesem Blogbeitrag beleuchten wir die Faktoren, die den manuellen Aufwand bei der Inplace-Migration erhöhen.

Die SAP BW/4HANA Inplace Migration wird größtenteils toolgestützt mithilfe des Transfer Cockpits (Transaktion RSB4HCONV) durchgeführt. Ein kleinerer Teil der Objekte erfordert jedoch ein größeres manuelles Eingreifen der Entwickler.

Die manuellen Aufwandstreiber hängen maßgeblich von der individuellen Systemlandschaft ab und können aufgrund der Menge der betroffenen Objekte erheblichen Aufwand während der Migration verursachen. Im Blogbeitrag wird auf InfoSets, virtuelle Provider und der Customer Exit der Eingabevariablen eingegangen, da hier Redesign in den jeweiligen Bereichen erfolgen muss.

Migration InfoSets

Bei der Inplace Migration in SAP BW/4HANA gibt es bestimmte Aspekte zu berücksichtigen, insbesondere im Zusammenhang mit InfoSets:

• Nicht alle InfoSets können vollständig über das Transfer Cockpit überführt werden, was zur manuellen Neuerstellung und dem Einsatz eines Composite Providers führt. Die Durchführbarkeit hängt von den Einstellungen des InfoSets ab (siehe SAP NOTE https://me.sap.com/notes/2444912).
• Beim manuellen Neuaufbau liegt der Hauptaufwand im Mapping der bisherigen F-Felder auf die entsprechenden Merkmale. Zum Beispiel steht das Feld F10 für das Merkmal 0COUNTRY. Das Merkmal 0COUNTRY kann dabei aus mehreren Part Providern stammen. Das führt dazu, dass in einer Query aufwendig nachverfolgt werden muss, aus welchem Provider das in der Query verwendete Merkmal stammt.
• Wenn die Migration über das Tool erfolgt, werden die Feldnamen zu einem systemweit eindeutigen kryptischen technischen Namen geändert, z.B. wird F2 zu 4X-F2, wobei X den technischen Namen des alten InfoSets repräsentiert.
  

Unabhängig davon, ob die Migration manuell oder über das Tool durchgeführt wird, sind nach Abschluss Anpassungen an Arbeitsmappen oder Queries erforderlich, da diese nach der Migration nicht mehr funktionieren.

Virtuelle Provider mit Funktionsbaustein

Virtuelle Provider stellen ebenfalls einen manuellen Aufwandstreiber dar, da sie nicht direkt mithilfe eines Tools durch einen anderen InfoProvider ersetzt werden können. In diesem Fall ist ein manuelles Redesign erforderlich, welches von den zugrundeliegenden Objekten des virtuellen Providers abhängig ist.

In unserem Fall betrachten wir einen virtuellen Provider, der auf einem Funktionsbaustein (FUBA) im ERP basiert. Als InfoProvider wird dabei die Nutzung eines Open ODS Views empfohlen.

Dieser erfordert zusätzlich das Anlegen einer CDS-View im ERP, welcher mit der Logik des FUBAs versorgt werden muss. Die Logik kann dabei nicht 1:1 übernommen werden und muss daher auf die CDS-View-Logik umgebaut werden. Des Weiteren ist es nötig, auf der BW-Seite eine DataSource anzulegen, auf die der ODS-View zugreifen kann. Der Zugriff erfolgt entweder über einen ADSO oder über eine Transformation in eine InfoSource.

Diese beiden Optionen würden wie folgt als Datenfluss aussehen:

Das anschließende Nachbauen und Vergleichen der betroffenen Queries ist ebenfalls erforderlich und dient als Indikator dafür, ob der virtuelle Provider richtig abgelöst wurde oder ob gegebenenfalls die Logik weiter angepasst werden muss. Das kann je nach Anzahl der betroffenen Queries viel Aufwand mit sich bringen.

Customer Exit Variablen (CMOD)

Ein weiterer Faktor, der manuellen Arbeitsaufwand verursacht, ist die Umstellung der Customer Exit Variablen. Diese Variablen dienen dazu, die Funktionalität von Variablen in Queries durch kundenspezifische Logik zu erweitern. Sie ermöglichen die dynamische Ableitung von Variablenwerten während der Ausführung einer Query. Vor der Einführung von SAP BW/4HANA wurde für die Implementierung von Customer Exits die Transaktion CMOD (Customer Modification) genutzt. Hierbei wurde die Logik üblicherweise in einem FUBA für die jeweiligen Variablen hinterlegt.

Allerdings steht die Transaktion CMOD unter SAP BW/4HANA nicht mehr zur Verfügung. Daher müssen Customer Exits in SAP BW/4HANA mithilfe von Erweiterungsspots (BADI-Transaktion SE18) umgesetzt werden.

SAP empfiehlt dafür, alle Customer Exit Variablen manuell im Erweiterungsspot RSROA_VARIABLES_EXIT anzulegen und die Logik direkt in einem BADI zu implementieren.

Da dies ein sehr aufwändiges Unterfangen sein kann, besteht ebenfalls die Möglichkeit, die Logik aus dem alten FUBA zu übernehmen und diesen durch einen neuen FUBA zu ersetzen. Hierfür implementiert man einen neuen BADI in der SE18 und kann dabei den neuen FUBA als Implementierung hinterlegen.

Fazit

In diesem Blogbeitrag wurden anhand von drei Beispielen mögliche manuelle Aufwandstreiber während einer SAP BW/4HANA Inplace Migration erläutert.
InfoSets mit speziellen Einstellungen, wie ein Join auf Stammdatentabellen mit Stichtagsableitungen können im Nachgang zu Performanceproblemen führen, da die Composite Provider mit den Standardeinstellungen nicht die gleichen Funktionalitäten bieten. Ebenfalls erfordert die Migration von virtuellen Providern Expertenwissen in der Datenmodellierung in BW/4HANA, da diese durch neue Technologien ersetzt werden müssen.

Haben Sie viele der genannten Objekte in Ihrem System? PRODATO steht Ihnen als zuverlässiger SAP-Partner stets zur Verfügung. Wir bieten Ihnen eine umfassende Analyse Ihres BW-Systems zur Vorbereitung auf eine Migration zu BW/4HANA oder Datasphere an.

Befinden Sie sich bereits inmitten einer Migration und benötigen Expertenhilfe für spezielle Objekte? Kontaktieren Sie uns gerne!