Integrationen & Anbindungen

Eine Anbindung beginnt mit einer nüchternen Bestandsaufnahme. Welches System führt welche Daten, in welche Richtung fließen sie, was passiert bei Konflikten. Wir erstellen eine Feldliste mit Quelle, Ziel, Datentyp und Umrechnungsregel. Genau dort kommen die unangenehmen Fragen auf den Tisch: unterschiedliche Steuersätze, Einheiten, Datumsformate, Länderkürzel und Artikelnummern, die in zwei Systemen nicht gleich aussehen.

Technisch arbeiten wir mit dem, was das Zielsystem anbietet. Das ist meist eine REST-API mit JSON, manchmal GraphQL, bei älteren Warenwirtschaften auch SOAP, CSV oder ein XML-Export auf einem SFTP-Verzeichnis. Webhooks nutzen wir dort, wo ein System Ereignisse von sich aus meldet, etwa eine bezahlte Bestellung.

Vor dem Produktivstart läuft die Strecke gegen eine Testinstanz. Wir spielen echte Datensätze durch, auch die unschönen: Storno, Teillieferung, Kunde ohne Umsatzsteuer-ID, Artikel ohne Gewicht. Erst wenn diese Fälle sauber durchlaufen, schalten wir die Anbindung produktiv.

Der häufigste Anlass ist doppelte Erfassung. Bestellungen werden im Shop ausgelöst und danach von Hand in die Warenwirtschaft getippt, Bestände werden wöchentlich per Liste gepflegt, Rechnungen entstehen ein zweites Mal in der Buchhaltung. Jede dieser Stellen kostet Zeit und erzeugt Abweichungen, die später jemand suchen muss.

Der zweite Anlass ist Wachstum. Solange wenige Bestellungen am Tag anfallen, fällt manuelle Arbeit nicht auf. Steigt das Volumen oder kommen Marktplätze und ein zweiter Shop dazu, wird die Übertragung zum Engpass. Auch neue Anforderungen lösen Projekte aus, etwa wenn Preise pro Kundengruppe aus dem ERP kommen sollen statt aus dem Shop.

Weniger sinnvoll ist eine automatische Strecke bei sehr kleinen Mengen, bei Prozessen, die sich noch jeden Monat ändern, oder wenn die Datenqualität im Quellsystem nicht stimmt. Eine Schnittstelle beschleunigt auch Fehler. Vor der Automatisierung steht deshalb das Aufräumen der Stammdaten.

Der Normalfall ist schnell gebaut. Der Aufwand steckt in den Ausnahmen. Wir arbeiten mit einer Warteschlange statt mit direkten Aufrufen, damit ein nicht erreichbares Zielsystem keine Bestellung verschluckt. Fehlgeschlagene Übertragungen werden mit wachsendem Abstand wiederholt und landen nach mehreren Versuchen in einer Liste, die jemand prüfen kann.

Wichtig ist Idempotenz: Ein zweimal gesendeter Auftrag darf nicht zu zwei Aufträgen führen. Dafür braucht jeder Vorgang einen eindeutigen Schlüssel, den beide Seiten kennen. Genauso wichtig sind die Aufruflimits der Anbieter. Viele Systeme begrenzen Anfragen pro Minute, was bei einem Erstimport mit mehreren tausend Artikeln sofort spürbar wird.

Dazu kommt Sichtbarkeit. Wir protokollieren jede Übertragung mit Zeitstempel, Nutzlast und Antwort und richten eine Benachrichtigung ein, wenn eine Strecke ungewöhnlich lange stillsteht. Zugangsdaten liegen in Umgebungsvariablen, nicht im Code. Außerdem halten wir fest, welches System bei Widerspruch gewinnt, damit niemand im Zweifelsfall raten muss.