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

Alles Rund um SAP®.
4 Beiträge • Seite 1 von 1
4 Beiträge Seite 1 von 1

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

Beitrag von abeape (ForumUser / 2 / 0 / 0 ) »
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?

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


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

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
Moin abeape,

ein paar Kommentare:
  • Schnelle Programmeabläufte zu schreiben ist immer gut - aber "First things first" und das ist bei einer Migration normalerweise die korrekte Funktion der Migrationsbausteine und nicht die Performance. Wenn alles korrekt läuft - erst dann solltest du dir Gedanken über das Herauskitzeln von ein wenig mehr Performance machen
  • Deine Gedanken die Datenvorselektion auf dem Quellsystem zu machen weil die Anwender das dort einfacher selektieren können ist grundsätzlich gut. Allerdings ist meine Erfahrung die, dass die Verbuchung und die Kontrolle auf dem Zielsystem wichtiger ist. Lass die Anwender die Schlüssel im Quellsystem selektieren und dann via RFC ans Zielsystem schicken. Dort können sie (oder du) dann die Daten importieren
  • Das Datensammeln sollte immer auf dem Quellsystem erfolgen. Wenn du das mit BAPIs machst oder andere komplexe Strukturen hast ist ein recht einfacher Weg alle gesammelten Daten in einen String zu serialisieren und diesen ( evtl. gezippt wenn du Angst hast ) dann via RFC-Verbindung auf das Zielsystem zu bringen ( Hinweis: ID-Transformation. Siehe Ennos Beitrag im Tricktresor
  • Wenn du echt migrierst - und bei den Testdaten kann es auch nicht schaden - solltest du eine Tabelle haben die dir sagt wie deine Migration bisher gelaufen ist.
    Folgender Aufbau könnt als Grundgerüst gelten ( Feldnamen ):
    • Mandant,
    • ID Migrationsobjekt (z.b. Debitor, Vertrag, Materialstamm, ... )
    • Schlüssel Migrationsobjekt im Quellsystem,
    • Rohdaten aus Quellsystem als String ( siehe vorheriger Punkt zur Serialisierung,
    • Schlüssel Migrationsobjekt im Zielsystem ( ist gleichzeitig Indikator, dass deine Migration zumindest das Objekt angelegt hat )
    • und ein paar Verwaltungsinfos ( ERDAT, ... , letzte Fehlermeldung beim Buchen, ...)
    • Die Revision wird es dir danken bzw. dich grillen wenn du es nicht machst
  • Wenn du grob so vorgehst kannst du im (schnellen, leeren) Zielsystem deine Verarbeitung gut parallelisieren indem du die o.a. Tabelle abklapperst und die nicht migrierten Objekte anlegst ( evtl. Selektion MigObjekt und MigSchlüssel ). Die Verarbeitung soll falls noch fehlend sich die Stammdaten aus dem Quellsystem via RFC-FuBa geben lassen und in der o.a. Tabelle ablegen und danach verbuchen. Wenn irgend etwas schief läuft (und das wird es am Anfang zu hauf! ) brauchst du dich im Zielsystem um die Datenbeschaffung nicht mehr kümmern müssen da nach dem ersten Aufruf die Stammdaten als Rohdaten fixiert bereit stehen und du wieder und wieder Versuche machen kannst bis es endlich klappt. Dann freust du dich bis die Anwender auf die Idee kommen, dass wenn das alles so einfach ist man ja bei der Migration gleichzeitig eine Datenbereinigung machen könnte und alles umsetzen könnte was man seit Jahren nicht gemacht hat...
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

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

Beitrag von abeape (ForumUser / 2 / 0 / 0 ) »
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

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

Beitrag von deejey (Specialist / 418 / 128 / 45 ) »
Das sind Consulting-Leistungen die du brauchst

Seite 1 von 1

Vergleichbare Themen

0
Antw.
1203
Views
Tools für die Dokumentation ?
von TakerOne » 06.03.2009 09:03 • Verfasst in SAP - Allgemeines
0
Antw.
1859
Views
Tools, um Diagramme zu erstellen?
von markudo » 05.12.2007 08:46 • Verfasst in SAP - Allgemeines
0
Antw.
817
Views
Datenmigration von Bewegungsdaten CML
von ASchreier » 17.05.2006 22:56 • Verfasst in Financials
4
Antw.
3139
Views
Alternative Transport Management Tools
von ralf.wenzel » 19.07.2012 17:25 • Verfasst in ABAP® Core
0
Antw.
1683
Views
Tools für Prüfung und Verwaltung von Berechtigungen in SAP
von kruegerj » 13.06.2017 13:29 • Verfasst in Basis

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 107
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 140