Aggregator
Zusammengehörige Nachrichten bündeln
Die Idee und ihr Nutzen
Bevor eine Versicherung einen Kfz-Schaden bezahlt, prüfen ihn drei Beteiligte: Die Deckungsprüfung stellt fest, ob der Vertrag den Schaden abdeckt, die Betrugsprüfung sucht nach Auffälligkeiten, und ein Gutachter schätzt die Schadenhöhe. Jeder der drei schickt sein Ergebnis als eigene Nachricht, sobald er fertig ist, und die drei Nachrichten treffen zu verschiedenen Zeitpunkten ein. Das Programm, das über die Zahlung entscheidet, heißt „Freigabe“ und braucht alle drei Ergebnisse zusammen. Ein zusätzlicher Baustein sammelt deshalb die Ergebnisse desselben Schadens und gibt sie gemeinsam an die „Freigabe“ weiter, sobald alle da sind. Fehlt nach einer festgelegten Frist noch ein Ergebnis, gibt der Baustein die vorhandenen Ergebnisse an einen Sachbearbeiter weiter, damit kein Schaden unbegrenzt liegen bleibt. Dieser Baustein heißt Aggregator.
Wie funktioniert es?
Für den Kfz-Schaden mit der Schadennummer 4711 beginnen die drei Prüfungen gleichzeitig, aber sie dauern unterschiedlich lange. Nach wenigen Sekunden meldet die Deckungsprüfung „gedeckt“ mit der Schadennummer 4711. Der Aggregator legt daraufhin die Gruppe 4711 an, in der er alle Ergebnisse zu diesem Schaden sammelt, und speichert den Stand „1 von 3“ im Zwischenspeicher. Der Zwischenspeicher hält die halb gesammelte Gruppe fest, damit sie einen Neustart des Aggregators übersteht. Nach einer Minute meldet die Betrugsprüfung „unauffällig“ mit derselben Schadennummer, und der Aggregator speichert den Stand „2 von 3“. Nach 20 Minuten liefert der Gutachter seine Schätzung der Schadenhöhe: 3.400 Euro. Damit ist die Gruppe 4711 vollständig. Der Aggregator schickt der „Freigabe“ die Nachricht „Prüfung abgeschlossen“ mit allen drei Ergebnissen, und die „Freigabe“ bereitet die Zahlung vor.
Die Deckungsprüfung und die Betrugsprüfung sind Programme, die die Versicherung selbst betreibt. Der Gutachter arbeitet als externer Dienstleister. Alle drei schicken ihre Ergebnisse über ein Nachrichtensystem. Eine Nachricht ist dabei ein Datenpaket, das ein Programm einem anderen über das Nachrichtensystem schickt, ohne auf eine Antwort zu warten. Weil viele Schäden gleichzeitig geprüft werden, treffen die Nachrichten verschiedener Schäden durcheinander beim Aggregator ein. Der Aggregator ist ein eigenes Programm oder ein eigener Baustein innerhalb eines Programms. Er arbeitet nach drei Regeln, die das Team festlegt, das den Aggregator entwickelt. Die erste Regel betrifft die Zuordnung: Jede Nachricht enthält die Schadennummer als gemeinsame Kennung, und der Aggregator legt jede Nachricht in die Gruppe mit derselben Nummer. Ohne diese Kennung könnte der Aggregator die Ergebnisse verschiedener Schäden nicht auseinanderhalten. Die zweite Regel legt fest, wann eine Gruppe vollständig ist: wenn von der Deckungsprüfung, der Betrugsprüfung und dem Gutachter je ein Ergebnis vorliegt. Zur zweiten Regel gehört auch die Frist von 30 Minuten ab der ersten Nachricht. Der Gutachter braucht für eine Schätzung meist 10 bis 25 Minuten; die Frist lässt ihm diese Zeit, ohne dass ein Schaden lange liegen bleibt. Die dritte Regel legt fest, wie der Aggregator aus den gesammelten Ergebnissen die Gesamtnachricht „Prüfung abgeschlossen“ bildet. Über die Zahlung entscheidet der Aggregator nicht, und den Gutachter macht er nicht schneller. Ob alle drei Ergebnisse eintreffen, kann der Aggregator nicht beeinflussen.
Fehlt die Gutachterschätzung 30 Minuten nach der ersten Nachricht noch, wartet der Aggregator nicht länger. Er gibt die beiden vorhandenen Ergebnisse mit dem Vermerk „Gutachterschätzung fehlt“ an einen Sachbearbeiter, der unvollständige Fälle klärt. Der Sachbearbeiter fragt beim Gutachter nach oder entscheidet selbst. Kommt dieselbe Nachricht wegen einer Störung zweimal an, erkennt der Aggregator das daran, dass in der Gruppe schon ein Ergebnis desselben Absenders liegt, und zählt die Nachricht nur einmal. Nach dem Versand der Gesamtnachricht oder des Vermerks ist die Gruppe abgeschlossen. Für ein Ergebnis, das erst danach eintrifft, legt das Team, das den Aggregator entwickelt, eine eigene Regel fest, etwa dass der Aggregator das Ergebnis dem Sachbearbeiter nachreicht.
Aggregator: drei Prüfergebnisse zu Schaden 4711 sammeln
Wann ist es sinnvoll und wann nicht?
Ein Aggregator lohnt sich
- Teilergebnisse treffen zu verschiedenen Zeitpunkten und in beliebiger Reihenfolge als einzelne Nachrichten ein. Sie dürfen erst gemeinsam weiterverarbeitet werden.
- Das Programm, das die Ergebnisse braucht, soll nicht selbst sammeln. Ohne Aggregator müsste die „Freigabe“ erkennen, welche Nachrichten zum selben Schaden gehören, ob noch eine fehlt und wie lange sich das Warten lohnt. Entschiede die „Freigabe“ schon nach der ersten Nachricht, fehlten ihr zwei Prüfergebnisse.
- Mehrere Programme brauchen dieselben gesammelten Ergebnisse. Ohne Aggregator enthielte jedes dieser Programme eigene Sammelregeln, und jede dieser Sammelregeln könnte eigene Fehler bei Fristen und doppelt zugestellten Nachrichten enthalten. Mit Aggregator sind Zuordnung, Frist und der Umgang mit doppelten Nachrichten einmal programmiert und getestet.
- Ein vorheriger Schritt hat eine Aufgabe aufgeteilt, und die Teile gehören nach der Bearbeitung wieder zusammen. Beim Scatter Gather wird zum Beispiel eine Anfrage an mehrere Empfänger verteilt. Ebenso kann eine große Nachricht in Einzelteile zerlegt worden sein.
- Deckungsprüfung, Betrugsprüfung und Gutachter sollen voneinander unabhängig bleiben. Keiner der drei muss auf die anderen warten.
Ein Aggregator ist nicht das Richtige
- Deckungsprüfung, Betrugsprüfung und Gutachter antworten alle schnell. Dann kann die „Freigabe“ die drei direkt aufrufen und auf die Antworten warten, also synchron kommunizieren. Die drei Ergebnisse liegen dann im selben Programmlauf vor, und es gibt keinen Zwischenstand zu speichern.
- Jedes Ergebnis wird unabhängig von den anderen verarbeitet. Das Ergebnis der Betrugsprüfung geht zum Beispiel nur in eine Statistik ein. Das Sammeln würde diese Verarbeitung nur verzögern.
- Die Prüfungen hängen voneinander ab, oder ein Programm muss den ganzen Ablauf mit seinen Entscheidungen steuern. Ein Gutachter wird zum Beispiel erst beauftragt, nachdem die Deckungsprüfung „gedeckt“ gemeldet hat. Dafür gibt es die Orchestration, bei der ein Steuerprogramm die Prüfungen der Reihe nach beauftragt und ihre Ergebnisse selbst auswertet.
Nachteile und typische Fehler
Der Aggregator ist ein zusätzlicher Baustein, der sich Zwischenstände merken muss. Ein Programm, das Nachrichten nur weiterleitet, braucht keinen eigenen Speicher. Der Aggregator braucht dagegen einen dauerhaften Zwischenspeicher, meist eine Datenbank, die betrieben, gesichert und von abgeschlossenen Gruppen bereinigt werden muss. Die Länge der Frist ist eine fachliche Entscheidung: Ist die Frist zu kurz, landen viele Fälle unnötig beim Sachbearbeiter; ist sie zu lang, warten Kunden länger auf ihr Geld. Außerdem hängt der Aggregator vom Aufbau der Nachrichten ab. Deckungsprüfung, Betrugsprüfung und Gutachter müssen die Schadennummer mitschicken, und ändert einer der drei das Format seiner Nachricht, muss auch der Aggregator angepasst werden.
Typische Fehler und woran man sie erkennt:
- Verlorene Zwischenstände: Der Aggregator hält seine Zwischenstände nur im Arbeitsspeicher und stürzt ab. Die bereits eingetroffenen Teilergebnisse gehen verloren, und die betroffenen Fälle bleiben unvollständig. Erkennbar ist das an Fällen, die nach einem Neustart mit dem Vermerk fehlender Ergebnisse beim Sachbearbeiter landen, obwohl alle drei Beteiligten ihr Ergebnis geschickt haben.
- Keine Frist: Der Aggregator hat keine Frist, und Gruppen warten unbegrenzt auf Nachrichten, die nie kommen. Die Zahl offener Gruppen wächst, bis der Speicher voll ist. Erkennbar ist das an einer stetig steigenden Zahl offener Gruppen und an Schäden, die tagelang ohne Entscheidung bleiben.
- Doppelt gezählte Nachricht: Der Aggregator erkennt doppelt zugestellte Nachrichten nicht. Er hält eine Gruppe dann womöglich für vollständig, obwohl ein Ergebnis fehlt, weil ein anderes doppelt gezählt wurde. Erkennbar ist das an Gesamtnachrichten „Prüfung abgeschlossen“, in denen etwa das Ergebnis der Betrugsprüfung zweimal und die Gutachterschätzung gar nicht steht.
- Aufgeteilte Gruppe: Mehrere Exemplare des Aggregators laufen gleichzeitig, also dasselbe Programm mehrfach nebeneinander. Die Exemplare nutzen keinen gemeinsamen Zwischenspeicher, und die Nachrichten zu Schaden 4711 kommen nicht alle beim selben Exemplar an. Jedes Exemplar sammelt dann nur einen Teil und gibt nach Ablauf der Frist eine unvollständige Gruppe weiter. Erkennbar ist das an zwei Vermerken zum selben Schaden, in denen jeweils andere Ergebnisse fehlen.
- Verspätetes Ergebnis ohne Regel: Die Gutachterschätzung trifft erst nach Ablauf der Frist ein, und für diesen Fall gibt es keine Regel. Der Aggregator legt für die Gutachterschätzung eine neue Gruppe an oder verwirft sie stillschweigend. Erkennbar ist das an Sachbearbeitern, die beim Gutachter nach einer Schätzung fragen, die er längst geschickt hat.
Weiterführend
Verwandte Ansätze
- Correlation Identifier: beschreibt die gemeinsame Kennung, an der zusammengehörige Nachrichten erkannt werden, beim Aggregator die Schadennummer.
- Idempotency: sorgt dafür, dass eine doppelt zugestellte Nachricht nicht doppelt wirkt.
- Messaging: beschreibt den Austausch von Nachrichten, auf dem der Aggregator aufbaut.
Werkzeuge und Umsetzungen
- Apache Camel: enthält den Aggregator als fertigen Baustein. Zuordnungskennung, Vollständigkeitsregel, Frist und Zusammenführung werden eingestellt; für die Zwischenstände lässt sich ein dauerhafter Speicher anschließen.
- Spring Integration: enthält einen Aggregator für Java-Anwendungen. Die Zwischenstände legt dieser Aggregator in einem austauschbaren Nachrichtenspeicher ab, zum Beispiel in einer Datenbank.
- Apache Flink: verarbeitet fortlaufende Datenströme und kann Ereignisse mit demselben Schlüssel, etwa derselben Schadennummer, innerhalb eines Zeitfensters zusammenfassen. Flink eignet sich vor allem für große Datenmengen; für wenige Geschäftsvorfälle ist es meist mehr Technik als nötig.
Quellen
- Gregor Hohpe, Bobby Woolf: Aggregator: beschreibt das Muster aus dem Buch Enterprise Integration Patterns mit Zuordnung, Vollständigkeitsbedingung und Zusammenführung sowie verschiedenen Strategien für Fristen.
- Apache Camel: Aggregate EIP: Projektdokumentation eines fertigen Aggregators mit Zuordnungsschlüssel, Abschlussbedingungen wie Anzahl oder Frist und austauschbarem, auch dauerhaftem Speicher für die Zwischenstände.