Schrittweise Datenimporte sind die beste Migrationsstrategie

Eine der häufigsten Aufgaben bei der Implementierung von IT-Projekten sind Datenimporte. Ganz gleich, ob es um die Migration von Inhalten aus einem alten Web-Content-Management-System oder um den Import von Millionen von Datenpunkten in die neue Kundendatenplattform geht – mit an Sicherheit grenzender Wahrscheinlichkeit muss das Entwicklungsteam vor dem großen Go-Live Migrationen durchführen.

Die Bandbreite ist dabei groß, aber im Grunde geht es immer um dasselbe: das Verschieben von Daten von einem System in ein anderes. In vielen Fällen wird dieser Prozess dadurch erschwert, dass das bestehende System vor der Umstellung auf die neuen Tools bis zur letzten Minute laufen muss. Häufig sind Quelldaten zudem durch Inkonsistenzen verunreinigt oder enthalten sogar falsche Informationen, sodass eine Datenbereinigung oder ein Scrubbing erforderlich sein kann.

Migrationen sind keine exakte Wissenschaft. Im Allgemeinen werden zwei Ansätze unterschieden: „Big Bang“ oder eine schrittweise Durchführung. Bei Big-Bang-Migrationen wird die gesamte Migration zu einem einzigen Zeitpunkt durchgeführt. Bei der schrittweisen Methode, die manchmal auch als „trickle migration“ bezeichnet wird, werden – wie der Name schon sagt – nach und nach Datenpakete aus dem Live-System in das zu entwickelnde System importiert.

Beide Methoden sind durchaus für eine erfolgreiche Umstellung auf ein neues Produktionssystem geeignet. Die schrittweise Methode dürfte jedoch auf der Ziellinie weniger Risiken bergen. Big-Bang-Migrationen könnten im Vorfeld mit Daten-Snapshots simuliert werden. Das funktioniert jedoch häufig nicht, was den Feedbackzyklus zwischen Ausführung und Überprüfung verlängert. Mit schrittweisen Importen hingegen lassen sich einzelne Datenpunkte aus Produktionssystemen schneller abrufen, was die Agilität des gesamten Prozesses erhöht.

Einzeldaten sind keine einsamen Inseln

Per Definition ist ein „System“ eine regelmäßig interagierende oder voneinander abhängige Gruppe von Elementen, die ein einheitliches Ganzes bilden. Unabhängig davon, welche Daten importiert werden – sie werden in der Regel auch von anderen Systemen genutzt. Eine Digital Experience Platform beispielsweise integriert Funktionen wie die Datenspeicherung in einer Datenbank und einem File-Storage-Backend (beides in sich komplexe Systeme) sowie in einer Verwaltungsschnittstelle.

Hier kann eine Menge schief gehen. Nehmen wir an, es geht um den Import von nutzergenerierten Inhalten einer E-Commerce-Site. Jemand hat einen Kommentar zu einem Produkt mit zig Schokoriegel-Emojis hinterlassen (🍫🍫🍫🍫...), der auf dem Quellsystem einwandfrei funktioniert. Aber vielleicht gab es irgendwann ein paar Workarounds und die Schokoriegel erscheinen nicht mehr als „Schokoriegel“, weil das alte System nicht mit dem UTF-8 Zeichensatz arbeitet. Anstelle von 🍫s werden also Platzhalter wie :candybar: in den Quelldaten gespeichert.

Das wäre kein Problem. Unser Importprozess kann damit umgehen, indem er die Platzhalter wieder in echte Schokoriegel umwandelt. Das Inhaltsfeld sieht jetzt so aus, wie ursprünglich beabsichtigt, aber Moment mal ... warum wird das Avatar-Bild des Benutzers nicht angezeigt? Ah … wir haben beschlossen, die Datei auf der Grundlage des Benutzernamens zu speichern und der Dateispeicher, den wir haben, erlaubt es nicht, eine Datei als 氷の男.png zu speichern. Also, schicken wir die Datei einfach durch eine Hash-Funktion und speichern sie als f07db9de.png.

Perfekt! Das Kommentarfeld und das Bild werden genau so angezeigt, wie man es im Backoffice erwarten würde. Aber jetzt bekommen wir Berichte vom Team für Benutzerakzeptanztests, dass sie Schachteln statt Schokoriegel sehen. Hm … kein Problem, wir erkennen, dass die gewählte Schriftart keine Emojis unterstützt und diese als unbekannte Zeichen anzeigt. Unser Designteam und die Frontend-Entwickler wechseln zu einer Version, die dies kann.

Jetzt ist endlich alles, was in unserem fiktiven Fall schiefgehen konnte (und auch schiefgegangen ist), behoben und wir sind startklar. Im Hinblick auf den gewählten Migrationsprozess (Big Bang vs. schrittweise) besteht der Unterschied darin, dass alle diese Probleme bei der ersten Variante gleichzeitig mit fünfzehn anderen ähnlichen Problemen hätten eintreten können. Damit wäre es ein enormer Arbeitsaufwand gewesen, „so eine einfache Sache“ zu beheben. Bei täglichen inkrementellen Importen hingegen werden solche Probleme höchstwahrscheinlich schon früh deutlich und es bleibt genügend Zeit, um sie vor der Produktionsfreigabe zu beheben.

Schrittweise Migrationen mit der Ibexa DXP

Ibexa DXP stellt Entwicklern eine breite Palette offener APIs für Datenmigrationsaufgaben zur Verfügung. Sie können entweder mit großen Datenblöcken arbeiten oder Importe mit granularen inkrementellen Prozessen verarbeiten. Bevor man sich entscheidet, welche dieser Möglichkeiten für den jeweiligen Anwendungsfall am besten geeignet ist, sollte man die Ausgangsdaten genau prüfen. Bieten sie alle benötigten Informationen? Soll der Import aus einer einzigen Quelle oder aus mehreren Systemen erfolgen? Werden Ressourcen benötigt, um etwas Neues für das Quellsystem zu entwickeln?

Einige gängige Methoden zur Freigabe von Quelldaten für Migrationsprozesse sind:

• Öffentliche Standard-APIs (REST, SOAP, usw.)
• Speziell entwickelte benutzerdefinierte Endpunkte (die Daten in einem benutzerdefinierten JSON-Format bereitstellen usw.)
• Gängige Content-Feed-Formate (ATOM, RSS, usw.)
• Ein Pool von Dateien, die auf der Festplatte gespeichert sind (XML, CSV, usw.)

Sobald die Datenquellen feststehen, steht die Frage im Raum, wie das Zielsystem optimal implementiert werden kann. Ibexa DXP stellt dafür die folgenden Verfahren zur Verfügung:

• Migrationsdateien
• Öffentliche HTTP-APIs
• Serverseitige PHP-APIs

Das in Ibexa DXP 3.3 eingeführte Migrations-Bundle ermöglicht das Verschieben von Repository-Strukturen zwischen Umgebungen unter Verwendung eines Standard-YAML-Formats. Es wurde für die Übertragung von Datenstrukturänderungen (Hinzufügen von Feldern zu Inhaltselementen, Erstellen von Root-Container-Objekten usw.) entwickelt, kann aber auch für den Import von Inhalten verwendet werden. Bei komplexen logischen Prozessen kann dies einschränkend wirken, aber bei einer überschaubaren Menge an einfachen Inhalten hilfreich sein, um das Prototyping von Datenmodellen zu unterstützen.

Die Ibexa DXP-Produktfamilie unterstützt von Haus aus gängige HTTP-APIs. Über RESTful- und GraphQL-APIs können Entwickler lesend und schreibend auf die Datenbestände in Ibexa DXP-Instanzen zugreifen und in ihren spezifischen Programmier- und Skriptsprachen wie JavaScript und Python mit dem System interagieren. Diese APIs bieten volle Flexibilität. Wenn allerdings beispielsweise Gigabytes von Binärdateien hin- und hergeschoben werden, kann die Performance leiden.

Die öffentliche PHP-API bietet Entwicklern direkten Zugriff auf unsere serverseitigen APIs. Es handelt sich dabei um dieselben APIs, die auch die Verwaltungsoberfläche und alle anderen Funktionen unseres Kernprodukts steuern. Üblicherweise wird die Symfony Console-Framework-Fähigkeit genutzt, um diese APIs für den Import und andere Skripting-Zwecke freizugeben. Die PHP-API-Funktionen bieten den einfachsten Zugang zu unseren sicheren APIs und sind im Allgemeinen der richtige Weg für sehr komplexe Integrationen, die mehrere Durchläufe erfordern, um Beziehungen zwischen migrierten Objekten herzustellen.

Zusammenfassung

Migrationsprozesse, bei denen das alte und das neue System lange vor der Inbetriebnahme parallel laufen, haben viele Vorteile. Mit schrittweisen Datenimporten lassen sich Probleme schneller erkennen und es kann sichergestellt werden, dass alle Teile der Integration perfekt zusammenpassen. Die kontinuierliche Durchführung von Migrationen von Anfang an bis zur letzten Minute gibt dem Unternehmen Sicherheit für den endgültigen Rollout.

Außerdem können einzelne Aspekte des Projekts noch einmal überdacht werden. So könnten einige Aufgaben, die eigentlich als Importe eingestuft sind, dadurch irrelevant werden. Wenn beispielsweise mehrere Systeme integriert werden, könnte der anfängliche Import auch in Zukunft als primäre Integrationsmethode verwendet werden. Nehmen wir an, den Betreibern der E-Commerce-Plattform sollen Produktverkaufsdaten zur Verfügung gestellt werden. Diese Daten sind in der alten Online-Commerce-Lösung gespeichert, aber die Quelldaten stammen eigentlich aus dem ERP-System. Wenn die ERP-Plattform wie bisher weiterarbeitet, könnte es sinnvoll sein, die Daten direkt von dort zu importieren und die alte E-Commerce-Plattform komplett außen vor zu lassen.

Ibexa DXP bietet Entwicklern Flexibilität und verschiedene Methoden zur Durchführung von Migrationen. Dank unseres modularen Produktaufbaus können sie auch weiterhin mit denselben vertrauten APIs arbeiten, während das Unternehmen vom digitalen Verkauf mit Ibexa Experience zum vollwertigen transaktionalen Handel mit Ibexa Commerce wechselt.