Target API
Euer Zielsystem gehört euch, dafür gibt es keinen fertigen Konnektor. Es gibt stattdessen einen dokumentierten Vertrag: einen Import, der die Arbeit macht, und einen Abgleich, der die Lücke bis zum Cutover schließt.
Jede Integration startet mit dem Import. Der laufende Abgleich kommt obendrauf, wenn sich die Quelle zwischen Vollimport und Cutover weiter verändert.
Der Standard
Eine Migration läuft, wir übergeben den fertigen Datenbestand an euer System, euer System meldet zurück, sobald er drin ist. Beliebig oft wiederholbar: Ein Testimport verhält sich exakt wie der echte, der Lauf, den euer Kunde freigibt, ist also der Lauf, der live geht. So startet jede Integration.
Deckt ab
Den vollständigen Datenbestand, für einen neuen Kunden oder eine Migration mit vereinbartem Cutover.
Obendrauf
Ein Vollimport ist eine Momentaufnahme, und in der Quelle wird danach weitergearbeitet. Der laufende Abgleich trägt diese Änderungen als Strom von Ereignissen nach, damit aus der Lücke zwischen Import und Cutover nie verlorene Daten werden. Es ist dasselbe ereignisgetriebene Muster, mit dem unsere eigenen Dienste untereinander im Gleichstand bleiben.
Deckt ab
Das Delta nach dem Vollimport, damit niemand die Quelle einfrieren oder die Migration in der Cutover-Nacht wiederholen muss.
Fünf Schritte, identisch für Testimport und Go-Live.
Jemand startet im Onboarding-Backoffice einen Test- oder Live-Import. Euer System ist noch nicht beteiligt.
Euer Import-Endpunkt erfährt, wo die fertigen Daten liegen, wie er sie abholt und wohin er zurückmeldet.
Euer System lädt die transformierten Daten samt Dokumenten. Die Zugangsdaten kommen mit dem Aufruf und lassen sich jederzeit erneuern.
In eurem Tempo. Währenddessen könnt ihr den Fortschritt melden, dann zeigt das Backoffice einen laufenden Balken statt eines Spinners.
Erfolg oder Fehler, dazu alles, was sich zu behalten lohnt: Fehlerprotokolle, Validierungsergebnisse, Warnungen, Statistiken.
Ihr wählt das Format, das euer System am leichtesten liest. Wir liefern darin, damit niemand uns zuliebe einen Parser schreibt.
JSON
Ein Dokument je Datensatz, verschachtelt so, wie euer Modell es erwartet.
JSONL
Ein Datensatz je Zeile, für große Mengen, die ihr streamen statt laden wollt.
SQL-Inserts
Ausführbare Statements gegen euer Schema, in der Reihenfolge, die die Beziehungen brauchen.
XML
Für Zielsysteme, deren Import das ohnehin spricht.
Eine fertige Datenbank
Die vollständige Datenbank, komplett übergeben. Gar nichts zu importieren.
Egal wofür ihr euch entscheidet, die Aufgabe auf eurer Seite bleibt dieselbe: die Lieferung annehmen, verarbeiten und den neuen Mandanten bereitstellen. Alles davor ist unsere.
Der Vertrag passt sich eurer API an, nicht umgekehrt. Diese Entscheidungen fallen einmal, bei der Einrichtung.
| Entscheidung | Möglichkeiten | Was wir meistens sehen |
|---|---|---|
| Wie wir uns bei euch ausweisen | Gar nicht, OAuth 2.0, OIDC oder etwas Eigenes | OAuth 2.0, das nutzen die bestehenden Produktiv-Integrationen |
| Wie der Aufruf aussieht | Eure Feldnamen, euer Wrapper, zusätzliche Felder | Eine Handvoll umbenannter Felder und ein eigenes Kennzeichen |
| Was vor einem Import passiert | Nichts, oder vorher ein Nachschlagen oder eine Prüfung | Nichts bei einem neuen System, ein Nachschlagen bei einem gewachsenen |
| Wie ihr zurückmeldet | Nur das Ergebnis, oder Ergebnis plus Fortschritt | Beides, sobald eine Migration lange genug läuft |
| Wie wir eure Ergebnisdateien holen | Links ohne Anmeldung, oder authentifizierter Abruf | Links ohne Anmeldung, für beide Seiten einfacher |
Jede dieser Festlegungen wird je Integration schriftlich gehalten, damit niemand sich erinnern muss, was vor einem halben Jahr vereinbart wurde.
Zwei Dinge sind wirklich Pflicht. Der Rest macht aus einer Migration etwas, das sich proben lässt, und ist das, worauf die meisten Integrationen hinauslaufen.
Pflicht
Empfohlen
Integrationen laufen auch ohne Testimporte, und wir richten die so ein. Es bedeutet nur, dass jede Probe, die ihr nicht halten könnt, als Risiko mit in den Go-Live geht. Deshalb drängen wir darauf.
Ein kleiner Teil ist in jeder Integration gleich. Alles andere passt sich an das an, was ihr schon habt.
Für den Start nicht. Der Import ist der Standard und trägt eine Migration mit vereinbartem Cutover allein. Der Abgleich kommt dazu, wenn zwischen Vollimport und Umschalten in der Quelle weitergearbeitet wird, damit diese Änderungen mitkommen statt verloren zu gehen oder doppelt migriert zu werden.
Ein Endpunkt, der einen Import annimmt, eine Rückmeldung an uns, wenn er fertig ist, und eine Möglichkeit für uns nachzufragen, wie es steht. Alles darüber hinaus ist eine Wahl, keine Pflicht.
Nein. Feldnamen, Adresse und Authentifizierung richten sich nach dem, was ihr habt. Genau deshalb wird das je Integration vereinbart, statt ein starres Format vorzugeben.
So richten wir es überall ein, wo das Zielsystem es zulässt. Testimporte laufen beliebig oft und verhalten sich exakt wie der Live-Import, der Lauf, den euer Kunde freigibt, ist also der Lauf, der live geht. Wo ein System das nicht kann, funktioniert die Integration trotzdem, sie verzichtet nur auf die Probe.
Nein, bewusst nicht. Es ist eine gewöhnliche Web-Schnittstelle, ihr baut sie in der Sprache, in der euer Backend ohnehin geschrieben ist.
Die bekommt ihr bei der Einrichtung: die genauen Endpunkte, was ein Aufruf mitbringt, wie das Ergebnis gemeldet wird und welche Antworten wir erwarten, geschrieben für die, die es umsetzen. Fragt im Gespräch danach, dann schicken wir sie.
Bringt den Endpunkt mit, in den importiert werden soll. Wir gehen den Vertrag durch, benennen was anzupassen ist, und sagen euch, was die Integration an Aufwand bedeutet.
Passend dazu: die Data Migration Engine, die die Daten erzeugt, die Quellen, aus denen sie liest und alle weiteren Integrationen.
