Zum Hauptinhalt springen
FromNine
Menü

Engineering

Schnittstellen, über die Daten zuverlässig fließen und die melden, wenn etwas stockt.

CRM, ERP, Aktensysteme und Plattformen der Verwaltung verbinden wir über saubere Verträge, Ereignisse und Identitäten. Daten kommen verlässlich an, Fehler bleiben nicht verborgen, und neue Funktionen bis hin zur KI lassen sich gefahrlos andocken.

Für Organisationen in Österreich, die Systeme, Partner und Plattformen der Verwaltung in mehr als einem Mitgliedstaat verbinden.

Erstgespräch anfragenPlattformen, die wir anbinden
Integrationen & APIs: der AufbauVier übereinanderliegende Ebenen: zuoberst Portale, Apps und Agenten als Datenabnehmer, dann das API-Gateway samt Identitätsprüfung, darunter das Ereignis-Rückgrat und als Basis die führenden Systeme.01Portale, Apps und Agenten02API-Gateway und Identität03Ereignis-Rückgrat04Führende Systeme
  1. 01APIs, die vom Vertrag her entworfen sind, mit OpenAPI und AsyncAPI, versioniert und dokumentiert
  2. 02Ereignisse mit gesicherter Reihenfolge, Idempotenz, Dead-Letter-Behandlung und Wiederholung
  3. 03Durchgängig überwachte Datenflüsse, Fehlerwarteschlangen in der Hand benannter Teams

01 Probleme

Weshalb man uns zu Integrations­problemen holt

  1. 01

    Direktverbindungen, an die sich keiner wagt

    Dutzende Punkt-zu-Punkt-Verbindungen zwischen CRM, ERP und Eigenentwicklungen. Wer ein einziges Feld ändert, muss zehn Schnittstellen testen.

  2. 02

    Doppelte Datensätze, stille Ausfälle

    Ein zweiter Versuch erzeugt eine zweite Bestellung, eine fehlgeschlagene Nachricht verschwindet spurlos. Die Fachabteilung erfährt davon über Beschwerden der Kundschaft.

  3. 03

    Jeder neue Kanal bringt neue Integrations­arbeit

    Webportal, Handy-App, neuerdings ein KI-Assistent: Alle wollen dieselben Daten, und für jeden entsteht ein weiterer Export.

  4. 04

    Anbindungen an die Verwaltung werden jedes Mal zum Projekt

    Ob nationale Plattform für den Datenaustausch oder eID-System: Sicherheitsnachweise und Aufnahmeverfahren dauern jedes Mal Monate.

02 Leistungs­umfang

Was wir liefern

  1. 01 API-Strategie und API-Management

    Wir entwerfen APIs zuerst als Vertrag in OpenAPI oder AsyncAPI, legen Regeln zur Versionierung fest, lassen sie von einem Gateway durchsetzen und stellen ein Entwicklerportal bereit, über das Teams Vorhandenes finden und wiederverwenden.

    Was wir tun

    • Übersicht der APIs und ihrer Zuständigkeiten
    • Gestaltungsrichtlinien und Review-Prozess
    • Gateway-Regeln für Sicherheit, Kontingente und Versionen
    • Entwicklerportal und API-Katalog

    Was Sie erhalten

    • API-Richtlinien, die Ihre Teams tatsächlich anwenden
    • Gateway-Konfiguration als Code
    • Katalog dokumentierter APIs

  2. 02 Ereignisgesteuerte Integration

    Broker, Change Data Capture und das Outbox-Muster, samt der Details, an denen das Gelingen hängt: Reihenfolge, idempotente Verarbeitung, Umgang mit unzustellbaren Nachrichten und erneutes Abspielen.

    Was wir tun

    • Ereignismodell und Namenskonventionen
    • Outbox und CDC in den Quellsystemen
    • Idempotente Verbraucher und zugesicherte Reihenfolge
    • Dead-Letter-Queues mit Werkzeugen zum Wiederholen

    Was Sie erhalten

    • Ereignis-Rückgrat im Produktivbetrieb
    • Schema-Registry und Kompatibilitätsregeln
    • Runbook für Wiederholung und Wiederherstellung

  3. 03 Integrations­plattformen, je Datenfluss gewählt

    Ob SAP Integration Suite, MuleSoft oder ein Integrationsdienst der Cloud: Jedes Werkzeug hat seine Stärken. Wo ein iPaaS den Vorzug vor selbst geschriebenem Code verdient und wo nicht, sagen wir Ihnen geradeheraus.

    Was wir tun

    • Bewertung der vorhandenen Middleware
    • Plattformwahl auf Basis der Gesamtkosten
    • Wiederverwendbare Mappings und Konnektoren
    • Ablöse alter Middleware

    Was Sie erhalten

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

  4. 04 Identität und Vertrauen zwischen Systemen

    OAuth 2.0 und OpenID Connect, gegenseitiges TLS, Identitäten für Dienste untereinander und die Anbindung elektronischer Identitäten für Bürgerinnen, Bürger und Unternehmen: in Österreich ID Austria, in den Nachbarländern und darüber hinaus etwa BundID, itsme, DigiD und eHerkenning, FranceConnect, Cl@ve, SPID und CIE.

    Was wir tun

    • Identitätsarchitektur für Menschen und Dienste
    • Token-Design, Berechtigungsumfang und Einwilligung
    • Unterstützung bei Aufnahme und Zertifizierung für eID-Systeme
    • Vorbereitung auf die EU-Brieftasche für die Digitale Identität

    Was Sie erhalten

    • Identitätskonzept und Bedrohungsmodell
    • eID-Anbindung im Produktivbetrieb
    • Dienstidentitäten und Rotation von Geheimnissen umgesetzt

  5. 05 Anbindung an Plattformen der Verwaltung

    In Österreich geht es meist um das Unternehmensserviceportal (USP), über das Unternehmen sich seit August 2026 auch mit ID Austria anmelden, und um die e-Rechnung an den Bund über das USP oder Peppol. Dazu kommen nationale Austauschplattformen anderer Länder, etwa XÖV-Standards und FIT-Connect in Deutschland, PDND in Italien, Federal Service Bus und MAGDA in Belgien, Digikoppeling und Common Ground in den Niederlanden oder API Entreprise in Frankreich, sowie das Once-Only Technical System der EU.

    Was wir tun

    • Aufnahmeverfahren gemeinsam mit dem Plattformbetreiber
    • Abbildung auf nationale Datenstandards
    • Sicherheits- und Protokollierungsvorgaben der jeweiligen Plattform
    • Konzept für den Nachweisaustausch nach dem Once-Only-Prinzip

    Was Sie erhalten

    • Zertifizierte Anbindung an die Plattform
    • Dokumentation der Datenabbildung
    • Betriebsabläufe, mit dem Betreiber abgestimmt

  6. 06 Transparenz im Betrieb für die Fachseite

    Überwachung der Datenflüsse in einer Sprache, die die Fachseite versteht, Abgleich zwischen Systemen und Fehlerwarteschlangen, die jemandem gehören und abgearbeitet werden.

    Was wir tun

    • Überwachung der Datenflüsse auf Prozessebene
    • Abgleichsberichte zwischen Systemen
    • Einstufung und Weiterleitung von Fehlern
    • Alarme für die jeweils zuständige Person

    Was Sie erhalten

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

03 Architektur

Eine Referenz­architektur zur Illustration

Die führenden Systeme verlassen Daten auf zwei Wegen. Wer synchron fragt, geht über System-APIs und ein Gateway mit Kontrolle von Identität, Rechten und Kontingenten. Jede Änderung wiederum verlässt das System als Ereignis, per Outbox oder Change Data Capture, und wird beim Empfänger idempotent verarbeitet.

Gescheiterte Nachrichten landen in einer Dead-Letter-Queue, aus der sie sich erneut abspielen lassen, und nicht in einer Logdatei. Ein Überwachungsband stellt jeden Datenfluss in fachlichen Begriffen dar, sodass die Prozessverantwortlichen sehen, wenn er stockt.

Schichten in der Zeichnung

Führende Systeme
ERP, CRM und Aktenverwaltung bleiben maßgeblich für ihre Daten.
Synchrone APIs
System-APIs mit Versionen, abgesichert durch ein Gateway (OAuth 2.0, mTLS, Kontingente).
Ereignisse
Outbox und Broker, dazu Dead-Letter-Queue und Mappings.
Verbraucher
Portale, Apps, Agenten, Partner und Verwaltungsplattformen, mit eID wie ID Austria, wo Bürgerinnen und Bürger beteiligt sind.
Beispiel zur Veranschaulichung

  1. Führende Systeme

    • ERP, CRM und Aktensysteme

  2. Synchrone APIs

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

  3. Ereignisse

    • Outbox und CDC
    • Ereignis-Broker
    • Dead-Letter und Wiederholung
    • Mappings der Integrationsplattform

  4. Verbraucher

    • Portale, Apps und Agenten
    • Partner und Verwaltungsplattformen
    • Identität: OIDC, mTLS, eID

  5. Betrieb

    • Überwachung, Abgleich, Fehlerwarteschlangen mit Zuständigkeit
APIs und Ereignis-Rückgrat nebeneinander

Veranschaulichende Architektur, kein System eines Kunden.

Diagramm als Text lesen

Von den führenden Systemen geht der Hauptweg über System-APIs mit Versionsstand und das API-Gateway bis zu Portalen, Apps und Agenten.

Zugleich geben die führenden Systeme ihre Änderungen per Outbox und Change Data Capture an einen Broker weiter, der Partner, Verwaltungsplattformen und die Mappings der Integrationsplattform beliefert. Was scheitert, wartet in einer Dead-Letter-Queue auf die Wiederholung. OAuth, mTLS und eID schützen den Austausch nach außen.

Darunter zeigt ein Überwachungsband den Zustand der Datenflüsse, den Abgleich und die Fehlerwarteschlangen samt Zuständigkeit.

04 Überlegungen und Grenzen

Technische Überlegungen und Grenzen

  • Genau einmal ist eine Frage des Entwurfs, keine Einstellung

    Wie wir damit umgehen

    Doppelte oder verdrehte Zustellung ist bei uns der Normalfall in der Planung. Empfänger verarbeiten deshalb idempotent, mit Schlüsseln und Ordnungsregeln, die für jeden Ereignistyp festgelegt sind.

    Grenzen und Abhängigkeiten

    Manche Altsysteme können keine Idempotenzschlüssel annehmen oder nicht melden, was sie verarbeitet haben. Rund um solche Systeme setzen wir auf Abgleich, statt etwas vorzutäuschen.

  • Ein iPaaS ist nicht immer die Antwort

    Wie wir damit umgehen

    Für viele Standardkonnektoren und Mappings ist eine Plattform im Vorteil, bei komplexer Logik, großen Mengen oder strengen Antwortzeiten eigene Services. Für jede Integration halten wir fest, wofür wir uns entschieden haben.

    Grenzen und Abhängigkeiten

    Hersteller ändern ihre Lizenzbedingungen. Die günstige Plattform von heute wird womöglich morgen zum teuersten Posten im Integrationsbudget, weshalb wir mehrjährig kalkulieren.

  • Verwaltungsplattformen bestimmen ihr eigenes Tempo

    Wie wir damit umgehen

    Aufnahmeunterlagen, Sicherheitsnachweise und Testpläne liegen bei uns früh bereit, und mit dem Betreiber der Plattform stehen wir von Woche eins an in Kontakt.

    Grenzen und Abhängigkeiten

    Den Zeitplan für Zertifizierung und Aufnahme legt der Betreiber fest, nicht wir. Wir planen darum herum und zeigen Ihnen, wo er auf dem kritischen Pfad liegt.

  • KI braucht schmale APIs

    Wie wir damit umgehen

    Für Agenten und Assistenten gibt es eigene, schmal geschnittene APIs mit Obergrenzen und Protokoll. Den weiten Zugang interner Dienste erhalten sie nicht.

    Grenzen und Abhängigkeiten

    Mit jeder API, die einem Agenten offensteht, wächst das Risiko. Vor der Freigabe besprechen wir daher jede einzeln mit Ihrer IT-Sicherheit.

05 Vorgehen

So arbeiten wir

Wir entflechten, bevor wir bauen, und kein Datenfluss bleibt ohne Zuständigkeit zurück.

  1. 01

    Die Datenflüsse erfassen

    Jede Schnittstelle mit Menge, Ausfallgeschichte und fachlicher Zuständigkeit.

    ErgebnisIntegrationslandschaft mit Risikoreihung

  2. 02

    Die Regeln festlegen

    API-Richtlinien, Konventionen für Ereignisse, Identitätsmodell und Wahl der Plattform.

    ErgebnisIntegrationsrichtlinien und Entscheidungsprotokolle

  3. 03

    Fluss für Fluss umziehen

    Wir beginnen beim größten Risiko und gleichen neben der alten Schnittstelle so lange ab, bis die Zahlen stimmen.

    ErgebnisMigrierte Flüsse mit Abgleichsnachweis

  4. 04

    Sichtbar betreiben

    Dashboards je Geschäftsprozess und Fehlerwarteschlangen mit benannten Zuständigen.

    ErgebnisZuständigkeitsübersicht und Dashboards

06 Menschliche Kontrolle

Wo Menschen die Kontrolle behalten

Integration läuft ohne Aufsicht. Die Verantwortung für das, was schiefgeht, lässt sich nicht automatisieren.

  • Jede Fehler­warteschlange hat eine Zuständigkeit

    Was nicht zugestellt werden konnte, landet samt Hintergrund und Wiederholungsknopf bei einem verantwortlichen Team, statt in einem Log zu verschwinden.

  • Vertragsänderungen werden geprüft

    Bricht eine Änderung an API oder Ereignis die Kompatibilität, sehen sich die betroffenen Empfänger sie vorher an.

  • Wiederholungen sind bewusste Handlungen

    Wer Nachrichten erneut in ein führendes System einspielt, braucht dafür eine Berechtigung, und das Protokoll hält fest, wer es war und weshalb.

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
  • Ereignis-Broker der Cloud-Anbieter
  • Debezium für Change Data Capture
APIs
  • OpenAPI und AsyncAPI
  • API-Gateways und Entwicklerportale
  • GraphQL, wo es passt
  • Vertragstests
Identität
  • OAuth 2.0 und OpenID Connect
  • Gegenseitiges TLS
  • Keycloak und Identitätsdienste der Cloud-Anbieter
  • Nationale eID-Systeme wie ID Austria

Diese Auflistung gibt unsere Erfahrung aus Projekten wieder. Eine Partnerschaft mit den Herstellern oder deren Befürwortung ist damit nicht gemeint.

08 Beispiel

Ein Beispiel zur Veranschaulichung

Beispiel zur Veranschaulichung

Förderansuchen mit ID Austria, auch von Unternehmen aus Nachbarländern

01Ausgangslage
Die Förderstelle eines Bundeslandes nimmt Ansuchen von Unternehmen aus Österreich, aber auch aus Deutschland, Italien und Slowenien an. Identitätsnachweise und Unterlagen kommen in unterschiedlichster Form, und Bedienstete tippen Angaben von Hand ab.
02Was wir bauen würden
Eine Identitätsschicht, die ID Austria samt Unternehmensanmeldung über das USP, andere nationale eID-Systeme und die EU-Brieftasche für die Digitale Identität annimmt, dazu ein Nachweisaustausch über das Once-Only Technical System, wo es bereits verfügbar ist.
03Wo Menschen entscheiden
Unterlagen, die außerhalb des automatisierten Austauschs eintreffen, bestätigen die Sachbearbeiterinnen und Sachbearbeiter; das nötige Vertrauensniveau der Identität legt die Informationssicherheit der Förderstelle fest. Über das Ansuchen entscheidet weiterhin das zuständige Referat.
04Was wir messen würden
Anteil der Ansuchen mit elektronisch erhaltenen Nachweisen, Zeit von der Einbringung bis zum vollständigen Akt und Zahl der Supportanfragen rund um die Anmeldung.

09 Branchenblick

In Ihrer Branche

  • Öffentliche Verwaltung

    Datenaustausch mit Registern nach dem Once-Only-Prinzip, ID Austria für Bürgerinnen, Bürger und Unternehmen und die Protokollierung, die Plattformen der Verwaltung verlangen. Mehr zu unserer Arbeit für die öffentliche Verwaltung.

  • Fertigung & Industrie

    Ereignisse verknüpfen ERP, MES und Lieferantenportale, sodass Planung, Produktion und Kundendienst mit demselben Stand arbeiten.

  • Finanz­dienst­leistungen

    Kernsysteme, CRM und Partner-APIs, verbunden mit starker Identitätsprüfung, Prüfprotokollen und einem Abgleich, dem das Rechnungswesen vertraut.

Österreich

Interoperabilität über Grenzen hinweg

Wer an Bundesdienststellen liefert, schickt seit 1. Jänner 2014 strukturierte e-Rechnungen über das Unternehmensserviceportal (USP) oder über Peppol. Lieferanten ohne Sitz in Österreich trifft diese Pflicht nur im Rahmen ihrer technischen Möglichkeiten; Länder und Gemeinden können dieselbe Infrastruktur nutzen, ihre Lieferanten sind derzeit aber nicht verpflichtet. Österreichische Unternehmen mit öffentlichen Kunden in Deutschland stellen dort zusätzlich XRechnungen aus.

Bei der Identität setzt Österreich auf ID Austria, die seit August 2026 mit dem USP verbunden ist, sodass sich Personen auch für ihr Unternehmen anmelden können. Der Interoperable Europe Act verlangt von öffentlichen Stellen, grenzüberschreitende Interoperabilität zu bewerten, und mit eIDAS 2 müssen alle Mitgliedstaaten bis 24. Dezember 2026 eine EU-Brieftasche für die Digitale Identität anbieten.

Hinter stabilen internen Verträgen hängen die nationalen Plattformen und eID-Systeme als austauschbare Adapter. Kommt ein Land hinzu, braucht es einen Adapter und dessen Aufnahmeverfahren, die Systeme dahinter bleiben unberührt.

Fragen zu Integrationen und APIs

Integrationsplattform oder eigene Integrationen?

Beides, je nach Datenfluss. Standardkonnektoren, Mappings und die Aufnahme neuer Partner sprechen für eine Plattform. Große Mengen, knappe Antwortzeiten oder viel Logik sprechen oft für eigene Services. Wir entscheiden je Fluss und schreiben die Begründung auf.

Binden Sie Salesforce, SAP und Odoo an?

Ja, laufend: untereinander, an Eigenentwicklungen und an Systeme der Verwaltung, etwa für die e-Rechnung an den Bund. FromNine ist Partner aller drei Hersteller (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner), sodass unsere Integrationsteams Seite an Seite mit den Plattformfachleuten arbeiten. Mehr dazu unter SAP-Integration.

Brauchen wir ereignisgesteuerte Integration?

Sinnvoll sind Ereignisse, sobald mehrere Systeme auf ein und dieselbe Änderung reagieren oder Teams unabhängig voneinander ausliefern wollen. Fragt nur ein System ein anderes etwas, genügt meist eine API. In der Praxis findet man fast immer beides.

Können Sie ID Austria und andere nationale eID-Systeme anbinden?

Ja. Wir binden ID Austria und vergleichbare Systeme für Bürgerinnen, Bürger und Unternehmen an und berücksichtigen bereits die EU-Brieftaschen für die Digitale Identität, die die Mitgliedstaaten nach eIDAS 2 bis 24. Dezember 2026 bereitstellen müssen. Die Aufnahmebedingungen sind je System verschieden, deshalb planen wir sie früh ein.

Unsere Middleware ist in die Jahre gekommen. Müssen wir sie ersetzen?

Nicht auf einen Schlag. Zuerst inventarisieren wir, was dort läuft. Dann ziehen die heikelsten oder kostspieligsten Flüsse als Erste um, und bis jeder davon seine Bewährungsprobe bestanden hat, läuft ein Abgleich mit.

Zeigen Sie uns die Schnittstelle, die am häufigsten ausfällt

Sie sehen, wie wir sie beobachtbar, idempotent und mit klarer Zuständigkeit aufstellen würden, und was derselbe Schritt für alle übrigen Schnittstellen kostet.

Erstgespräch anfragenServiceassistenz ansehen