API an CRM und ERP: drei Stellen, an denen es bricht

Die Anbindung wirkt auf der Skizze wie ein Pfeil: fremde API, CRM, ERP, dazwischen ein Kasten mit dem Wort „Sync”. In der Zeichnung ist das ein Nachmittag. Im Betrieb ist es die Stelle, an der Vorgänge verschwinden, ohne dass jemand eine Fehlermeldung sieht.

Das Muster ist branchenunabhängig. Eine Fahrzeugbörse wie mobile.de ist nur das sichtbarste Beispiel: Fahrzeuge werden außen gepflegt, Anfragen sollen im CRM landen, der Verkauf soll die Warenwirtschaft erreichen. Derselbe Schnitt entsteht zwischen Shop und Buchhaltung, zwischen Ticket-System und Zeiterfassung. Dieser Beitrag ist kein Tutorial einer konkreten Schnittstelle. Er beschreibt die drei Stellen, an denen jede solche Kette bricht.

Die drei Bruchstellen heißen Rate Limits, Feldmapping und Besitz der Wahrheit. Sie treten selten einzeln auf. Wer nur die erste sieht, baut einen Puffer. Wer nur die zweite sieht, baut eine Übersetzungstabelle. Wer die dritte überspringt, hat beides und trotzdem zwei Wahrheiten.

Was die Anbindung tatsächlich ist

Eine Drittanbieter-API ist kein Adapter für das eigene Datenmodell. Sie ist ein fremdes System mit eigener Semantik, eigener Lastgrenze und eigener Vorstellung davon, was ein Datensatz ist. Eine erfolgreiche HTTP-Antwort bestätigt nur, dass die Gegenstelle die Anfrage angenommen hat — nicht, dass der eigene Bestand damit übereinstimmt. RFC 9110 beschreibt Methoden und Statuscodes; die fachliche Bedeutung eines Feldes steht dort nicht.

Deshalb scheitert der erste Entwurf fast immer gleich: Ein nächtlicher Lauf liest die fremde Liste, schreibt sie ins CRM und ins ERP und gilt als fertig, wenn er ohne Exception endet. Was fehlt, ist die Entscheidung, wer bei Widerspruch recht hat, was bei Drosselung passiert und welches Feld innen dem Feld draußen entspricht.

In der Fallstudie zur durchgehenden Vertriebskette war genau das der eigentliche Auftrag — nicht die Website, die am Ende darauf aufsetzte. Die Börsen-API ist dabei austauschbar. Was nicht austauschbar ist, sind die drei Bruchstellen.

Erste Bruchstelle: Rate Limits

Die Gegenstelle erlaubt nicht so viele Anfragen, wie der eigene Ablauf gerne stellen würde. Das ist keine Störung, sondern die normale Betriebsbedingung einer öffentlichen API. Wer das erst merkt, wenn der Lauf vor dem Messewochenende ausfällt, hat die Lastgrenze nicht entworfen, sondern gehofft.

HTTP kennt dafür einen eigenen Status: 429 Too Many Requests in RFC 9110, Abschnitt 15.5.20. Derselbe Standard legt in Abschnitt 10.2.3 fest, dass die Gegenstelle mit Retry-After sagen kann, wann ein erneuter Versuch überhaupt sinnvoll ist. Der IETF-Entwurf RateLimit header fields for HTTP ergänzt das um Kopfzeilen, mit denen ein Server das verbleibende Kontingent ankündigt, bevor es verbraucht ist. Solange der Entwurf nicht verabschiedet ist, heißt die Kopfzeile nicht überall gleich — gelesen werden muss sie trotzdem.

Was in der Praxis bricht, ist nicht der Statuscode. Es bricht die Annahme, ein Lauf dürfe die Gegenstelle so behandeln, als gehöre sie einem selbst. Ein Abgleich „lies alle, schreib alle” erzeugt auf einer Börse mit Tausenden Einträgen und auf einem CRM mit ein paar Hundert Kontakten zwei verschiedene Lastprofile. Die Börse drosselt zuerst.

Drei Entwurfsfehler treten hier regelmäßig zusammen auf:

1. Der Lauf kennt kein Budget. Er startet und arbeitet, bis er fertig ist oder abgewiesen wird. Eine Strecke, die ihr Kontingent nicht kennt, kann es nicht einhalten.
2. Der Fehlerfall ist ein Abbruch, kein Aufschub. Trifft 429 ein, gilt der Lauf als gescheitert. Der nächste Versuch beginnt von vorn und trifft dieselbe Grenze früher, weil er die bereits übertragenen Datensätze erneut anfasst.
3. Wiederholung ohne Idempotenz. Nach einer Drosselung erneut zu senden ist richtig — aber nur, wenn derselbe Vorgang nicht doppelt angelegt wird. Das ist eine eigene Eigenschaft der Schnittstelle, beschrieben in RFC 9110, Abschnitt 9.2.2 und im Beitrag Idempotenz in automatisierten Abläufen.

Die tragfähige Form ist deshalb kein „schnellerer Sync”, sondern ein Ablauf mit Fenster, Restkontingent und Fortschreibung: Was übertragen wurde, wird nicht noch einmal angefragt. Was die Gegenstelle auf später verweist, wird später versucht. Was unklar bleibt, landet in einer sichtbaren Warteschlange, nicht in einem stillen Retry. Dieselbe Grenze hat jede Ticket-, Zahlungs- oder Versand-API. Der Anbietername ändert die Kopfzeile, nicht die Bruchstelle.

Zweite Bruchstelle: Feldmapping

Zwei Systeme können dasselbe Wort verwenden und Verschiedenes meinen. „Status” ist in einer Börse der Veröffentlichungszustand eines Inserats, im CRM der Stand einer Anfrage, im ERP der Fortschritt eines Auftrags. „Preis” ist dort eine sichtbare Zahl für den Markt, hier eine kalkulierte Zahl für den Vertrieb, dort eine buchungsrelevante Zahl mit Steuerlogik. Wer die Felder gleichnamig überträgt, überträgt die Bedeutung nicht mit.

Enterprise Integration Patterns nennen das den Grund, warum eine direkte Punkt-zu-Punkt-Übersetzung nicht skaliert. Das Muster Message Translator übersetzt zwischen zwei konkreten Modellen. Das Muster Canonical Data Model setzt dazwischen ein eigenes Modell, das keinem der beteiligten Systeme gehört. Der Unterschied ist kein Geschmack: Bei drei Systemen braucht die direkte Übersetzung drei Paare, bei vier bereits sechs. Das kanonische Modell wächst linear, das Paarnetzwerk quadratisch.

In der Praxis sieht der Bruch so aus: Das fremde Feld ist ein Freitext, das eigene ein Pflichtwert aus einer festen Liste. Oder das fremde Feld kennt drei Zustände, das eigene sieben, und vier davon entstehen nur intern. Oder ein Feld existiert außen gar nicht — Baujahr, Lieferzeit, intern vergebene Nummer — und wird trotzdem gebraucht, sobald der Datensatz ins ERP soll. Dann wird gemappt, was sich mappen lässt, und der Rest landet in einem Notizfeld. Ab da ist die Automatisierung optisch fertig und fachlich offen: Die Information ist da, aber kein nachfolgender Schritt kann sie zuverlässig lesen.

Drei Regeln halten das Mapping prüfbar:

• Jedes Feld hat eine Richtung. Übernommen, übersetzt, verworfen oder intern gesetzt. Ein Feld ohne Richtung wird in beide Richtungen geschrieben und ist nach der ersten Abweichung nicht mehr zu erklären.
• Übersetzung ist eine Tabelle, kein Ausdruck im Code. Die Zuordnung „draußen A bedeutet innen B” muss eine Fachseite lesen und ändern können, ohne die Strecke neu zu bauen. Sonst veraltet sie beim nächsten Release der Gegenstelle und fällt als stiller Fehlbestand auf.
• Unübersetzbares bleibt unübersetzt. Ein Wert, der nicht eindeutig zugeordnet werden kann, darf nicht auf den häufigsten Fall fallen. Er muss in die Warteschlange — mit dem Originalwert und der Stelle, an der die Zuordnung fehlt.

Die mobile.de-API ist hier wieder nur der Typfall. Eine Börse beschreibt ein Fahrzeug so, wie Suchende es finden sollen. Ein ERP beschreibt dasselbe Fahrzeug so, wie es gebaut und kalkuliert wird. Die Felder überlappen, sie sind nicht deckungsgleich. Wer die Börse ins ERP spiegelt, übernimmt eine Verkaufssicht in eine Bestandssicht — und bricht an der ersten Ausstattungsregel, die außen ein Text ist und innen eine Verknüpfung.

Dritte Bruchstelle: Besitz der Wahrheit

Rate Limits und Mapping sind beherrschbar, solange klar ist, welches System bei Widerspruch recht hat. Genau das ist in den meisten Anbindungen nicht geklärt. Die Börse hält den aktuellen Verkaufsstand. Das CRM hält den aktuellen Kundenstand. Das ERP hält den aktuellen Auftragsstand. Jedes der drei Systeme ist in seiner Domäne die führende Quelle — und keines ist die führende Quelle für den gesamten Vorgang.

Enterprise Integration Patterns behandeln das nicht als Datenpflege, sondern als Schnittfrage. Hohpe und Woolf beschreiben im Canonical-Data-Model-Muster den Fall, in dem jedes System sein eigenes Modell durchsetzt und die Übersetzungen gegeneinander laufen. Das Ergebnis ist ein Bestand, der in zwei Systemen gleichzeitig korrekt aussieht und trotzdem nicht derselbe Vorgang ist.

Der praktische Test ist einfach. Man ändert einen Datensatz, der in allen drei Systemen vorkommt, und fragt, was die anderen beiden tun. Die Antworten in der Aufnahme sind Varianten von „das gleicht sich nachts ab”. Das heißt: Es gibt keine führende Quelle, es gibt eine Hoffnung.

Vier Festlegungen gehören deshalb vor den ersten Schreibzugriff:

1. Welche Information hat welche Heimat. Fahrzeugdaten können außen führend sein, weil sie dort ohnehin gepflegt werden müssen. Kundendaten gehören ins CRM. Auftrags- und Bestandsdaten gehören ins ERP. Eine Information, die zwei Heimaten hat, hat keine.
2. Welche Richtung der Abgleich hat. Lesen von der Heimat, schreiben in die abhängigen Systeme. Ein beidseitiger Abgleich ohne Konfliktregel ist kein Abgleich, sondern ein Würfel.
3. Was bei Konflikt gilt. Zeitstempel der Gegenstelle, Zeitstempel des eigenen Systems, oder Halt und Warteschlange. „Der neueste gewinnt” ist nur dann eine Regel, wenn die Uhren vergleichbar sind — und das sind sie zwischen einer Börse, einem SaaS-CRM und einem on-premises ERP selten.
4. Wer eine Abweichung sieht. Eine Automatisierung, die einen Konflikt still zugunsten einer Seite auflöst, erzeugt keinen bereinigten Bestand, sondern einen unbemerkten.

In der Vertriebskette aus der Fallstudie war das die Arbeit vor dem Bau: Die Börse wurde für den Katalog als führend festgelegt, das CRM für die Anfrage, die Warenwirtschaft für den Verkauf. Die Website übernahm Daten, statt sie zu halten. Dieselbe Festlegung braucht jede andere Drittanbieter-API. Wer sie überspringt, automatisiert die Unklarheit.

Eine Integration ohne benannte Wahrheit verdoppelt den Bestand. Eine Integration mit benannter Wahrheit löscht Pflege an den abhängigen Stellen.

Was vor dem Bau entschieden sein muss

Die drei Bruchstellen haben eine gemeinsame Ursache: Die Anbindung wird als technischer Adapter geplant und als fachlicher Prozess betrieben. Der größere Teil ist die Entscheidung, welches System welche Aussage darf, wie Felder ihre Bedeutung wechseln und was passiert, wenn die Gegenstelle langsamer ist als der eigene Anspruch.

Deshalb gehört die Aufnahme vor den Connector. Zwei Personen, die den Ablauf heute ausführen, beschreiben, woher sie eine Zahl nehmen und welchen Bildschirm sie im Zweifel für richtig halten. Weichen die Beschreibungen voneinander ab, ist das der erste Befund. Wie das im Vorgehen verankert ist, steht unter Prozessautomatisierung: erst aufnehmen, dann streichen, dann eine Strecke vollständig bauen. Eine API-Anbindung, die bei Schritt vier beginnt, baut die schnelle Version des alten Abgleichs.

Die Kriterien für Automatisierungsreife gelten unverändert. Der Übergang ist beschreibbar, Auslöser und Ende sind klar, die Regel steht vor dem Fall fest, und jemand verantwortet den Vorgang. Fehlt die Zuständigkeit, veraltet das Mapping und wird umgangen. Die Rate-Limit-Behandlung ohne zuständigen Menschen endet in einem stillen Stau. Der Besitz der Wahrheit ohne fachliche Heimat endet in zwei korrekten, unvereinbaren Beständen.

Was sich nicht automatisieren lässt, bleibt auch hier draußen. Eine Börse, deren Felder niemand intern festlegt, ist zuerst eine Klärung. Ein CRM mit Dubletten wird durch eine API nicht besser. Die Datenbereinigung ist dann das eigentliche Vorhaben.

Gebaut wird am Ende trotzdem ein Connector. Gegen Rate Limits braucht er ein Fenster und ein Gedächtnis. Gegen Feldmapping eine sichtbare Übersetzung. Gegen den Streit um die Wahrheit eine Richtung, die nicht zur Laufzeit umgedreht wird. Der Unterschied ist nicht die Plattform. Es ist, wem die Logik gehört.

Wer eine Drittanbieter-API an CRM und ERP hängt, entscheidet drei Dinge: wie viel Last die Gegenstelle tragen darf, welche Bedeutung ein Feld beim Übergang behält, und welches System bei Widerspruch recht hat. Sind die drei entschieden, ist der Connector Handwerk. Sind sie es nicht, ist er die Stelle, an der es bricht.

Quellen

• RFC 9110 — HTTP Semantics (9.2.2 Idempotent Methods, 10.2.3 Retry-After, 15.5.20 429 Too Many Requests)
• IETF-Entwurf: RateLimit header fields for HTTP
• Hohpe / Woolf: Message Translator
• Hohpe / Woolf: Canonical Data Model