Correlation Identifier
Eine Kennung verknüpft Antwort und Anfrage
Die Idee und ihr Nutzen
Das Kundenportal einer Versicherung erstellt für eine Kundin einen Preisvergleich und fragt dafür gleichzeitig drei Tarifrechner an, die Preise berechnen: einen für Kfz, einen für Hausrat und einen für Haftpflicht. Die Antworten kommen in einer anderen Reihenfolge zurück, als die Anfragen hinausgegangen sind. Damit das Kundenportal jeden Preis beim richtigen Produkt einträgt, bekommt jede Anfrage eine eindeutige Kennung, etwa die Nummer 43 für die Anfrage an den Tarifrechner für Hausrat. Der Tarifrechner übernimmt die Kennung unverändert in seine Antwort. Eine solche Kennung heißt Correlation Identifier, kurz Correlation ID, auf Deutsch etwa „Kennung zur Zuordnung“.
Wie funktioniert es?
Frau Kaya fordert im Kundenportal einen Preisvergleich für Kfz, Hausrat und Haftpflicht an, und das Kundenportal legt dafür den Vorgang v17 an. Das Kundenportal schickt gleichzeitig drei Anfragen: an den Kfz-Rechner mit der Kennung 42, an den Hausrat-Rechner mit 43 und an den Haftpflicht-Rechner mit 44. Jede Anfrage trägt zusätzlich die Vorgangskennung v17, die alle drei Anfragen dieses Vergleichs gemeinsam haben. Das Kundenportal merkt sich in seiner Liste der offenen Anfragen, dass im Vergleich für Frau Kaya 42 zu Kfz, 43 zu Hausrat und 44 zu Haftpflicht gehört. Nach 200 Millisekunden trifft als Erstes die Antwort des Hausrat-Rechners mit Kennung 43 und einem Preis von 89 Euro im Jahr ein. Das Kundenportal sieht in seiner Liste, dass 43 der Hausratpreis für Frau Kaya ist, und trägt den Preis in ihrem Vergleich beim Hausrat ein. Danach kommt die Antwort mit Kennung 44, und das Kundenportal trägt den Preis ebenso bei Haftpflicht ein. Zuletzt trifft die Antwort des Kfz-Rechners mit Kennung 42 ein, weil der Kfz-Rechner mehr Angaben prüft. Frau Kaya sieht alle drei Preise beim richtigen Produkt, obwohl die Antworten in anderer Reihenfolge eintrafen.
Jedes der vier Programme schreibt außerdem ein eigenes Protokoll, eine fortlaufende Liste von Einträgen darüber, welche Anfragen es wann bearbeitet hat und welche Fehler dabei auftraten. Eine Woche später meldet ein anderer Kunde, dass in seinem Vergleich der Kfz-Preis fehlte. Der Support sucht in den Protokollen aller vier Programme nach der Vorgangskennung dieses Vergleichs. In wenigen Minuten findet er einen Eintrag des Kfz-Rechners: Der Kfz-Rechner hat die Berechnung wegen einer fehlenden Angabe abgebrochen.
Kundenportal, Kfz-Rechner, Hausrat-Rechner und Haftpflicht-Rechner sind eigenständige Programme, die über das Netz Nachrichten austauschen. Das Kundenportal wartet nicht auf eine Antwort, bevor es die nächste Anfrage stellt, damit Frau Kaya nicht dreimal warten muss. Alle Antworten treffen am selben Eingang des Kundenportals ein, gleichgültig, von welchem Tarifrechner und zu welchem Vergleich sie stammen. Das Kundenportal erzeugt die Correlation ID. In der Praxis ist sie meist eine lange Zufallsfolge, hier vereinfacht die Nummern 42, 43 und 44. Das Kundenportal schreibt die Kennung in die Kopfzeilen der Anfrage. Kopfzeilen sind Zusatzangaben, die neben dem eigentlichen Inhalt einer Nachricht mitgeschickt werden. Jeder Tarifrechner hat dabei nur eine Aufgabe: Er übernimmt die Kennung unverändert in seine Antwort, ohne verstehen zu müssen, was sie bedeutet. Hat das Kundenportal eine Antwort zugeordnet, streicht es die Kennung aus der Liste der offenen Anfragen.
Die Vorgangskennung v17 hat eine andere Aufgabe als die Kennungen 42, 43 und 44. Über die Kennungen der Anfragen ordnet das Kundenportal jede Antwort ihrer Anfrage zu. Die Vorgangskennung verbindet alle Protokolleinträge des ganzen Vergleichs, denn jedes Programm schreibt sie in jeden Protokolleintrag, der zu diesem Vorgang gehört.
Trifft eine Antwort nie ein, bleibt ihre Kennung in der Liste der offenen Anfragen stehen. Das Kundenportal streicht sie nach einer festgelegten Frist und zeigt beim betroffenen Produkt einen Hinweis statt eines Preises. Eine fehlende Antwort heißt dabei nicht, dass der Tarifrechner nicht gerechnet hat. Seine Antwort kann auch unterwegs verloren gegangen sein. Manchmal trifft eine Antwort erst ein, wenn ihre Kennung nicht mehr in der Liste steht, etwa nach Ablauf der Frist. Eine solche Antwort verwirft das Kundenportal. Die Kennung sagt dem Kundenportal nur, zu welcher Anfrage eine Antwort gehört. Ob der Preis eines Tarifrechners richtig ist, sagt sie nicht.
Korrelationskennung: drei Tarifantworten richtig zuordnen
Wann ist es sinnvoll und wann nicht?
Eine Correlation ID lohnt sich
- Mehrere Anfragen sind gleichzeitig unterwegs, und ihre Antworten können in beliebiger Reihenfolge zurückkommen. Ohne Kennung weiß das Kundenportal nicht, welche der eintreffenden Antworten zu welcher Anfrage gehört. Das Kundenportal könnte dann den Hausratpreis von 89 Euro bei Kfz eintragen.
- Die Antworten vieler gleichzeitiger Vorgänge treffen am selben Eingang ein. Ein Beispiel sind die Vergleiche für Hunderte Kundinnen und Kunden, die das Kundenportal gleichzeitig erstellt. Ohne Kennung könnte das Kundenportal den Kfz-Preis eines anderen Kunden im Vergleich von Frau Kaya eintragen.
- Eine Anwendung besteht aus mehreren Programmen, deren Protokolle bei der Fehlersuche zusammengeführt werden sollen. Ohne gemeinsames Merkmal lässt sich nicht erkennen, welche Einträge in den vier Protokollen zu einem bestimmten Vergleich gehören. Mit der Vorgangskennung findet der Support den Eintrag zum Abbruch des Kfz-Rechners in wenigen Minuten, statt vier Protokolle von Hand abzugleichen.
Eine Correlation ID ist nicht das Richtige
- Das Kundenportal fragt nur einen einzigen Tarifrechner und wartet auf dessen Antwort, bevor es weitermacht. Dann kommt die Antwort über dieselbe Verbindung zurück, über die das Kundenportal gefragt hat, und gehört damit eindeutig zu dieser Anfrage. Das Kundenportal braucht keine Kennung für die Zuordnung und keine Liste offener Anfragen. Bei drei Tarifrechnern würde dieses Warten für Frau Kaya allerdings so lange dauern wie alle drei Tarifrechner zusammen.
- Ein Tarifrechner eines anderen Unternehmens gibt Kennungen aus den Kopfzeilen nicht zurück, und die Versicherung kann ihn nicht ändern. Eine Correlation ID in den Kopfzeilen käme dann nie zurück, und das Kundenportal könnte keine Antwort dieses Tarifrechners zuordnen. Stattdessen ordnet das Kundenportal die Antwort über eine fachliche Angabe zu, die der fremde Tarifrechner ohnehin in seine Antwort schreibt, etwa die Angebotsnummer aus der Anfrage. Das Kundenportal merkt sich dafür in seiner Liste der offenen Anfragen, welche Angebotsnummer zu welchem Produkt gehört. Eine Änderung am fremden Tarifrechner ist dafür nicht nötig.
- Es geht nur um die Fehlersuche, und das Kundenportal muss keine Antworten zuordnen. Die Kennungen 42, 43 und 44 und die Liste der offenen Anfragen braucht dann niemand. Stattdessen richtet die Versicherung Distributed Tracing ein, das auf derselben Idee einer mitgereichten Kennung beruht. Ein Werkzeug dafür gibt jeder Anfrage selbst eine Kennung mit, reicht sie vom Kundenportal an jeden Tarifrechner weiter und misst zusätzlich, wie lange jeder Schritt dauert. Die Teams müssen die Vorgangskennung dann nicht selbst in jeden Protokolleintrag schreiben.
Nachteile und typische Fehler
Die Kennung muss wirklich überall weitergegeben werden. Jeder Tarifrechner muss sie in seine Antwort übernehmen, und jedes Programm muss die Vorgangskennung in seine Protokolleinträge schreiben. Das ist eine Vereinbarung zwischen den Teams des Kundenportals und der drei Tarifrechner, die bei jedem neuen Programm eingehalten werden muss. Das Kundenportal muss außerdem die Liste der offenen Anfragen führen. Läuft das Kundenportal auf mehreren Servern, läuft auf jedem Server ein Exemplar desselben Kundenportals, und jedes Exemplar führt seine eigene Liste der offenen Anfragen. Die Antwort muss dann bei dem Exemplar ankommen, das sich die Kennung gemerkt hat, oder die Liste muss in einem gemeinsamen Speicher liegen, den alle Exemplare erreichen.
Typische Fehler und woran man sie erkennt:
- Kennung fehlt in der Antwort: Ein Tarifrechner übernimmt die Kennung nicht in seine Antwort, und das Kundenportal kann die Antwort keiner Anfrage zuordnen. Erkennbar ist das an Antworten ohne Kennung im Protokoll des Kundenportals und an Vergleichen, in denen immer derselbe Preis fehlt.
- Kennung nicht eindeutig: Das Kundenportal vergibt Kennungen aus einem Zähler, der nach einem Neustart wieder bei 1 beginnt. Vor einem Neustart fragt das Kundenportal den Kfz-Rechner mit Kennung 42 an. Nach dem Neustart vergibt das Kundenportal die 42 erneut, für die Hausrat-Anfrage eines anderen Kunden. Die verspätete Antwort des Kfz-Rechners mit Kennung 42 trifft ein, und das Kundenportal trägt den Kfz-Preis als Hausratpreis des anderen Kunden ein. Erkennbar ist das an Preisen, die nicht zum angefragten Produkt oder Kunden passen.
- Wachsende Liste offener Anfragen: Das Kundenportal streicht Kennungen unbeantworteter Anfragen nie, und die Liste wächst unbegrenzt. Erkennbar ist das an steigendem Speicherverbrauch des Kundenportals über Tage hinweg.
- Vertrauliche Kennung: Das Kundenportal verwendet die Kundennummer als Vorgangskennung. Jedes der vier Programme schreibt die Vorgangskennung in seine Protokolleinträge, und diese Protokolle können viele Menschen lesen. Kennungen dürfen deshalb keine vertraulichen Angaben enthalten. Erkennbar ist der Fehler an Kundennummern in Protokollen, die nicht für Kundendaten freigegeben sind.
- Nur Vorgangskennung vergeben: Das Kundenportal gibt allen drei Anfragen nur v17 mit und kann die Antworten nicht auseinanderhalten. Das Kundenportal trägt die Antworten dann in der Reihenfolge ein, in der es gefragt hat: die erste Antwort bei Kfz, die zweite bei Hausrat, die dritte bei Haftpflicht. Die Antwort des Hausrat-Rechners trifft aber zuerst ein, und ihr Preis von 89 Euro steht dann bei Kfz. Erkennbar ist das an vertauschten Preisen zwischen Kfz, Hausrat und Haftpflicht.
Weiterführend
Verwandte Ansätze
- Request Reply: beschreibt den Austausch von Anfrage und Antwort über Nachrichten und nutzt die Kennung, um Antworten zuzuordnen.
- Aggregator: sammelt zusammengehörige Nachrichten und erkennt sie an einer gemeinsamen Kennung.
- Observability: verbindet Protokolle, Messwerte und Ablaufspuren über gemeinsame Kennungen, sodass das Betriebsteam alle Angaben zu einem Vorgang zusammen sieht.
Werkzeuge und Umsetzungen
- Apache Camel: ordnet bei Anfragen über Nachrichtenkanäle die Antworten automatisch über eine Kennung den Anfragen zu.
- Spring Integration: kann bei bestimmten Bausteinen Anfrage und Antwort automatisch zuordnen. Bei selbst gebauten Nachrichtenwegen muss die Anwendung die Kennung selbst mitführen und auswerten.
Quellen
- Gregor Hohpe, Bobby Woolf: Enterprise Integration Patterns, Correlation Identifier: Originalbeschreibung des Musters. Der Anfragende vergibt eine eindeutige Kennung, der Antwortende kopiert sie in seine Antwort.
- RabbitMQ: Remote procedure call (RPC): Projektdokumentation, die zeigt, wie ein Programm jeder Anfrage eine eindeutige Kennung mitgibt, Antworten über einen gemeinsamen Antwortkanal zuordnet und Antworten mit unbekannter Kennung verwirft.