Zwei Programme verbinden: was vor dem Versprechen einer Integration zu prüfen ist

„Sprechen die beiden Systeme miteinander?“ ist eine Frage, die sich nicht beantworten lässt. Sie sprechen miteinander, um was zu tun: welches Datum, in welcher Richtung, mit welcher Häufigkeit, und wer hat recht, wenn die beiden Systeme Unterschiedliches sagen. Dieser Leitfaden hilft, das vor einer Zusage zu klären, denn eine versprochene, aber ungeprüfte Integration verwandelt ein Projekt in eine endlose Wartung.

Fast alle gescheiterten Integrationen haben dieselbe Geschichte: In der Testphase funktionierte es, dann trat ein nicht vorgesehener Fall auf — eine stornierte Bestellung, ein Kunde mit zwei Datensätzen, ein gelöschter Artikel —, und niemand bemerkte, dass seit drei Tagen nichts mehr übertragen wurde.

Eine Zeile für jedes Datum

Das Ausgangsdokument ist eine Liste: eine Zeile pro Datum, vier Spalten. Lässt sie sich nicht ausfüllen, ist es noch nicht an der Zeit, sich die technischen Spezifikationen anzusehen.

Die letzte Spalte ist die, die Diskussionen vermeidet. Weicht der Preis eines Artikels in den beiden Systemen voneinander ab, wer gewinnt? Lautet die Antwort „kommt darauf an“, wird die Integration unabhängig von der eingesetzten Technologie widersprüchliche Daten erzeugen.

Daten, die unterwegs den Eigentümer wechseln

Manche Daten wechseln den Eigentümer, und das ist der heikelste Fall. Eine Bestellung gehört der Website, solange sie nicht übernommen wurde; ab diesem Moment liegt die Wahrheit in der Verwaltungssoftware, und die Website zeigt nur noch eine Kopie. Können beide sie ändern, kreuzen sich früher oder später zwei Änderungen, und die zuletzt eingetroffene gewinnt, was nicht zwangsläufig die richtige ist.

Es gibt nur eine praktische Regel: Für jedes Datum darf zu jedem Zeitpunkt nur ein System schreiben. Die anderen lesen nur.

Was die Schnittstellen auf der ersten Seite nicht verraten

• Die Berechtigungen. Die Ihnen erteilten Zugangsdaten decken möglicherweise nicht alle benötigten Felder ab, und die Autorisierung kann ablaufen oder eine regelmäßige Erneuerung erfordern, an die jemand denken muss.
• Die Grenzwerte. Wie viele Aufrufe pro Minute oder pro Tag, wie viele Datensätze pro Anfrage. Ein großer Katalog passt mit der benötigten Häufigkeit möglicherweise nicht in diese Grenzen, und das verändert das Projekt, nicht nur den Code.
• Die tatsächlich verfügbaren Felder. Die Dokumentation listet die Objekte auf, sagt aber nicht immer, ob Ihre individuellen Felder freigegeben sind: Das muss an Ihren eigenen Daten geprüft werden, nicht am Beispiel.
• Die Testumgebung. Gibt es keine, findet jede Prüfung mit den echten Daten statt, mit allem, was das bedeutet. Das ist ein Umstand, den man vorher einplanen muss, nicht erst hinterher entdeckt.
• Die Bedingungen des Anbieters. Was erlaubt ist, mit welchem Tarif, und ob der Zugang zum Datenaustausch inbegriffen ist oder gesondert kostet.

Integrationsblatt: die doppelt eintreffende Bestellung

Der zu planende Fall ist nicht der normale, sondern der unsaubere. Eine Bestellung wird an die Verwaltungssoftware gesendet, die Antwort bleibt wegen eines Netzwerkproblems aus, das System versucht es erneut, und die Bestellung wird doppelt angelegt. Das ist die häufigste Störung von allen.

1. Jede Nachricht trägt eine feste, von der sendenden Seite festgelegte Kennung: die Bestellnummer der Website, nicht eine erst beim Versand erzeugte laufende Nummer.
2. Die empfangende Seite prüft, ob diese Kennung bereits verarbeitet wurde. Wenn ja, wiederholt sie nichts und meldet, dass alles in Ordnung ist. Diese Eigenschaft macht das erneute Senden sicher.
3. Die Versuche wiederholen sich in wachsenden Abständen und für eine festgelegte Anzahl von Malen; danach landet die Nachricht in einer Fehlerwarteschlange, die eine Person prüft. Endloses Wiederholen verdeckt das Problem, statt es zu lösen.
4. In regelmäßigen Abständen werden die beiden Systeme für den Zeitraum verglichen: wie viele Bestellungen auf der einen Seite, wie viele auf der anderen, welche fehlen. Das ist der Abgleich, und er ist das Einzige, was wirklich zeigt, ob die Integration funktioniert.
5. Die Behebung ist ein schriftliches Verfahren: wer das Duplikat in welchem System löscht, was mit einem eventuell bereits ausgestellten Dokument geschieht, wer den Kunden informiert, falls er zwei Bestätigungen erhalten hat.

Dasselbe Blatt muss für die Kundenstammdaten ausgefüllt werden, wo die typische Störung eine andere ist: zwei Datensätze für dasselbe Unternehmen, angelegt mit der Umsatzsteuer-ID in zwei unterschiedlichen Schreibweisen. Es braucht eine vorab festgelegte Erkennungsregel und einen Ort, an dem Zweifelsfälle landen, bis eine Person sie sich ansieht.

Wer es bemerkt, wenn es stoppt

Eine Integration bleibt früher oder später immer stehen: Der Anbieter aktualisiert, ein Passwort läuft ab, ein Zertifikat wird nicht erneuert, ein Feld ändert sein Format. Die Frage ist nicht, ob es passiert, sondern wie viel Zeit vergeht, bevor es jemand bemerkt.

• Eine Kontrolle, die die jüngste Datenübertragung prüft und Alarm schlägt, wenn der Fluss abreißt, statt auf den Anruf eines Kunden zu warten.
• Eine namentlich benannte Person für diesen Alarm, und eine zweite für den Fall, dass die erste nicht verfügbar ist.
• Ein Austauschprotokoll, das ohne Anruf bei einer Entwicklerin oder einem Entwickler einsehbar ist: Kommt eine Bestellung nicht an, lautet die erste Frage immer „ist sie abgeschickt worden?“.
• Eine festgelegte Zuständigkeit für die Wartung, mit den Ablaufdaten von Zugangsdaten und Zertifikaten an einem Ort vermerkt, den jemand im Blick behält.

Was dieser Leitfaden nicht abdeckt

Hier wird der Austausch zwischen zwei dauerhaft nebeneinander bestehenden Systemen geplant. Historische Daten einzubringen — aus einer alten Verwaltungssoftware oder aus Tabellenkalkulationen — ist eine andere Aufgabe, mit eigenen Problemen bei der Bereinigung und der Kontrolle des Ergebnisses, und hat einen eigenen Leitfaden. Auch der spezielle Fall der Verbindung zwischen Online-Shop und Lager wird gesondert behandelt.