Migrationstools

Eine gute Nachricht zuerst: Die hier im folgenden beschriebenen Migrationstools sind für meine Kunden kostenfrei! Werde ich für Migrationsprojekte beauftragt, sind diese Tools Bestandteil meiner “Werkzeugkiste” und im Tagessatz mit drin!

Die Migrationstools von bit-impulse (von mir) stützen sich im Wesentlichen auf zwei Säulen: iQuery, mit weiteren Komponenten, als sogenanntes ETL-Tool und sub-way für die Verwaltung der Migrationsobjekte.

iQuery – als ETL-Tool

iQuery – Übersicht vorhandener Abfragen

Ein ETL-Tool ist das Herzstück der technischen Datenmigration. Die drei Buchstaben stehen für Extraktion der Daten aus verschiedenen Quellen, Transformation der Daten in das Schema und Format des Zielsystems, sowie dem Laden der Daten in das Zielsystem.

iQuery deckt alle drei erforderlichen Schritte vollständig ab, konzentriert sich in den meisten Projekten aber auf die Schritte Extraktion und Transformation. Das Laden der Daten erfolgt in aller Regel mit dem Import-Tool des Herstellers des Zielsystems.

iQuery extrahiert die Daten ausschließlich aus SQL-fähigen Datenbanken. Wo immer die Daten in anderer Form abgelegt sind, bspw. in Excel, werden solche Daten daher zuerst in eine dem iQuery beiliegende Datenbank übertragen.

Die für die Extraktion benötigten Daten können aus mehreren Quellsystemen stammen. iQuery kann auf diese gleichzeitig in einer einzigen Abfrage zugreifen. Damit können beispielsweise die Kundendaten eines ERP-Systems aus einer SQL-Server Datenbank mit den CRM-Daten aus einer Oracle Datenbank verknüpft werden.

iRepository – Beispiel einer Verknüpfung

Die Entwicklung eines Exports beginnt immer ausgehend von einer primären SQL-Tabelle, bspw. die des Kunden. An zentraler Stelle, in iRepository, erfolgt die Verknüpfung von beispielhaft Kunde > Adresse und Adresse > Länderstamm. Damit sind für ALLE Exporte beginnend mit der primären Tabelle Kunde, auch die Daten zur Adresse und zum Länderstamm abrufbar.

iQuery – Beispiel Spalten-Definition

Für jedes zu exportierendem Objekt, bspw. Stücklisten-Kopf, Stücklisten-Position, Stücklisten-Positions-Text, wird in iQuery eine SQL-Abfrage erstellt. Der Anordnung der Ausgabefelder erfolgt nach den Import-Vorgaben des Herstellers des Zielsystems. Dies gilt auch für die grundsätzliche Formatierung dieser Felder, als Alphafelder, numerische Felder, Datumsfelder, etc., in der jeweils gewünschten Aufbereitung.

Die Verbindung zwischen Quell- und Zielfelder gestaltet sich dann unterschiedlich. Im einfachsten Fall erfolgt eine direkte Zuordnung, wie bspw. beim Kundennamen. Der Länderschlüssel lässt sich vielleicht nicht direkt zuordnen und muss von bisher zweistellig nach dreistellig umgeschlüsselt werden. Um die Übersetzungsregel dem Tool bekannt zu machen wird dort ein Excel als Lookup hinterlegt. Die linke(n) Spalte(n) dieses Excel beinhaltet dann den bisherigen Länderschlüssel, die rechte Spalte den neuen.

iQuery – Beispiel eines (komplexen) Lookups

Lookups bilden ein wichtiges Rückgrat in iQuery und können sehr vielfältig eingesetzt werden. Bspw. gilt es immer wieder Daten „zu erfinden“, welche vom Zielsystem gefordert, so im Quellsystem aber gar nicht vorhanden sind. Solche Daten können auf Basis von Lookups „generiert“ werden. In einem solchen Lookup werden auf Basis des Musters mehrerer Eingabewerte die dazu gewünschten Ausgangswerte definiert.

Mit das schönste an Lookups: Diese Excel können von der Fachabteilung, völlig ohne die Einarbeitung in irgendwelche Tools, gepflegt werden!

Recht zügig lassen sich so 80 bis 90 Prozent der zum Export notwendigen Daten mit iQuery „zusammenklicken“. Für die „hartnäckigeren“ Fälle gibt es mehrere Vorgehensweisen:

Für immer wiederkehrende Aufgabestellungen lässt sich iQuery, sowohl generell als auch projektspezifisch, erweitern. SAP erwartet bspw. Umrechnungen zwischen Mengeneinheiten als Bruch (Zähler und Nenner in zwei Feldern) und nicht, wie sonst eher üblich, als Dezimalzahl. Dazu wurde iQuery um diese, durchaus nicht triviale, Funktionalität erweitert.Wo immer notwendig, kann die Ermittlung eines Wertes auch direkt in SQL-(Fragmente) erfolgen, das sieht dann beispielhaft so aus: CASE WHEN feld < 3 THEN ‘A’ WHEN feld < 7 THEN ‘B’ ELSE ‘C’ END. iQuery fügt dann diese individuellen SQL-Fragmente in die generierte SQL-Anweisung mit ein.

iQuery – Beispiel einer komplizierten Abfrage

Selbst dort wo es in Einzelfällen richtig kompliziert wird, bleibt iQuery bei der Stange. Lange und unübersichtliche SQL-Ausdrücke können in sogenannte Literale zerlegt werden. Auf diese Literale kann dann, ähnlich wie auf Textcontainer, zugegriffen werden. Literale können wiederum ein oder mehrere Literale enthalten. Das alles vereinfacht die in Einzelfällen nicht immer vermeidbare Komplexität.

iQuery – Beispiel Auswahl-Definition

Meist sind nicht alle Datensätze aus dem Quellsystem zu übernehmen. Abgrenzungen können bspw. über den momentanen Status oder den Zeitstempel in den Datensätzen vorgenommen werden. Solche Auswahlen lassen sich in iQuery recht einfach „zusammenklicken“.

Aber auch komplexe Fälle lassen sich abbilden. Eine Stückliste soll bspw. nur dann übernommen werden, wenn ALLE Stücklisten-Positionen einen gewissen Mindest-Status gesetzt haben. Auch hier kann die Abfrage um ein SQL-Schnipsel wie EXISTS SELECT * FROM table … WHERE … AND STATUS >= 10 erweitert werden.

Die mit iQuery erstellten Exporte können vor einem Import ins Zielsystem erst einmal „auf Sicht“ validiert werden. Typischerweise wird dazu der Export nach Excel konvertiert und dieses Excel dann zentral abgelegt oder direkt verteilt. Hier unterstützt iQuery das aktuelle Excel-XLSX-Format, welches bis zu 1,4 Millionen Zeilen in einem Excel-Dokument erlaubt.

Letztlich erfolgt der Export in das gewünschte, technische Zielformat, für den vom Hersteller vorbereiteten Import. Hier gibt es in iQuery verschiedenste Ausgabe-Adapter, bspw. für CSV in allen Variationen, Excel, XML-Daten und auch direkt in Datenbank-Tabellen.

sub-way – als Verwaltungs-Tool

Verwaltung und Dokumentation – beide Begriffe stehen auf der Beliebtheitsskala bei Migrationen eher am unteren Ende denn an einem populären Spitzenplatz. sub-way enthält daher manches an Funktionalität um seine Anwendung unmittelbar „zu belohnen“.

sub-way – Beispiel einer Migrations-Dokumentation

Die Migrations-Objekte, bspw. Kunde und Adresse müssen ja letztlich in irgendeiner Form beschrieben werden. Minimum sind die technischen Eigenschaften der Zielfelder (Datentyp, Länge, …) und die Migrations-Regel zum jeweiligen Zielfeld.

Erfolgt diese Beschreibung nach einer von sub-way vorgegebenen Vorlage in Excel, können Dokumentation und Tool ineinandergreifen. Sind mindestens die technischen Eigenschaften der Felder des Zielsystems sauber beschrieben, kann das Tool die SQL-Abfragen des Exports in ihrem Grundgerüst automatisch erstellen und so einiges an Tipparbeit ersparen. Zudem hilft es, Fehler bei der sonst manuellen Übertragung zu vermeiden.

sub-way – Beispiel eines Versionsabgleichs

sub-way erlaubt eine Versionierung der Schnittstellen-Objekte. Sehr nützlich ist diese Möglichkeit für den typischerweise iterativen Prozess bei der Definition der Migrationsregeln. Die Regeln werden definiert, im Tool umgesetzt, ein Export erfolgt. Nach der Validierung des Exports auf Sicht oder nach einem testweisen Import in Zielsystem, werden Unzulänglichkeiten in den Regeln erkannt und diese angepasst. sub-way kann die Unterschiede einer neueren Version erkennen und für die Anpassung der Exporte, die Differenzen als „Aktivitätenliste“ auf Feldebene bereitstellen.

sub-way – Beispiel eines Verwendungsnachweises

In aller Regel müssen Migrationen dokumentiert werden; bspw. verlangt der Wirtschaftsprüfer eine transparente Sicht auf die Übertragung der Daten vom alten ins neue ERP.

Mit sub-way kann die Dokumentation zur Migration auf Basis der bestehenden Exporte in iQuery jederzeit aktuell erzeugt werden. In der Dokumentation ist dann ersichtlich, welche Daten aus dem Quellsystem, mit welchen Übersetzungsregeln, für das Zielsystem exportiert wurden.

Zudem lässt sich ein Verwendungsnachweis zu den bestehenden Exportabfragen erstellen. Welche Tabellen und Felder des Quellsystems oder welche Felder des Zielsystems kamen in welchen Abfragen zum Einsatz? Wo wurden welche Lookups verwendet?

Sammelsurium weiterer Infos

Die Migrations-Tools von bit-impulse sind Java-basierend und laufen damit auf praktisch jeder Plattform. Der für die Browser-Anwendungen notwendige Applikations-/Webserver kann entweder auf einem bestehenden Server „mitlaufen“ oder es wird ein eigener Server dafür aufgesetzt. Die Anforderungen an die System-Ressourcen sind recht moderat.

Für den eigentlichen Export müssen in aller Regel mehrere Abfragen in bestimmter Reihenfolge durchgeführt werden. Hierzu werden auf dem Server CMD-Dateien angelegt in der die einzelnen Aktivitäten über iQuery-Kommandos aufgerufen werden. Per Kommando-Parameter lassen sich hier detailliert die gewünschten Eigenschaften vorgeben. Für den Export, bspw. in das Excel-CSV-Format, sieht das dann so aus:

DBToCSV [jdbc:]library/table | [jdbc:]iquery csvfile [key:value] [charset] [semicolon-delimited|comma-delimited|tab-delimited] [decimal-comma|decimal-point] [no-quotes] [no-header] [crlf|lf|cr] [supdate|sdelete] [debug]

Dort wo iQuery als ETL-Tool eingesetzt wird, wird es in aller Regel auch als Report-Tool für das Migrations-Projekt verwendet. Mit iQuery lassen sich die Quelldaten für die Erstellung der Transformationsregeln erst einmal nach vielfältigen Kriterien sichten. Vielleicht sind Daten im Vorfeld im Quellsystem anzupassen – hierzu können mit iQuery die notwendigen Todo-Listen erstellt werden.

Die Migrations-Tools von bit-impulse können in Projekten unterschiedlichster Größenordnung eingesetzt werden. Es gab kleinste Projekte auf denen die Software einfach auf dem Laptop des Beraters lief, bis hin zu großen Projekten im großen Team mit bis zu 373 Abfragen und 102 Lookups.

Diese Informationen gibt es auch zum Herunterladen als PDF
This information is also available as PDF in English language for download