Message Translator: Nachrichtenformat umwandeln

Nachrichten und Ereignisse

Message Translator

Nachrichtenformat umwandeln

Die Idee und ihr Nutzen

Das Altsystem einer Versicherung, ein altes Programm, das die Verträge verwaltet, schickt Schadenmeldungen im Textformat XML, mit dem Feldnamen KDNR für die Kundennummer und dem Betrag in Cent. Der neue Schadendienst, der die Schäden anlegt, erwartet dieselben Meldungen im Textformat JSON, mit dem Feldnamen kundennummer und dem Betrag in Euro. XML und JSON sind zwei verbreitete Textformate, in denen Programme Daten mit Feldnamen und Werten austauschen. Das Altsystem schickt jede Meldung an ein zusätzliches Programm. Dieses Programm prüft, ob alle nötigen Angaben vorhanden sind, schreibt die Meldung in das Format des Schadendienstes um und gibt sie an den Schadendienst weiter. Ein solches Programm heißt Message Translator, auf Deutsch Nachrichtenübersetzer oder kurz Übersetzer.

Bausteine: Altsystem: sendet Schadenmeldungen; Übersetzer: prüft Pflichtfelder, rechnet um, benennt Felder um; Schadendienst: erwartet seine eigenen Feldnamen. Verbindungen: Altsystem → Übersetzer (Textformat XML, Betrag in Cent); Übersetzer → Schadendienst (Textformat JSON, Betrag in Euro). Der Übersetzer schreibt jede Meldung vom Format des Altsystems in das Format des Schadendienstes um.

Wie funktioniert es?

Das Altsystem sendet dem Übersetzer eine Schadenmeldung als XML mit der Schadennummer 4711, der Kundennummer <KDNR>815</KDNR> und dem Betrag <BETRAG>125000</BETRAG>, gemeint sind 125000 Cent. Der Übersetzer prüft zuerst, ob die Meldung Schadennummer, Kundennummer und Betrag enthält, denn diese Angaben braucht der Schadendienst. Alle drei sind vorhanden. Der Übersetzer übernimmt die Werte von Schadennummer und Kundennummer unverändert, rechnet 125000 Cent in 1.250 Euro um und schreibt eine Nachricht als JSON mit den Feldnamen des Schadendienstes, darin "kundennummer": 815 und "betrag": 1250.00. Der Schadendienst erhält die übersetzte Nachricht und legt den Schaden an.

Am selben Tag vergisst ein Sachbearbeiter, bei einem weiteren Schaden die Kundennummer im Altsystem einzutragen. Das Altsystem sendet diese zweite Meldung ohne Kundennummer. Der Übersetzer bemerkt bei der Prüfung, dass die Kundennummer fehlt. Er gibt die Meldung nicht an den Schadendienst weiter, sondern weist sie mit dem Hinweis „Kundennummer fehlt“ an das Altsystem zurück. Eine Kundennummer erfindet der Übersetzer nicht, denn mit einer falschen Kundennummer würde der Schaden beim falschen Vertrag landen.

Das Altsystem verschickt die Schadenmeldungen als Nachrichten. Eine Nachricht ist ein in sich abgeschlossenes Datenpaket, das ein Programm an ein anderes schickt. Schadennummer, Kundennummer und Betrag bedeuten in beiden Programmen dasselbe; die Programme schreiben die Angaben nur verschieden auf. Nur der Übersetzer weiß, dass KDNR die Kundennummer ist und das Altsystem Beträge in Cent schickt. Automatische Tests geben dem Übersetzer Meldungen des Altsystems und prüfen, ob die erwartete Nachricht für den Schadendienst herauskommt.

Je nachdem, welche Programme verbunden werden, muss der Übersetzer auf einer oder mehreren der folgenden Ebenen umwandeln:

Übertragungsweg: Ein Programm legt zum Beispiel jede Nacht eine Datei ab. Der Übersetzer macht aus der Datei einzelne Nachrichten auf einer Warteschlange. Eine Warteschlange ist ein Zwischenspeicher, aus dem der Empfänger die Nachrichten der Reihe nach abholt.
Textformat: XML wird zu JSON. Oder Datensätze, in denen jede Angabe an einer festen Position steht, werden zu einem Format mit Feldnamen.
Feldnamen und Einheiten: KDNR wird zu kundennummer, Cent werden zu Euro, die Werte J für ja und N für nein werden zu „wahr“ und „falsch“.
Codewerte und zusammengesetzte Felder: Codewerte sind Abkürzungen und Zahlen, deren Bedeutung man nachschlagen muss. Zwei Programme verwenden zum Beispiel verschiedene Codewerte für dieselbe Versicherungssparte, das eine 03 für Hausrat, das andere HR. Oder ein Feld enthält Straße und Hausnummer zusammen und muss aufgeteilt werden.

Der Übersetzer formt nur um und trifft keine fachlichen Entscheidungen. Er entscheidet zum Beispiel nicht, ob ein Schaden bezahlt wird.

Beteiligte: Altsystem: sendet Schadenmeldungen als XML, Betrag in Cent; Übersetzer: prüft Pflichtfelder, rechnet um, benennt Felder um; Schadendienst: erwartet JSON mit seinen Feldnamen, Betrag in Euro. Ablauf: 1. Das Altsystem sendet dem Übersetzer eine Schadenmeldung als XML mit der Schadennummer 4711, der Kundennummer 815 und dem Betrag 125000 Cent. 2. Der Übersetzer prüft die Pflichtfelder: Schadennummer, Kundennummer und Betrag sind vorhanden. 3. Der Übersetzer rechnet 125000 Cent in 1.250 Euro um und schreibt die Nachricht als JSON mit den Feldnamen des Schadendienstes. 4. Der Schadendienst erhält die übersetzte Nachricht und legt den Schaden an. 5. Ein Sachbearbeiter vergisst, bei einem weiteren Schaden die Kundennummer im Altsystem einzutragen. Das Altsystem sendet diese zweite Meldung ohne Kundennummer. 6. Der Übersetzer weist die Meldung mit dem Hinweis „Kundennummer fehlt“ an das Altsystem zurück. Mit einer erfundenen Kundennummer würde der Schaden beim falschen Vertrag landen.

Wann ist es sinnvoll und wann nicht?

Ein Message Translator lohnt sich

Keines der beiden Formate lässt sich ändern. Das Altsystem kann nicht mehr geändert werden, und der Schadendienst wird von einem Team gepflegt, das bei seinem eigenen Format bleiben soll. Ohne Übersetzer kann der Schadendienst die Meldungen des Altsystems nicht lesen.
Der Schadendienst soll die Eigenheiten des Altsystems nicht kennen müssen. Ohne Übersetzer müsste der Schadendienst selbst wissen, dass KDNR die Kundennummer ist, und jeden Betrag von Cent in Euro umrechnen. Mit Übersetzer erhält der Schadendienst kundennummer statt KDNR und 1.250 Euro statt 125000 Cent.
Viele Programme mit eigenen Formaten sollen miteinander Nachrichten austauschen. Dann legt die Versicherung oft ein gemeinsames Zwischenformat fest, ein sogenanntes kanonisches Datenmodell. In diesem Zwischenformat steht die Kundennummer zum Beispiel in jeder Nachricht im Feld kundennummer und jeder Betrag in Euro. Jedes Programm braucht dann nur zwei eigene Übersetzer mit eigenen Regeln, einen in das Zwischenformat und einen aus dem Zwischenformat heraus, statt einen Übersetzer für jedes andere Programm.

Ein Message Translator ist nicht das Richtige

Die Teams beider Programme können ihre Programme ändern und sich auf ein gemeinsames Format einigen. Ein Übersetzer würde dann nur einen Unterschied ausgleichen, den eines der Teams auch einmal selbst beseitigen kann. Kann zum Beispiel das Team des Altsystems das Altsystem noch ändern, stellt es die Meldungen einmal auf JSON mit kundennummer und Beträgen in Euro um. Ob Schadennummer, Kundennummer und Betrag vorhanden sind, prüft dann der Schadendienst beim Empfang selbst. Ein Übersetzer, der betrieben und bei jeder Formatänderung angepasst werden muss, entfällt.
Beide Programme verwenden dieselben Begriffe mit verschiedener Bedeutung. Ein Beispiel: „Kunde“ bezeichnet im einen Programm eine Person und im anderen einen Vertrag. Eine reine Formatumwandlung löst diesen Widerspruch nicht. Dann baut das Team des Schadendienstes einen Anti Corruption Layer. Der Anti Corruption Layer übersetzt nicht nur das Format, sondern auch die Begriffe und Regeln des fremden Programms. So legt der Schadendienst einen Vertrag des fremden Programms nicht als Kunden an.
Der Schadendienst verlangt eine Angabe, die das Altsystem gar nicht kennt. Der Übersetzer kann nur weitergeben, was das Altsystem liefert. Dann legt die Versicherung fest, woher die fehlende Angabe kommt, etwa aus einem anderen Programm oder aus einer Eingabe der Sachbearbeiter. So setzt niemand im Übersetzer einen erfundenen Ersatzwert ein.
Ein Programm ruft ein anderes direkt auf, statt ihm Nachrichten zu schicken. Ein Message Translator wandelt aber Nachrichten um, die ein Programm verschickt. Dann baut das Team des aufrufenden Programms einen Adapter. Das aufrufende Programm ruft den Adapter auf, der Adapter wandelt den Aufruf um, ruft das andere Programm auf und wandelt dessen Antwort zurück. Das aufrufende Programm muss seine Aufrufe dafür nicht auf Nachrichten umstellen.

Nachteile und typische Fehler

Der Übersetzer ist ein zusätzliches Programm, das betrieben, getestet und bei jeder Formatänderung angepasst werden muss. Damit eine Formatänderung auffällt, braucht der Übersetzer Tests mit echten Beispielnachrichten. Führt der Schadendienst eine weitere Pflichtangabe ein, etwa das Schadendatum, muss der Übersetzer ebenfalls angepasst werden. Ein gemeinsames Zwischenformat für das ganze Unternehmen wird schnell sehr umfangreich, weil es die Angaben aller angebundenen Programme aufnehmen muss. Das Zwischenformat ist dann schwer zu ändern, weil jede Änderung alle Übersetzer betrifft. Bei nur zwei Programmen braucht ein Zwischenformat für die Meldungen des Altsystems zwei Übersetzer statt einem. Der eine übersetzt vom Altsystem in das Zwischenformat, der andere aus dem Zwischenformat in das Format des Schadendienstes. Jede Meldung wird dann zweimal übersetzt.

Typische Fehler und woran man sie erkennt:

Verlorene Angaben: Das Format des Schadendienstes kennt ein Feld des Altsystems nicht, und der Übersetzer lässt das Feld stillschweigend weg. Das Altsystem schickt zum Beispiel im Feld BEM eine Bemerkung des Sachbearbeiters mit, etwa „Kunde nur vormittags erreichbar“. Das Format des Schadendienstes hat kein Feld dafür, und die Bemerkung kommt beim Schadendienst nicht an. Erkennbar ist das, wenn Sachbearbeiter im Schadendienst Angaben vermissen, die im Altsystem stehen.
Unklare Fehlerquelle: Mit einem Zwischenformat läuft eine Meldung durch zwei verschiedene Übersetzer hintereinander, vom Altsystem in das Zwischenformat und aus dem Zwischenformat in das Format des Schadendienstes. Zwei verschiedene Teams pflegen die beiden Übersetzer. Steht beim Schadendienst ein falscher Betrag, kann jeder der beiden Übersetzer den Fehler verursacht haben. Erkennbar ist das an langen Fehlersuchen, bei denen jedes beteiligte Team seine eigene Umwandlung für richtig hält.
Geändertes Format eines angebundenen Programms: Ein angebundenes Programm ändert sein Format, und niemand passt den Übersetzer an. Das Team des Schadendienstes benennt zum Beispiel das Feld betrag in schadenbetrag um. Der Übersetzer schreibt weiter betrag, und der Schadendienst weist jede übersetzte Nachricht zurück, weil der Schadenbetrag fehlt. Erkennbar ist das an vielen zurückgewiesenen Nachrichten ab einem bestimmten Zeitpunkt.
Vergessene Umrechnung: Der Übersetzer übernimmt den Betrag ohne Umrechnung, und beim Schadendienst steht ein Schaden über 125.000 Euro statt 1.250 Euro. Erkennbar ist das an Beträgen, die genau hundertmal zu hoch sind.
Erfundener Wert: Der Übersetzer setzt für eine fehlende Pflichtangabe einen Ersatzwert ein, etwa für jede fehlende Kundennummer die Kundennummer 1. Der Schadendienst legt den Schaden dann beim Vertrag von Kunde 1 an, also beim falschen Vertrag. Erkennbar ist das an Schäden, die einem Vertrag zugeordnet sind, zu dem sie nicht passen.

Weiterführend

Werkzeuge und Umsetzungen

Apache Camel: enthält fertige Umwandlungen zwischen vielen Formaten und Übertragungswegen.
Jolt: Java-Bibliothek, die JSON-Nachrichten nach einer Beschreibung umformt. Seit Mai 2023 hat sich am Code nichts mehr geändert.
Apache NiFi: wandelt Daten über eine grafische Oberfläche zwischen Formaten wie CSV, JSON und XML um.
MapStruct: erzeugt Java-Code, der Werte von einem Datenobjekt in ein anderes überträgt.

Quellen

Gregor Hohpe, Bobby Woolf: Message Translator: Beschreibung des Musters aus dem Buch Enterprise Integration Patterns. Der Übersetzer steht zwischen Programmen mit verschiedenen Datenformaten und wandelt jede Nachricht in das Format des Empfängers um.
Gregor Hohpe, Bobby Woolf: Canonical Data Model: erklärt das gemeinsame Zwischenformat und rechnet vor, dass es erst ab mehreren Systemen weniger Übersetzer braucht als die direkte Umwandlung, etwa 12 statt 30 bei sechs Systemen.