API-Anbindungen zwischen ERP und Dritten
ERP zu Dritten: CRM, Logistik, Steuern und Identität
REST-, SOAP-, Webhook- und iPaaS-Verbindungen zwischen Ihrem ERP und den Diensten darum herum, mit Wiederholungen und Warnungen.
Blueprint
Seitwärts scrollen, um die ganze Zeichnung zu sehen.
ERP zu Drittanbietern: eine Plattform, viele Partner
Geschäftsereignisse verlassen das ERP einmal, und die Integrationsplattform liefert sie an jeden Partner in dem Format, das er erwartet. Callbacks kommen denselben Weg zurück. Eine Nachricht, die auch nach ihren Wiederholungen scheitert, geht an eine Dead-Letter-Queue und löst eine Warnung mit angehängter Nutzlast aus.
- Primärer Ablauf
- Asynchron
- Fehlerpfad
Der Ablauf in 9 Schritten
Der Ablauf Schritt für Schritt
- Von ERP nach Integrationsplattform: Geschäftsereignisse, über REST · OData · webhook (primärer Ablauf).
- Von Integrationsplattform nach CRM: Kunden und Aufträge, über REST/JSON (primärer Ablauf).
- Von Integrationsplattform nach Logistik und Frachtführer: Gebuchte Sendungen, über REST/JSON (primärer Ablauf).
- Von Logistik und Frachtführer nach Integrationsplattform: Sendungsereignisse, über webhook (asynchron).
- Von Integrationsplattform nach E-Invoicing- und Steuerplattform: Rechnungen zur Freigabe, über SOAP/XML · REST (primärer Ablauf).
- Von Integrationsplattform nach KYC- und Identitätsanbieter: Identitätsprüfungen, über REST/JSON (primärer Ablauf).
- Von KYC- und Identitätsanbieter nach Integrationsplattform: Prüfergebnisse, über webhook (asynchron).
- Von Integrationsplattform nach Dead-Letter-Queue und Warnungen: Nach Wiederholungen fehlgeschlagen, an eine Dead-Letter-Queue (Fehlerpfad).
- Von Dead-Letter-Queue und Warnungen nach Support-Team: Warnung mit Nutzlast und Fehler (Fehlerpfad).
Überblick
Das ist der Fluss zwischen Ihrem ERP und den Diensten darum herum: CRM, Frachtführer und Logistikdienstleister, E-Invoicing- und Steuerplattformen sowie Identitäts- und KYC-Anbieter. Jeder Partner hat seine eigene API, sein eigenes Format und seine eigenen Fehler, und jeder kommt meist als eigenes Projekt.
Das Referenzdesign sendet Geschäftsereignisse einmal aus dem ERP an eine Integrationsplattform, die sie in dem Format an jeden Partner liefert, das er erwartet: über REST, SOAP, Webhooks oder EDI über AS2, wo Handelspartner es verlangen. Rückrufe, etwa Tracking-Ereignisse oder Prüfergebnisse, kommen über dieselbe Plattform zurück.
Ein ausgefallener Partner ist ein normales Ereignis, kein Notfall. Vorübergehende Fehler werden wiederholt. Eine Nachricht, die auch nach ihren Wiederholungen fehlschlägt, geht in eine Dead-Letter-Queue, und eine Warnung erreicht das Supportteam mit Nutzlast und Fehler, sodass sie behoben und erneut eingespielt werden kann.
So funktioniert der Ablauf
Das ERP veröffentlicht ein Ereignis
Ändert sich ein Kunde, eine Bestellung oder eine Rechnung, veröffentlicht das ERP ein Geschäftsereignis an die Integrationsplattform, über seine API, OData-Dienste oder Webhooks.
Das CRM bleibt aktuell
Die Plattform aktualisiert Konten, Kontakte und Bestellungen im CRM, sodass Vertrieb und Service sehen, was das ERP weiß.
Sendungen werden gebucht
Versandbereite Bestellungen werden über seine API beim Frachtführer oder Logistikdienstleister gebucht, und Labels und Referenzen kommen zurück.
Tracking kommt zurück
Der Frachtführer sendet Tracking- und Liefernachweis-Ereignisse per Webhook, und die Plattform aktualisiert die Bestellung im ERP.
Rechnungen werden freigegeben
Rechnungen gehen im von der Behörde verlangten Format an die E-Invoicing- oder Steuerplattform, und der Freigabestatus wird mit der Rechnung gespeichert.
Identitäten werden geprüft
Neue Kunden oder Lieferanten werden an den KYC- oder Identitätsanbieter gesendet, und das Ergebnis kommt per Webhook zurück, bevor das Konto aktiviert wird.
Wenn etwas fehlschlägt
Ein Partner ist vorübergehend nicht erreichbar
Der Aufruf wird mit wachsenden Abständen wiederholt. Ein Idempotenzschlüssel bei jedem Schreibvorgang sorgt dafür, dass eine Wiederholung nie eine zweite Sendung oder Rechnung erzeugt.
Eine Nachricht schlägt auch nach den Wiederholungen fehl
Sie geht mit Nutzlast und Fehler des Partners in eine Dead-Letter-Queue, und das Supportteam wird benachrichtigt. Nach der Behebung wird sie aus der Queue erneut eingespielt.
Ein Partner ändert seine API
Vertragstests laufen gegen die Testumgebung jedes Partners und erkennen die Änderung. Angekündigte Änderungen werden vor der Frist des Partners geplant und getestet.
Die Daten werden abgelehnt
Ein Partner, der Daten aus einem fachlichen Grund ablehnt, etwa wegen einer fehlenden Steuernummer, sendet den Fehler zurück an den ERP-Datensatz, wo der Verantwortliche ihn korrigieren kann.
Standards und Systeme
- Integration
- REST
- SOAP
- Webhooks
- OpenAPI
- EDI (EDIFACT, ANSI X12)
- AS2
- MuleSoft
- Boomi
- Azure Logic Apps
- Identität und Zugriff
- OAuth 2.0
Fragen und Antworten
Welche Drittanbieterdienste können Sie anbinden?
Jeden Dienst mit dokumentierter API- oder Dateischnittstelle. Typische Beispiele sind CRM-Plattformen, Frachtführer und Logistikdienstleister, Marktplätze, E-Invoicing- und Steuerplattformen, Payroll-, KYC- und Identitätsanbieter sowie Handelspartner, die EDI-Dokumente über AS2 austauschen. Wir prüfen die API, die Limits und die Testumgebung jedes Partners, bevor wir einen Plan zusagen.
Brauchen wir dafür eine Integrationsplattform?
Sobald mehrere Partner an ein ERP angebunden sind, hält eine Plattform wie MuleSoft, Boomi oder Azure Logic Apps oder eine Reihe eigener Dienste auf einer Message Queue Mapping, Wiederholungen und Monitoring an einer Stelle. Bei einem oder zwei Partnern können direkte Verbindungen ausreichen. Wir legen die Abwägungen einschließlich Lizenzkosten für Ihren Fall dar.
Können Sie uns an E-Invoicing- und Steuer-Freigabeplattformen anbinden?
Ja. Viele Länder verlangen heute, dass Rechnungen in einem definierten Format über eine staatliche oder akkreditierte Plattform ausgestellt oder freigegeben werden. Wir integrieren das ERP mit der von Ihrem Land verlangten Plattform oder einem akkreditierten Anbieter, speichern Freigabestatus und Kennungen bei jeder Rechnung und behandeln Ablehnungen. Ihre Steuerberater bestätigen die für Sie geltenden Regeln.
Wie sichern Sie eingehende Webhooks ab?
Jeder eingehende Webhook wird vor der Verarbeitung geprüft: per Signatur, wo der Partner seine Nachrichten signiert, und per Token-, Quell- und Zeitstempelprüfung, wo er es nicht tut. Nutzlasten werden gegen den Vertrag validiert, und Ereignisse werden nur einmal verarbeitet, auch wenn der Partner sie mehrfach sendet.
Was geschieht, wenn ein Partner ausfällt?
Die übrigen Flüsse laufen weiter. Nachrichten für diesen Partner werden wiederholt und dann eingereiht, das Supportteam wird benachrichtigt, und nichts geht verloren. Erholt sich der Partner, werden eingereihte Nachrichten in Reihenfolge erneut eingespielt. Das Dashboard zeigt, welcher Partner betroffen ist und wie viele Nachrichten warten.
Wem gehören die Konnektoren, die Sie bauen?
Das geistige Eigentum an der Arbeit, die wir für Sie bauen, gehört Ihnen ab dem ersten Commit – ohne Übertragungsschritt am Ende. Konnektoren werden mit Quellcode, Tests und Dokumentation geliefert, sodass Ihr Team oder ein anderer Dienstleister sie warten kann. Vorhandene XSIS-Werkzeuge bleiben unser Eigentum und werden Ihnen lizenziert. Partner-APIs und Lizenzen für Integrationsplattformen bleiben unter den Bedingungen der jeweiligen Anbieter.
Beginnen Sie mit einem Gespräch, nicht mit einem Vertrag.
Sagen Sie uns, was Sie bauen, verbinden oder absichern möchten. Ein Architekt geht es mit Ihnen durch und empfiehlt dann, wo Sie beginnen sollten.
Wie es weitergeht
Terminabstimmung
Unser Team schreibt Ihnen, um einen Termin für das Gespräch zu vereinbaren.
Beratungsvorgespräch
Ein kostenlose 30-minütige Online-Vorberatung: Wir gehen Ihre Ziele, Systeme und Rahmenbedingungen durch.
Readiness-Review
In einer kostenlose 48-stündige Readiness-Review prüft ein Principal Architect Ihr Projekt gegen die 6-Punkte-Definition of Ready und empfiehlt den passenden Track.
Wahl des Tracks
Projekte mit klarem Leistungsumfang erhalten innerhalb von 3–5 Werktagen ein verbindliches Angebot. Projekte in der Konzeptphase starten im Blueprint Studio. Ein laufendes System, das ausfällt, nicht dokumentiert ist oder integriert werden muss, beginnt mit einer Diagnose von 1–2 Wochen. Blueprint Studio und Diagnose haben jeweils ein festes Honorar, das im Angebot genannt wird.