Content Based Routing
Nachrichten nach ihrem Inhalt weiterleiten
Die Idee und ihr Nutzen
Über das Schadenportal einer Versicherung gehen täglich rund 4.000 Schadenmeldungen ein, und je nach Inhalt ist ein anderes Team oder Programm zuständig: Meldungen mit verletzten Personen gehen an ein Spezialteam, kleine Hagelschäden bis 2.000 Euro an eine automatische Bearbeitung, alle übrigen an die allgemeine Sachbearbeitung. Die Grenze von 2.000 Euro hat die Fachabteilung gewählt, weil Hagelschäden bis zu dieser Höhe fast immer ohne Rückfrage bezahlt werden. Statt dass das Schadenportal diese Zuständigkeiten kennen muss, schickt es jede Meldung an ein eigenständiges Verteilprogramm, den sogenannten Router. Der Router liest Angaben wie „Person verletzt“, „Schadenart“ und „Betrag“ aus der Meldung, prüft sie der Reihe nach mit diesen Zuständigkeitsregeln und leitet die Meldung an das zuständige Team oder Programm weiter. Ändert die Fachabteilung eine Zuständigkeit, wird nur eine Regel im Router geändert, nicht das Schadenportal. Dieses Weiterleiten nach dem Inhalt heißt Content Based Routing.
Wie funktioniert es?
Ein Kunde meldet über das Schadenportal einen Hagelschaden von 1.400 Euro an seinem Auto. Verletzt ist niemand. Das Schadenportal legt die Meldung in den Eingangskanal, eine Ablage, in der alle neuen Meldungen gesammelt werden. Das Schadenportal weiß nicht, wer die Meldung bearbeitet. Der Router holt die Meldung aus dem Eingangskanal und prüft seine Regeln in fester Reihenfolge. Er liest „Person verletzt: nein“, die erste Regel für verletzte Personen trifft also nicht zu. Dann liest er „Schadenart: Hagel“ und „Betrag: 1.400 Euro“, und die zweite Regel für Hagelschäden bis 2.000 Euro trifft zu. Der Router legt die Meldung unverändert in den Kanal der automatischen Bearbeitung. In der automatischen Bearbeitung prüft ein Programm den Vertrag und bereitet die Zahlung vor, ohne dass ein Mensch eingreift. Am selben Tag legt das Schadenportal die Meldung eines Auffahrunfalls in den Eingangskanal. Bei dem Unfall wurde die Fahrerin verletzt, der Sachschaden beträgt 900 Euro. Der Router holt die zweite Meldung und liest „Person verletzt: ja“. Schon die erste Regel trifft zu, und der Router schickt die Meldung an das Spezialteam, ohne Schadenart und Betrag noch zu prüfen.
Das Schadenportal und die Programme, mit denen die zuständigen Teams arbeiten, sind getrennt und werden von verschiedenen Entwicklungsteams gepflegt. Sie tauschen die Meldungen über eine Nachrichtenplattform aus. Das ist ein Programm, das Datenpakete von einem Programm entgegennimmt und für ein anderes bereithält. Solche Datenpakete heißen Nachrichten. Auf der Nachrichtenplattform laufen die Nachrichten über Kanäle. Ein Kanal ist eine benannte Ablage, in die ein Programm Nachrichten legt und aus der ein anderes Programm sie abholt. Das Schadenportal kennt nur den gemeinsamen Eingangskanal. Jedes der drei Ziele hat einen eigenen Ausgangskanal: das Spezialteam, die automatische Bearbeitung und die allgemeine Sachbearbeitung. Jede Schadenmeldung enthält dieselben Felder, darunter „Person verletzt“, „Schadenart“ und „Betrag“, und der Router liest genau diese Felder. Welche Meldung wohin gehört, legt die Fachabteilung fest. Das Team, das den Router betreut, pflegt die Verteilregeln im Router. Der Router entscheidet nur, wer eine Meldung bekommt. Ob ein Schaden bezahlt wird, entscheidet weiterhin das Programm oder Team, das die Meldung erhält.
Bei der Reparatur eines kleinen Hagelschadens fällt ein Dachdecker vom Dach und verletzt sich. Für die Meldung dieses Schadens treffen zwei Regeln zu. Weil die Regel für verletzte Personen zuerst geprüft wird, geht die Meldung an das Spezialteam und nicht an die automatische Bearbeitung. Trifft keine Regel zu, geht die Meldung an die allgemeine Sachbearbeitung. So geht jede Meldung an genau ein Ziel. Manchmal fehlt in einer Meldung eine Angabe, die der Router prüfen muss. Ein Beispiel ist eine Meldung, in der die Angabe „Person verletzt“ fehlt. Für solche Meldungen braucht der Router ein festes Ziel, etwa einen eigenen Fehlerkanal, den die allgemeine Sachbearbeitung täglich prüft. Sonst bleiben solche Meldungen unbemerkt liegen oder gehen verloren.
Content Based Routing: jede Meldung zum richtigen Team
Wann ist es sinnvoll und wann nicht?
Content Based Routing lohnt sich
- Viele gleich aufgebaute Nachrichten müssen je nach Inhalt verschieden behandelt werden. Schickt das Schadenportal jede Meldung an alle Teams und sortiert jedes Team selbst aus, was nicht zu ihm gehört, erhält jedes Team alle 4.000 Meldungen und verwirft den Großteil. Die Regeln stehen dann verstreut in den Programmen aller Teams, und ob jede Meldung bei genau einem Team ankommt, kann niemand zentral prüfen. Mit dem Router prüft das Team, das den Router betreut, mit Beispielmeldungen, ob jede Meldung bei genau einem Ziel ankommt.
- Der Absender soll die Empfänger und deren Zuständigkeiten nicht kennen. Entscheidet das Schadenportal selbst, wohin eine Meldung geht, muss es alle Teams und alle Zuständigkeitsregeln kennen.
- Zuständigkeiten ändern sich häufiger als die Erfassung der Meldung. Ohne Router erfordert dann jede neue Betragsgrenze eine Änderung am Schadenportal. Mit Router genügt eine geänderte Regel. Hebt die Fachabteilung die Grenze für die automatische Bearbeitung auf 3.000 Euro an, ändert das Team, das den Router betreut, die Regel, testet sie mit Beispielmeldungen und spielt sie ein. Das Schadenportal und die Programme der Teams bleiben unverändert.
Content Based Routing ist nicht das Richtige
- Das Ziel hängt von einer fachlichen Bewertung ab, die viele Angaben abwägt. Ein Beispiel ist eine Betrugsbewertung, die Vorschäden und Schadenhergang einbezieht. Der Router müsste dafür Vorschäden nachschlagen und gegeneinander abwägen, obwohl er nur Felder der Meldung liest. Stattdessen geht die Meldung zuerst an ein eigenes Fachprogramm, das die Bewertung berechnet und das Ergebnis als Feld in die Meldung schreibt, etwa „Betrugsverdacht: ja“. Erst danach erhält der Router die Meldung und liest nur dieses Feld. Die Bewertungsregeln pflegt so das Team des Fachprogramms, und der Router wird nicht zu einem Regelwerk außerhalb der Fachprogramme.
- Mehrere Empfänger brauchen dieselbe Meldung. Ein Beispiel sind die Sachbearbeitung und eine Statistik. Der Router gibt jede Meldung aber nur an genau ein Ziel. Stattdessen legt das Schadenportal jede Meldung in einen Kanal, aus dem die Nachrichtenplattform jedem angemeldeten Empfänger eine eigene Kopie zustellt. Dieses Vorgehen heißt Publish Subscribe. Die Sachbearbeitung bearbeitet ihre Kopie, und die Statistik zählt ihre Kopie.
- Es gibt nur einen einzigen Empfänger. Dann legt das Schadenportal jede Meldung direkt in den Kanal dieses Empfängers. Ein Router, der betrieben und überwacht werden muss und dabei nichts zu entscheiden hätte, entfällt.
- Die Zuständigkeiten ändern sich selten, und das Schadenportal darf sie kennen. Mit einem Router ließe sich eine Regel ändern, ohne das Schadenportal zu ändern, aber solche Änderungen kommen dann kaum vor. Dann baut das Entwicklungsteam des Schadenportals die Verteilregeln ins Schadenportal ein. Das Schadenportal legt jede Meldung direkt in den Kanal des zuständigen Teams. Ein eigenes Programm, das betrieben, überwacht und gepflegt werden muss, entfällt. Ändert sich eine Zuständigkeit, muss das Entwicklungsteam des Schadenportals allerdings das Schadenportal ändern.
Nachteile und typische Fehler
Der Router ist ein zusätzliches Programm, das betrieben, überwacht und bei jeder Änderung der Zuständigkeiten gepflegt und getestet werden muss. Er muss den Aufbau der Nachrichten kennen. Ändert sich dieser Aufbau, muss auch der Router angepasst werden. Baut das Team, das den Router betreut, immer mehr fachliche Regeln in den Router ein, etwa Teile einer Betrugsbewertung, stehen fachliche Entscheidungen in zwei Programmen. Bei einer fachlichen Änderung müssen dann das Team des Routers und das Team des Fachprogramms ihre Programme ändern und gemeinsam testen. Die beteiligten Teams müssen deshalb festlegen, welche Entscheidungen in den Router gehören und welche in die Fachprogramme. In den Router gehört nur die Wahl des Ziels.
Typische Fehler und woran man sie erkennt:
- Falsche Reihenfolge der Regeln: Das Team, das den Router betreut, setzt eine neue Regel für Hagelschäden vor die Regel für verletzte Personen. Der Router prüft bei der Meldung des verletzten Dachdeckers dann zuerst die neue Hagelregel. Die Hagelregel trifft zu, und der Router legt die Meldung in den Kanal der automatischen Bearbeitung, obwohl ein Mensch verletzt ist. Erkennbar ist das an Meldungen mit Verletzten, die in der automatischen Bearbeitung auftauchen.
- Ausfall des Routers: Der Router fällt aus, und alle Meldungen bleiben im Eingangskanal liegen. Erkennbar ist das an einem wachsenden Eingangskanal, während bei allen Teams keine neuen Meldungen eintreffen.
- Kein Ziel für unvollständige Meldungen: Für Meldungen, denen eine geprüfte Angabe fehlt, gibt es keinen Fehlerkanal. Der Router holt eine Meldung, in der die Angabe „Person verletzt“ fehlt. Die erste Regel lässt sich nicht prüfen, und der Router bricht die Bearbeitung dieser Meldung ab, ohne sie in einen Kanal zu legen. Kein Team erhält die Meldung. Erkennbar ist das an Kunden, die nachfragen, obwohl ihre Meldung im Schadenportal als abgeschickt gilt.
- Umbenanntes Feld: Das Entwicklungsteam des Schadenportals benennt in einer neuen Version das Feld „Person verletzt“ um. Der Router findet das Feld danach in keiner Meldung mehr. Wertet der Router die fehlende Angabe als „nein“, gehen auch Meldungen mit Verletzten an die automatische Bearbeitung oder die allgemeine Sachbearbeitung. Behandelt der Router die fehlende Angabe als Fehler, landen alle Meldungen im Fehlerkanal. Erkennbar ist das daran, dass nach einer neuen Version des Schadenportals das Spezialteam keine Meldungen mehr erhält oder sich der Fehlerkanal plötzlich füllt.
Weiterführend
Verwandte Ansätze
- Message Router: der allgemeine Verteiler, der Nachrichten nach irgendeiner Regel weiterleitet. Content Based Routing ist die Form, die nach dem Inhalt entscheidet.
- Messaging: beschreibt Nachrichten und Kanäle. Der Router holt jede Meldung aus dem Eingangskanal und legt sie in einen Ausgangskanal.
- Dead Letter Queue: eine Ablage für Nachrichten, die nicht zugestellt werden können. Eine solche Ablage kann auch Meldungen aufnehmen, die der Router keinem Ziel zuordnen kann.
- Enterprise Service Bus: eine zentrale Vermittlungsplattform, die das Weiterleiten nach Inhalt als eingebaute Funktion enthält.
Werkzeuge und Umsetzungen
- Apache Camel: enthält den Baustein Content Based Router. Die Regeln werden in Java oder in Konfigurationsdateien geschrieben.
- Spring Integration: enthält Router für Java-Anwendungen, die nach dem Inhalt oder nach Zusatzangaben einer Nachricht entscheiden.
- Apache NiFi: Werkzeug mit grafischer Oberfläche für Datenflüsse, in dem Daten nach Merkmalen an verschiedene Ziele weitergeleitet werden.
- RabbitMQ: Nachrichtenplattform, die Nachrichten nach Merkmalen in ihren Kopfzeilen an passende Warteschlangen weiterleitet. Kopfzeilen sind Zusatzangaben, die neben dem eigentlichen Inhalt einer Nachricht mitgeschickt werden. Den eigentlichen Inhalt liest RabbitMQ dabei nicht. Die zu prüfenden Angaben muss der Absender deshalb in die Kopfzeilen schreiben.
Quellen
- Gregor Hohpe, Bobby Woolf: Content-Based Router: Beschreibung des Musters aus dem Buch Enterprise Integration Patterns. Der Router prüft den Inhalt jeder Nachricht und leitet sie in den Kanal des passenden Empfängers. Die Seite warnt auch davor, dass der Router häufig gepflegt werden muss.
- Apache Camel: Choice: Dokumentation des Bausteins, mit dem Apache Camel den Content-Based Router umsetzt. Die Bedingungen werden der Reihe nach geprüft, und die erste zutreffende bestimmt das Ziel.