Ein Standard schafft einen gemeinsamen Ausgangspunkt
In einem Integrationsprojekt haben wir Dokumente und Daten mehrerer Versicherer abgerufen und für nachgelagerte Anwendungen bereitgestellt. Ein Teil der Nutzer arbeitete mit eigener Vermittlersoftware, ein anderer mit einem von uns entwickelten Maklerportal.
Die Anbindungen nutzten BiPRO-SOAP-Schnittstellen. Das gab uns eine gemeinsame Grundlage, aber noch keinen durchgehend einheitlichen Datenfluss. In diesem Projekt mussten wir unter anderem unterschiedliches SOAP-Verhalten, unvollständige Metadaten, abweichende Dokumentstrukturen und Encoding-Probleme berücksichtigen.
Das beschreibt unsere damaligen Integrationen, nicht jeden heutigen BiPRO-Dienst. BiPRO umfasst inzwischen mit RClassic und RNext zwei Normgenerationen. Die offizielle Normenübersicht ordnet ihre Einsatzgebiete ein. Für eine neue Anbindung würde ich zuerst klären, welche Generation, Version und konkreten Dienste der Partner tatsächlich bereitstellt.
Die Unterschiede an einer Stelle auffangen
Unser Ziel war eine einheitliche Bereitstellung über eine eigene REST-API und das Portal. Wir speicherten die abgerufenen Daten zentral und ergänzten fehlende Metadaten, soweit sie sich aus den Dateien gewinnen ließen. Hinzu kamen Funktionen zur lesbaren Darstellung von Dokumenten.
Für die Architektur ist daran vor allem die Grenze interessant: Die Eigenheiten einer Quelle sollten nicht jede nachgelagerte Anwendung beschäftigen.
Wenn ein Versicherer ein Datum in einer bestimmten Form liefert, sollte die Darstellung im Portal nicht wissen müssen, welcher Sonderfall dahintersteckt. Die Umwandlung gehört an eine klar verantwortete Stelle. Das Portal braucht anschließend ein verlässliches Ergebnis oder eine erkennbare Information darüber, was fehlt.
Eine solche Übersetzung zwischen unterschiedlichen Modellen beschreibt Microsoft als Anti-Corruption Layer. Die Schicht schützt das eigene Modell vor fremden Begriffen und Strukturen. Sie kostet allerdings selbst Pflege und muss getestet werden.
Normalisieren heißt nicht Informationen erfinden
Ein gemeinsames Datenmodell ist nur hilfreich, wenn seine Felder eine klare Bedeutung behalten.
Angenommen, eine Quelle liefert kein eindeutiges Dokumentdatum. Das ist ein hypothetisches Beispiel. Den Abrufzeitpunkt stillschweigend als Dokumentdatum einzutragen, würde zwar eine leere Spalte füllen. Später könnte aber jemand nach diesem Datum sortieren oder einen Geschäftsvorgang daraus ableiten.
Ich würde deshalb zwischen gelieferten, abgeleiteten und fehlenden Angaben unterscheiden. Für eine abgeleitete Information muss nachvollziehbar bleiben, woher sie stammt. Wo eine zuverlässige Zuordnung nicht möglich ist, sollte das System den Zustand sichtbar machen.
Diese Entscheidung ist fachlich. Sie lässt sich nicht allein durch die Auswahl eines Serializers lösen.
Vom erfolgreichen Abruf zum verlässlichen Ablauf
Ein Dokument einmal aus einer Testumgebung zu laden, ist ein guter erster Schritt. Für den Betrieb würde ich zusätzlich drei Situationen durchspielen.
Der Abruf wird unterbrochen. Welche Arbeit wurde bereits dauerhaft gespeichert? Wo kann der nächste Versuch wieder ansetzen? Eine Erfolgsmeldung darf nicht mehr versprechen, als tatsächlich abgeschlossen ist.
Eine Lieferung kommt erneut. Woran lässt sich erkennen, ob sie bereits verarbeitet wurde? Das sollte anhand der Identitäten und Regeln des jeweiligen Dienstes entschieden werden. Ein gleicher Dateiname reicht als allgemeine Regel nicht aus.
Eine Zuordnung bleibt unklar. Wer sieht das Problem, und wie gelangt der Vorgang zur Nachbearbeitung? Ein technischer Fehlertext allein hilft dem Menschen, der das fehlende Dokument sucht, selten weiter.
Das sind Prüffragen für neue Integrationen. Sie behaupten keinen bestimmten Ablauf oder eine bestimmte Zustellgarantie für alle BiPRO-Dienste.
Onboarding gehört zur Integration
Im beschriebenen Projekt erforderte das Freischalten neuer Zugänge zunächst manuelle Arbeit durch Administratoren. Später entwickelten wir eine Oberfläche, über die Makler ihre Anbindungen selbst verwalten konnten.
Damit verschob sich ein Teil der wiederkehrenden Arbeit aus der Administration in einen bedienbaren Prozess. Das war für die Nutzung der Plattform ebenso relevant wie der eigentliche Abruf.
Für vergleichbare Vorhaben würde ich deshalb früh fragen: Wer richtet einen Zugang ein? Wer erkennt abgelaufene oder ungültige Zugangsdaten? Kann der Nutzer zwischen einem Konfigurationsproblem und einer vorübergehenden Störung unterscheiden?
Eine Integration umfasst auch die Wege, auf denen jemand sie einrichtet, versteht und nach einem Fehler wieder in Betrieb nimmt.
Was ich vor der nächsten Anbindung festhalten würde
Für einen neuen Partner würde ich ein kurzes Integrationsprofil anlegen:
- Welche Dienste und Versionen werden genutzt, und welche Geschäftsvorfälle sind abgedeckt?
- Welche repräsentativen Testfälle und Beispieldokumente stehen zur Verfügung?
- Welche Angaben werden unverändert übernommen, welche umgewandelt und welche gegebenenfalls ergänzt?
- Woran erkennen wir einen vollständigen Abruf und eine bereits verarbeitete Lieferung?
- Wer bearbeitet technische Fehler, und wer entscheidet über fachlich unklare Daten?
Das Profil ist auch eine Grundlage für die Aufwandsschätzung. Die Implementierung des nächsten Adapters kann überschaubar sein, wenn seine Besonderheiten bekannt sind. Analyse, Zugangseinrichtung, Tests und Abstimmung gehören trotzdem zum Gesamtaufwand.
Der Nutzen zeigt sich beim nächsten Verbraucher
Eine gut geschnittene Integrationsschicht macht es einfacher, dieselben Daten in einer weiteren Anwendung zu nutzen. Diese Anwendung soll auf den gemeinsam definierten Vertrag bauen können, ohne jede Quellbesonderheit neu zu behandeln.
Für mich ist das der entscheidende Maßstab: Wie viel Wissen über einzelne Versicherer muss noch durch die gesamte Anwendung getragen werden? Je klarer dieses Wissen an der Integrationsgrenze bleibt, desto gezielter lassen sich Änderungen bearbeiten.
Wenn du Versicherungsdaten in eine gewachsene .NET-Landschaft integrierst, können wir im kostenlosen Erstgespräch über eure Schnittstellen und die Stellen sprechen, an denen heute manuelle Arbeit entsteht.