Zum Hauptinhalt springen
FromNine
Menü

Engineering

Schnittstellenentwicklung und API-Integration, die Daten zuverlässig bewegt

Wir verbinden CRM, ERP, Fachsysteme und Plattformen der Verwaltung über saubere Verträge, Ereignisse und Identitäten. So fließen Daten verlässlich, Fehler werden sichtbar, und neue Funktionen, auch KI, lassen sich sicher anbinden.

Für Organisationen, die ihre Systeme mit Peppol, föderalen Basisdiensten und Partnern auf beiden Seiten der Grenze verbinden.

Ihr Projekt besprechenUnser Vorgehen kennenlernen
Integrationen & APIs: LeistungsschichtenVier hintereinander gestaffelte Schichten. Von oben nach unten: die Konsumenten wie Portale, Apps und Agenten, das API-Gateway mit Identitätsprüfung, das Event-Backbone und darunter die führenden Systeme.01Portale, Apps und Agenten02API-Gateway und Identität03Event-Backbone04Führende Systeme
  1. 01Contract-first-APIs mit OpenAPI und AsyncAPI, versioniert und dokumentiert
  2. 02Ereignisse mit Reihenfolge, Idempotenz, Dead-Letter-Behandlung und Replay
  3. 03Jeder Datenfluss überwacht, jede Fehlerwarteschlange bei einem benannten Team

01 Herausforderungen

Integrationsprobleme, für die man uns holt

  1. 01

    Punkt-zu-Punkt-Verbindungen, die niemand anzufassen wagt

    Dutzende direkte Verbindungen zwischen CRM, ERP und Individualsystemen. Wer ein Feld ändert, muss zehn Schnittstellen testen.

  2. 02

    Dubletten und stille Fehler

    Ein erneuter Sendeversuch erzeugt einen zweiten Auftrag. Eine fehlgeschlagene Nachricht verschwindet. Der Fachbereich erfährt es von den Kunden.

  3. 03

    Jeder neue Kanal bedeutet neue Integrationsarbeit

    Das Portal, die mobile App und jetzt ein KI-Assistent brauchen dieselben Daten, und jeder bekommt seinen eigenen Extrakt.

  4. 04

    Der Anschluss an Verwaltungsplattformen wird zum eigenen Projekt

    Die Anbindung an eine nationale Datenaustauschplattform oder ein eID-Verfahren kostet jedes Mal Monate an Sicherheits- und Onboarding-Arbeit.

02 Leistungsumfang

Unsere Leistungen

  1. 01 API-Strategie und API-Management

    API-first-Design mit Verträgen in OpenAPI und AsyncAPI, eine Versionierungsrichtlinie, ein Gateway, das sie durchsetzt, und ein Entwicklerportal, über das Teams Bestehendes finden und wiederverwenden.

    Was wir tun

    • API-Landschaft und Zuständigkeiten
    • Designrichtlinien und Review-Prozess
    • Gateway-Richtlinien für Sicherheit, Kontingente und Versionierung
    • Entwicklerportal und API-Katalog

    Was Sie erhalten

    • Von Ihren Teams übernommene API-Richtlinien
    • Gateway-Konfiguration als Code
    • Katalog dokumentierter APIs

  2. 02 Ereignisgesteuerte Integration

    Broker, Change Data Capture und das Outbox-Muster, mit den Details, die über das Gelingen entscheiden: Reihenfolge, idempotente Konsumenten, Dead-Letter-Behandlung und Replay.

    Was wir tun

    • Ereignismodell und Namenskonventionen
    • Outbox und CDC an den Quellsystemen
    • Idempotente Konsumenten und Reihenfolgegarantien
    • Dead-Letter-Queues mit Replay-Werkzeugen

    Was Sie erhalten

    • Event-Backbone im Produktivbetrieb
    • Schema-Registry und Kompatibilitätsregeln
    • Runbook für Replay und Wiederherstellung

  3. 03 Integrationsplattformen, ehrlich ausgewählt

    SAP Integration Suite, MuleSoft und cloud-native Integrationsdienste haben jeweils ihren Platz. Wir sagen Ihnen, wann eine iPaaS besser ist als individueller Code und wann nicht.

    Was wir tun

    • Bewertung der vorhandenen Middleware
    • Plattformwahl auf Basis der Gesamtbetriebskosten
    • Wiederverwendbare Mappings und Konnektoren
    • Migration von Alt-Middleware

    Was Sie erhalten

    • Dokumentierte Entscheidung zur Integrationsplattform
    • Bibliothek von Integrationsmustern
    • Migrationsplan für bestehende Schnittstellen

  4. 04 Identität und Vertrauen zwischen Systemen

    OAuth 2.0 und OpenID Connect, Mutual TLS, Identitäten für Service-zu-Service-Kommunikation und die Anbindung an eID-Verfahren für Bürger und Unternehmen: itsme, DigiD und eHerkenning, BundID, FranceConnect, Cl@ve, SPID und CIE.

    Was wir tun

    • Identitätsarchitektur für Nutzende und Services
    • Token-Design, Scopes und Einwilligung
    • Unterstützung bei eID-Onboarding und Zertifizierung
    • Vorbereitung auf die EUDI-Wallets (European Digital Identity Wallets)

    Was Sie erhalten

    • Identitätskonzept und Bedrohungsmodell
    • eID-Anbindung im Produktivbetrieb
    • Service-Identitäten und Rotation von Secrets eingerichtet

  5. 05 Interoperabilität mit der Verwaltung

    Anbindungen an nationale Datenaustauschplattformen, etwa Federal Service Bus und MAGDA in Belgien, Digikoppeling und Common Ground in den Niederlanden, XÖV-Standards und FIT-Connect in Deutschland, PDND in Italien und API Entreprise in Frankreich, sowie an das Once-Only Technical System der EU.

    Was wir tun

    • Onboarding beim Plattformbetreiber
    • Mapping auf nationale Datenstandards
    • Sicherheits- und Protokollierungsanforderungen der jeweiligen Plattform
    • Konzept für den Nachweisaustausch nach dem Once-Only-Prinzip

    Was Sie erhalten

    • Zertifizierte Anbindung an die Plattform
    • Mapping-Dokumentation
    • Betriebsverfahren mit dem Betreiber

  6. 06 Betriebliche Transparenz für den Fachbereich

    Monitoring der Datenflüsse, das der Fachbereich lesen kann, Abgleiche zwischen Systemen und Fehlerwarteschlangen, für die jemand zuständig ist und die abgearbeitet werden.

    Was wir tun

    • Monitoring der Datenflüsse auf fachlicher Ebene
    • Abgleichsberichte zwischen Systemen
    • Fehlerklassifizierung und Weiterleitung
    • Alarmierung je Flussverantwortung

    Was Sie erhalten

    • Integrations-Dashboard je Geschäftsprozess
    • Abgleichsprüfungen im Produktivbetrieb
    • Zuständigkeitsübersicht für jede Fehlerwarteschlange

03 Architektur

Eine beispielhafte Referenzarchitektur

Zwei Wege führen aus den führenden Systemen heraus. Synchrone Anfragen laufen über System-APIs und ein Gateway, das Identität, Scopes und Kontingente prüft. Änderungen werden über eine Outbox oder Change Data Capture als Ereignisse veröffentlicht, und die Konsumenten verarbeiten sie idempotent.

Fehlgeschlagene Nachrichten landen in einer Dead-Letter-Queue mit Replay, nicht in einer Logdatei. Ein Monitoring-Band zeigt jeden Datenfluss in fachlichen Begriffen, damit die Prozessverantwortlichen sehen, wenn er stockt.

Ebenen der Darstellung

Führende Systeme
ERP, CRM und Fallbearbeitung behalten die Hoheit über ihre Daten.
Synchrone APIs
Versionierte System-APIs hinter einem Gateway mit OAuth 2.0, mTLS und Kontingenten.
Ereignisse
Outbox, Broker, Dead-Letter-Queue und Mappings der Integrationsplattform.
Konsumenten
Portale, Apps, Agenten, Partner und Austauschplattformen der Verwaltung, mit eID, wo Bürgerinnen und Bürger beteiligt sind.
Beispiel zur Veranschaulichung

  1. Führende Systeme

    • ERP, CRM und Fachsysteme

  2. Synchrone APIs

    • System-APIs
    • API-Gateway: OAuth 2.0, mTLS, Kontingente

  3. Ereignisse

    • Outbox und CDC
    • Event-Broker
    • Dead-Letter und Replay
    • Mappings der Integrationsplattform

  4. Konsumenten

    • Portale, Apps und Agenten
    • Austausch mit Partnern und Verwaltung
    • Identität: OIDC, mTLS, eID

  5. Betrieb

    • Fluss-Monitoring, Abgleich, zugeordnete Fehlerwarteschlangen
APIs und Event-Backbone nebeneinander

Beispielhafte Architektur, kein Kundensystem.

Diagramm als Text lesen

Der Hauptpfad führt von den führenden Systemen über versionierte System-APIs und ein API-Gateway zu Portalen, Apps und Agenten.

Parallel veröffentlichen die führenden Systeme Änderungen über eine Outbox und Change Data Capture an einen Event-Broker, der sie an Austauschplattformen von Partnern und Verwaltung sowie an eine Integrationsplattform für Mappings ausliefert. Fehlgeschlagene Nachrichten gehen in eine Dead-Letter-Queue mit Replay. Identitätsdienste mit OAuth, mTLS und eID sichern den Austausch mit Partnern ab.

Ein Monitoring-Band darunter zeigt den Status der Datenflüsse, Abgleiche und zugeordnete Fehlerwarteschlangen.

04 Abwägungen und Grenzen

Technische Abwägungen und Grenzen

  • Exactly-once ist ein Design, keine Einstellung

    Wie wir vorgehen

    Wir gehen davon aus, dass Nachrichten doppelt oder in falscher Reihenfolge ankommen, und gestalten Konsumenten idempotent, mit Schlüsseln und Reihenfolgeregeln, die je Ereignistyp vereinbart werden.

    Grenzen und Abhängigkeiten

    Manche Altsysteme akzeptieren keine Idempotenzschlüssel oder melden nicht, was sie verarbeitet haben. Um sie herum bauen wir Abgleiche, statt etwas vorzutäuschen.

  • Eine iPaaS ist nicht immer die Antwort

    Wie wir vorgehen

    Plattformen gewinnen bei vielen Standardkonnektoren und Mappings. Individuelle Services gewinnen bei komplexer Logik, hohen Volumen oder strengen Latenzanforderungen. Wir dokumentieren die Entscheidung je Integration.

    Grenzen und Abhängigkeiten

    Lizenzmodelle ändern sich. Eine Plattform, die heute günstig ist, kann zum größten Posten Ihres Integrationsbudgets werden. Deshalb rechnen wir die Kosten über mehrere Jahre.

  • Verwaltungsplattformen bestimmen ihr eigenes Tempo

    Wie wir vorgehen

    Wir bereiten Onboarding-Unterlagen, Sicherheitsnachweise und Testpläne früh vor und arbeiten ab der ersten Woche mit dem Plattformbetreiber zusammen.

    Grenzen und Abhängigkeiten

    Zeitpläne für Zertifizierung und Onboarding legt der Betreiber fest, nicht wir. Wir planen sie ein und zeigen Ihnen, wo sie auf dem kritischen Pfad liegen.

  • KI-Konsumenten brauchen schmale APIs

    Wie wir vorgehen

    Agenten und Assistenten erhalten eigene, eng begrenzte APIs mit Limits und Audit-Protokollierung, nicht denselben breiten Zugriff wie interne Services.

    Grenzen und Abhängigkeiten

    Eine API für einen Agenten freizugeben, erhöht das Risiko. Wir prüfen jede einzelne mit Ihrer IT-Sicherheit, bevor sie live geht.

05 Zusammenarbeit

So arbeiten wir

Wir entflechten, bevor wir bauen, und hinterlassen jeden Datenfluss mit einer klaren Zuständigkeit.

  1. 01

    Datenflüsse erfassen

    Jede Schnittstelle mit Volumen, Fehlerhistorie und fachlicher Verantwortung.

    ErgebnisIntegrationslandschaft und Risikorangfolge

  2. 02

    Regeln festlegen

    API-Richtlinien, Ereigniskonventionen, Identitätsmodell und Plattformwahl.

    ErgebnisIntegrationsrichtlinien und Entscheidungsprotokolle

  3. 03

    Fluss für Fluss umstellen

    Die riskantesten Flüsse zuerst, mit einem Abgleich parallel zur alten Schnittstelle, bis die Zahlen übereinstimmen.

    ErgebnisMigrierte Datenflüsse mit Abgleichsnachweis

  4. 04

    Sichtbar betreiben

    Dashboards je Geschäftsprozess und Fehlerwarteschlangen mit benannten Verantwortlichen.

    ErgebnisZuständigkeitsübersicht und Dashboards

06 Menschliche Kontrolle

Wo Menschen die Kontrolle behalten

Integration läuft unbeaufsichtigt. Die Verantwortung für Fehler nicht.

  • Jede Fehlerwarteschlange hat eine Zuständigkeit

    Fehlgeschlagene Nachrichten gehen mit Kontext und Replay-Funktion an ein verantwortliches Team, nicht in ein gemeinsames Log.

  • Vertragsänderungen werden geprüft

    Inkompatible Änderungen an APIs oder Ereignissen durchlaufen vor der Veröffentlichung ein Review mit den Konsumenten.

  • Replays sind bewusste Entscheidungen

    Nachrichten erneut in ein führendes System einzuspielen, ist eine autorisierte Aktion, protokolliert mit Person und Begründung.

07 Technologien

Technologien, mit denen wir arbeiten

Integrationsplattformen
  • SAP Integration Suite
  • MuleSoft
  • Azure Integration Services
  • Integrationsdienste von AWS und Google Cloud
Ereignisse und Streaming
  • Apache Kafka
  • RabbitMQ
  • Cloud-Event-Broker
  • Debezium für Change Data Capture
APIs
  • OpenAPI und AsyncAPI
  • API-Gateways und Entwicklerportale
  • GraphQL, wo es passt
  • Contract Testing
Identität
  • OAuth 2.0 und OpenID Connect
  • Mutual TLS
  • Keycloak und Cloud-Identity-Provider
  • Nationale eID-Verfahren

Die Nennung einer Technologie beschreibt unsere Engineering-Erfahrung. Sie bedeutet keine Partnerschaft mit dem Hersteller und keine Empfehlung durch ihn.

08 Beispiel

Beispielhaftes Szenario

Beispiel zur Veranschaulichung

E-Rechnungen für Kunden in Belgien und Deutschland

01Ausgangslage
Ein Maschinenbaubetrieb in Ostbelgien stellt Rechnungen an belgische Kunden über Peppol aus, während seine Kunden in Deutschland strukturierte E-Rechnungen in ihrem nationalen Format erwarten. Bisher erstellt die Buchhaltung beides von Hand aus dem ERP.
02Was wir bauen würden
Eine Integrationsschicht, die jede Rechnung einmal aus dem ERP übernimmt, je Empfänger das richtige Format erzeugt, sie über Peppol oder den vereinbarten Kanal zustellt und den Status zurückmeldet.
03Wo Menschen entscheiden
Abgelehnte oder unzustellbare Rechnungen landen in einer Fehlerwarteschlange, die die Buchhaltung prüft und erneut anstößt.
04Was wir messen würden
Anteil der Rechnungen, die ohne Eingriff zugestellt werden, Zeit bis zur Klärung eines Fehlers und Zahl der Rückfragen von Kunden.

09 Branchenblick

In Ihrer Branche

  • Öffentlicher Sektor & Verwaltung

    Datenaustausch nach dem Once-Only-Prinzip mit authentischen Quellen, eID für Bürger und Unternehmen und die Protokollierung, die nationale Plattformen verlangen. Mehr zu unserer Arbeit für den öffentlichen Sektor.

  • Fertigung & Industrie

    ERP, MES und Lieferantenportale, über Ereignisse verbunden, damit Planung, Produktion und Service dasselbe Bild teilen.

  • Finanzdienstleistungen

    Kernsysteme, CRM und Partner-APIs, verbunden mit starker Identitätsprüfung, Audit-Protokollierung und Abgleichen, denen das Finanzwesen vertraut.

Belgien

Schnittstellen zu den belgischen Basisdiensten

Seit dem 1. Januar 2026 müssen belgische Unternehmen Rechnungen untereinander strukturiert über Peppol austauschen, und öffentliche Auftraggeber empfangen sie über Mercurius. Für Bürger und Unternehmen stellt FÖD BOSA eID, itsme über den Föderalen Authentifizierungsdienst und die eBox bereit, und mit eIDAS 2 kommt die EU-Brieftasche für die digitale Identität hinzu.

Ostbelgische Betriebe haben oft auch Kunden in Deutschland, die eigene E-Rechnungsformate verlangen. Wir bauen Integrationsschichten, in denen jede Plattform ein Adapter hinter einer stabilen internen Schnittstelle ist. Ein neuer Partner bedeutet dann einen neuen Adapter, keinen Umbau.

Fragen zu Integrationen und APIs

Sollen wir eine Integrationsplattform nutzen oder individuell integrieren?

Beides, für unterschiedliche Datenflüsse. Standardkonnektoren, Mappings und das Onboarding von Partnern sprechen für eine Plattform. Flüsse mit hohem Volumen, kritischer Latenz oder viel Logik sprechen oft für individuelle Services. Wir entscheiden je Fluss und dokumentieren die Gründe.

Integrieren Sie Salesforce, SAP und Odoo?

Ja, regelmäßig, untereinander sowie mit Individual- und Verwaltungssystemen. FromNine hat bei allen drei Herstellern Partnerstatus (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner), sodass unsere Integrationsteams Seite an Seite mit Plattformspezialisten arbeiten. Mehr zu unserer SAP-Integration.

Brauchen wir ereignisgesteuerte Integration?

Wenn mehrere Systeme auf dieselbe Änderung reagieren müssen oder Sie Release-Zyklen entkoppeln wollen, helfen Ereignisse. Für einfache Anfrage-Antwort-Muster zwischen zwei Systemen reicht oft eine API. Die meisten Systemlandschaften nutzen beides.

Können Sie nationale eID-Verfahren anbinden?

Ja. Wir binden eID-Verfahren für Bürger und Unternehmen an und planen bereits für die EUDI-Wallets, die die Mitgliedstaaten im Rahmen von eIDAS 2 einführen. Die Onboarding-Anforderungen unterscheiden sich je Verfahren, und wir berücksichtigen sie früh.

Wir haben Alt-Middleware. Müssen wir sie ersetzen?

Nicht auf einen Schlag. Wir erfassen, was darauf läuft, verlagern zuerst die riskantesten oder teuersten Flüsse und behalten den Abgleich bei, bis jeder migrierte Fluss sich bewährt hat.

Bringen Sie die Schnittstelle mit, die am häufigsten ausfällt

Wir zeigen, wie wir sie beobachtbar, wiederholbar und verantwortet machen würden, ob sie nach Brüssel, nach Namur oder über die Grenze nach Aachen führt.

Gespräch vereinbarenUnser Vorgehen ansehen