Migration auf SAP BW/4
Es gibt drei verschiedene Möglichkeiten, um von einem SAP BW System bis BW 7.5 (Any DB) auf ein BW/4Hana zu migrieren. In diesem Abschnitt wird kurz auf die drei Migrationswege eingegangen, zu denen die SAP rät. Ein vierter Weg ist der Greenfield Ansatz; hierbei werden jedoch keine bestehenden Objekte mit Hilfe einer Transfer Tool Box migriert.
In-Place Conversion
Eine notwendige Voraussetzung zur In-Place Conversion ist, dass es sich bei dem Altsystem um ein BW 7.5 on HANA handelt. Dies bedeutet, dass eine separate Installation eines neuen SAP BW Systems nicht notwendig ist – es müssen jedoch alle Objekte in BW/4 HANA kompatible Objekte umgewandelt werden. Ein Beispiel hierfür ist die Migration eines „DataStore-Object“ (DSO) zu einem „Advanced DataStore-Object“ (ADSO) oder die eines „MultiProviders“ zu einem „CompositeProvider“.
Ein Vorteil dieser Methode ist, dass keine Objekte zwischen „verschiedenen SAP BW Systemen“ transportiert werden müssen, sondern alles in einem „Entwicklungsstrang“ (Entwicklungssystem -> (Testsystem) -> Produktivsystem) bleibt.
Remote Conversion
Im Gegensatz zur „In-Place Conversion“ wird ein neues BW/4Hana System neben dem bestehenden SAP BW System installiert. Somit ist es notwendig zwei SAP BW Systeme parallel zu betreiben. Hierfür muss das zu migrierende System mindestens ein SAP BW 7.3 sein. Dies bedeutet, dass alle älteren Datenflüsse aus dem Release 3.5 zunächst auf den Systemstand 7.3 migriert werden müssen, bevor diese per Migration Tool Box (Migration Cockpit) in BW/4Hana kompatible Objekte migriert und in das parallel installierte BW/4Hana transportiert werden können. Bei diesem Migrationsansatz werden hinzukommend auch die Daten aus den zu migrierenden Datenflüssen migriert.
Ein Vorteil dieser Methode ist, dass auch ältere SAP BW Systeme (ab Release 7.3) migriert werden können. Bei dieser Methode ist es möglich, dass nicht alle Datenflüsse migriert werden, sodass obsolete Datenflüsse „aussortiert“ werden können, indem sie nicht migriert werden.
Shell Conversion
Die Shell Conversion unterscheidet sich im Vorgehen nicht von der Remote Conversion. Der Unterschied hierbei ist jedoch, dass weder Stamm- noch Bewegungsdaten in das BW/4Hana migriert werden.
Dies führt zu einer schnelleren Conversion, bei der es möglich ist, auch erst im Nachgang zu entscheiden, ob Daten aus dem Quellsystem bzw. aus dem migrierten Quellsystem geladen werden sollen. Über dieses Vorgehen wird im weiteren Verlauf dieses Blogs aus einem Kundenprojekt berichtet.
Ausgangssituation
Das zu migrierende System war ein SAP BW 7.5 on HANA. Die Systemarchitektur sah wie folgt aus:
Vor dem Projektstart wurden bereits alle 3.5 Datenflüsse migriert.
Zu Beginn des Projektes wurden dann die zentralen Stammdatenobjekte, wie zum Beispiel Kunde und Material selektiert, um mit diesen zentralen Objekten und deren darunterliegenden Datenflüssen die Migration zu starten. Parallel dazu wurde das zu migrierende System in einzelne Applikationen aufgeteilt. Somit wurde sichergestellt, dass es nicht einen großen Go-Live gibt.
Vorgehen
Zu Beginn jeder Migration einer Applikation wurde deren Objekte im Entwicklungssystems des BW 7.5 auf einen Transportauftrag geschrieben. Damit einhergehend wurde dem dazugehörigen Fachbereich untersagt, Änderungen vorzunehmen (Frozen Zone). Darauf folgt, dass der Datenfluss (DataSource, Transformation(en), DataStoreObjekt(e), MultiProvider, CompositeProvider) im Migrations Cockpit gesammelt wird.
Hierbei ist wichtig zu erwähnen, dass ABAP-Objekte nur im ersten „Level“ gesammelt werden. Das ABAP Coding aus den Routinen der Transformationen wird übernommen. Der Inhalt der Programme und Funktionsbausteine, welche in der Transformation genutzt werden müssen, werden separat gesammelt und in das BW/4Hana transportiert. Dies geschieht nicht mit dem Migrationstool.
Eine weitere Besonderheit sind Query Elemente, die nicht über deren Querynamen migriert werden können. Für diese Objekte muss zunächst aus der Tabelle “RSZELTDIR“ mit dem Querynamen in dem Feld “MAPNAME“ gesucht werden und anschließend die UID in das Migrationstool übernommen werden. Man sucht nicht über die Objektsuche, sondern muss die Query manuell hinzufügen. Hierzu gibt es einen Button im ersten Schritt „Collect Scope for Transfer“ im Migration Tool.
Falls in dem Datenfluss Datenbankobjekte wie Calculation Views genutzt werden, müssen diese datenbankseitig ex- und importiert werden. Dies kann nicht per Migrations Cockpit gemacht werden.
Nacharbeiten im BW/4Hana
Sind alle Objekte migriert, sollte vor dem Transport im BW/4 darauf geachtet werden, dass das Quellsystem der Objekte noch umgestellt unddas Reparaturflag gelöscht wird. Anschließend kann im BW/4Hana die Applikation transportiert werden.
Datenversorgung
Wie im ersten Abschnitt beschrieben, werden bei der Shell Conversion keine Daten migriert. Wenn man die historischen Daten aus dem Legacy-System benötigt, ist es möglich, dieses als Quellsystem hinzuzufügen und die Daten daraus zu laden. Falls keine historischen Daten aus dem Legacy System benötigt werden, können diese auch direkt aus den Quellsystemen geladen werden. Beim initialen Laden der Stammdatenobjekte bietet sich bei der Shell Migration die Möglichkeit, die Datenqualität im BW/4Hana zu erhöhen.
Fazit
Es ist möglich alle BW spezifischen Objekte ab Release 7.3 mit dem Migrationscockpit zu migrieren. Mit einem guten Projektplan und steigender Erfahrung nach den ersten Datenflüssen ist dies ohne weitere Herausforderungen leicht durchführbar. Werden bereits datenbankspezifische Objekte genutzt, so deckt das Migrationstool dies nicht ab. Jedoch kann die Ex- und Importfunktion im Hana Studio diese Aufgabe übernehmen. Interessant wird zu sehen sein, wie der Schritt von einem BW/4Hana in die Data Warehouse Cloud funktionieren wird.
