Konzeption eines Tools für Migration von Stamm- und Bewegungsdaten

Konzeption eines Tools für Migration von Stamm- und Bewegungsdaten

Hallo zusammen,

ich habe die Aufgabe bekommen, eine Art Testdatengenerator für bestimmte Stamm- und Bewegungsdaten (der Einfachheit halber erstmal nur das Objekt Vertrag ) zu bauen.
Dabei sollen Verträge von einem ERP-System (System A) selektiert und diese dann in ein S/4HANA System (System B) migriert werden - das Datenmodell hat sich mit S/4HANA etwas verändert. Auch wenn das Tool zunächst nur Testdaten bereitstellen soll, kommt es später auch für eine richtige Migration in Frage...

Vorab zu erwähnen: Die Idee mit SAP Migration Cockpit + eigenem Migrationsobjekt habe ich erstmal verworfen, weil die zu erstellende Lösung erstmal nur für die Bereitstellung von Testdaten im neuen System verwendet werden soll. Da zudem der potenzielle Anwenderkreis nicht aus Migrationsexperten besteht, sondern aus mehreren (fachlichen) Anwendern, halte ich die Lösung über ein eigenes Programm für sinnvoller, da ich dieses für den Anwender einfacher und intuitiver stricken kann.

Auch eine Lösung, wobei die Daten in ein File geschrieben und dann im Zielsystem eingelesen werden, finde ich für den regelmäßigen Gebrauch umständlich. Also bleibt aus meiner Sicht nur die direkte Verbindung zwischen den Systemen (per RFC).

Nun mache ich mir Gedanken, wie ich die Verarbeitung/Last und damit auch die Komponenten der zu entwickelnden Lösung zwischen den beiden beteiligten Systemen aufteilen sollte. Dabei steht natürlich die Performance im Vordergrund, weil ich davon ausgehe, dass der Datentransport zwischen Systemen dahingehend belastend sein wird.

Hier meine Überlegungen:
Das zu erstellende Programm wird auf System A erstellt, weil dort die (durch den Anwender) auszuwählenden und zu migrierenden Daten existieren. Würde ich stattdessen aus System B kommen, müsste für die Selektion der Daten durch den Anwender (Suchhilfeanbindung), eine RFC-Verbindung nach System A aufgebaut werden und die ausgewählten Daten (IDs) müssten dann zurück um in die Selektionsoption übernommen zu werden, wobei es eventuell zu Verzögerungen kommen könnte. Außerdem müssten diese IDs nochmal nach dem Start der Ausführung für den lesenden BAPI-Aufruf auf System A nochmal dahin geschickt werden.
Für die Verbuchung der Daten in System B habe ich keinen massenweise verbuchenden BAPI. Würde ich also aus System A die Datensätze einzeln nach System B senden, müsste für jeden Datensatz eine Übertragung per RFC aufgebaut werden. Deshalb habe ich mir an dieser Stelle überlegt, in System B einen RFC-fähigen FB anzulegen, der die Daten massenweise entgegennimmt und in einem Loop den bereits erwähnten BAPI für jeden Datensatz aufruft und diese damit verbucht. Dadurch wird die RFC-Verbindung nur einmal aufgebaut, wovon ich mir Performance-Vorteile erhoffe (auf der anderen Seite eine größere Datenmenge auf einmal transportiert). Der besagte BAPI hat aber auch mehrere Tabellen als Parameter. Wie kann ich mehrere Datensätze übergeben, wobei jeder Datensatz in sich nochmal mehrere Tabellen enthät? Mir fällt aktuell nur die Kapselung der Daten in Klassen/Objekte ein. Die Parametertabellen können (analog zu den BAPI-Parametern) in Attributen untergebracht werden und alle Datensätze (dann Instanzen) werden nochmal in einer internen Tabelle (als Objektreferenzen) gesammelt und in dieser Form dem o.g. RFC-Baustein in System B übergeben. Auf dieser Seite müsste ich dann natürlich auch die entsprechende(n) Klasse(n) bereistellen. Dann können die Daten (Objekte) im Schleifendurchlauf ausgelesen und dem verbuchenden BAPI übergeben werden. Stellt sich an dieser Stelle auch die Frage, ob ich Objekte in dieser Form an ein anderes System reichen kann...

Ich habe noch keinen Zugang zu den Systemen, deswegen beschränken sich meine bisherigen Ansätze nur auf das Konzeptionelle. Bitte schreibt mir Eure Meinung zu dem o.g. Vorgehen und ich freue mich über jeden Vorschlag.

Vielen Dank im Voraus!

Viele Grüße
abeape

Edit: Es war nicht meine Absicht, diesen Beitrag im ABAP-Objects Bereich zu platzieren. Ich habe auch keine Möglichkeit gefunden, wie ich den Beitrag umsiedeln oder löschen kann. Vielleicht kann mir ein Administrator behilflich sein?

Re: Konzeption eines Tools für Migration von Stamm- und Bewegungsdaten

Hallo Stefan,

vielen Dank für Deine schnelle Rückmeldung und Deine detaillierten Antworten. Ich weiß es wirklich zu schätzen und werde Deine Ratschläge beherzigen. Ich hatte frei, deswegen melde ich mich erst jetzt...

Momentan hat sich aber folgendes Problem aufgetan:
Das bereits angesprochene Objekt "Vertrag" hat abhängige Entitäten, die nicht wie der Vertrag selbst, einfach per RFC-Baustein/BAPI angelegt werden können. Das Modul in dem der Vertrag bzw. in der Ausprägung als Darlehen verwaltet wird, zieht seine Daten (Replikation) aus der sogenannten Financial Services Data Model (FSDM). Hintergrund Info: Es gibt für das Banking das sogenannte Financial Services Data Model (FSDM), welches im Bereich der Financial Services betriebswirtschaftliche Inhalte anbietet und technisch auf der SAP HANA Data Management Suite aufsetzt. Kurz gesagt: Die Daten sollen in eine HANA-Umgebung überführt werden, also außerhalb der Netweaver-Umgebung. Das bedeutet, dass der Weg über BAPIs wegfällt.
Ich bin mir bewusst, dass die Fragestellung jetzt in eine ganz andere Richtung geht und hier eigentlich nicht mehr reingehört. Diese muss ich jetzt an anderer Stelle hier im Forum platzieren. Aber vielleicht hast ja Du oder ein anderer Leser eine Idee, ob es trotzdem einen Weg aus der vertrauten ABAP-Umgebung heraus gibt (z.B. ganz banal, einen Baustein, der entsprechendes Interface in der HANA-Umgebung ansprechen kann, ohne das nativ (oder wenig) in der HANA Umgebung programmiert werden muss...

MfG
abeape