Saga
Lange Abläufe als Folge lokaler Schritte mit Ausgleich
Die Idee und ihr Nutzen
Nach einem schweren Wasserschaden ist die Wohnung eines Kunden vorübergehend unbewohnbar, und sein Auto steht in der überfluteten Garage. Die Schadenanwendung seiner Versicherung organisiert für Fall 4711 deshalb einen Mietwagen und ein Hotelzimmer. Mietwagenanbieter und Hotel bestätigen die Buchungen in ihren eigenen Systemen. Danach stellt sich heraus, dass der Fall nicht freigegeben werden kann. Die bestätigten Buchungen lassen sich nicht mit einem einzigen Befehl ungeschehen machen, weil sie in fremden Systemen stehen. Die Schadenanwendung führt den Ablauf deshalb als Folge einzelner Schritte und hat für jeden Schritt, der etwas verändert, eine vorab festgelegte Gegenaktion. Im Fall 4711 storniert die Schadenanwendung Hotelzimmer und Mietwagen wieder. Ein solcher Ablauf heißt Saga.
Wie funktioniert es?
Die Schadenanwendung legt den Vorgang mit der Kennung S-4711 an und speichert jeden Stand im Saga-Log, dem Protokoll des Vorgangs. Dann reserviert die Schadenanwendung beim Mietwagenanbieter einen Wagen. Erst nachdem der Mietwagenanbieter „reserviert“ gemeldet hat, bucht die Schadenanwendung das Hotelzimmer, und das Hotel meldet „gebucht“. Anschließend fragt die Schadenanwendung bei der Freigabeprüfung an, ob Fall 4711 freigegeben wird. Die Freigabeprüfung ist das Programm, das über die Freigabe von Schadenfällen entscheidet. Sie lehnt ab, weil der Wasserschaden nicht gedeckt ist. Jetzt gleicht die Schadenanwendung die bestätigten Schritte in umgekehrter Reihenfolge aus. Zuerst storniert die Schadenanwendung das Hotelzimmer. Das Hotel bestätigt die Stornierung, berechnet aber eine Gebühr von 20 Euro. Die Schadenanwendung hält die Gebühr im Saga-Log fest. Danach storniert die Schadenanwendung den Mietwagen. Der Mietwagenanbieter antwortet nicht. Die Schadenanwendung weiß deshalb nicht, ob die Stornierung angekommen ist, und hält den Vorgang offen, statt ihn als erledigt zu markieren. Später sendet die Schadenanwendung die Stornierung mit der Kennung S-4711 erneut. An der Kennung erkennt der Mietwagenanbieter eine doppelt ankommende Stornierung. Scheitern auch weitere Versuche, übernimmt ein Sachbearbeiter den offenen Vorgang.
Innerhalb eines einzigen Systems lässt sich das Rückgängigmachen der Datenbank überlassen: Eine Datenbank bündelt mehrere Änderungen in einer Transaktion. Scheitert eine davon, verwirft die Datenbank auf Befehl alle zusammen, als wäre nichts geschehen. Über die Systeme der Schadenanwendung, des Mietwagenanbieters und des Hotels hinweg gibt es keine gemeinsame Transaktion. Jedes System bestätigt seinen Schritt mit seiner eigenen Transaktion und speichert ihn dauerhaft, bevor der nächste Schritt beginnt. Zu jedem Schritt, der etwas verändert, legt das Team der Schadenanwendung deshalb vorab eine fachliche Gegenaktion fest, die die Wirkung des Schritts so weit wie möglich aufhebt. Eine solche Gegenaktion heißt englisch Compensating Transaction. Zur Reservierung des Mietwagens gehört die Stornierung des Mietwagens, zur Buchung des Hotelzimmers die Stornierung des Hotelzimmers. Die Schadenanwendung steuert den Ablauf und ruft die Anbieter der Reihe nach auf. Nach einem Fehler liest die Schadenanwendung im Saga-Log nach, welche Schritte bestätigt sind und welche Gegenaktionen noch fehlen. Mietwagenanbieter und Hotel kennen den Gesamtvorgang nicht. Jeder Anbieter bestätigt nur seinen eigenen Schritt. Schritte, die sich fachlich gar nicht aufheben lassen, legt das Team der Schadenanwendung an das Ende des Ablaufs. Nach ihnen folgt dann kein Schritt mehr, der scheitern und einen Ausgleich nötig machen könnte.
Eine Gegenaktion stellt nicht unbedingt den ursprünglichen Zustand wieder her, denn sie ist ein neuer Vorgang mit eigenen Folgen, wie die Stornogebühr von 20 Euro. Eine ausbleibende Antwort bedeutet nicht, dass die Stornierung gescheitert ist. Der Mietwagenanbieter kann die Stornierung ausgeführt haben, ohne dass seine Bestätigung angekommen ist. Deshalb muss die wiederholte Stornierung dieselbe Kennung tragen, und der Mietwagenanbieter muss eine zweite Stornierung derselben Reservierung als bereits erledigt beantworten.
Saga: Mietwagen und Hotel buchen, nach gescheiterter Freigabe ausgleichen
Wann ist es sinnvoll und wann nicht?
Eine Saga lohnt sich
- Ein längerer Ablauf erstreckt sich über mehrere eigenständige Systeme oder Dienste, und für seine Schritte gibt es sinnvolle fachliche Gegenaktionen. Beispiele sind Stornierungen, Gutschriften oder Rückbuchungen. Ohne vorab festgelegte Gegenaktionen muss nach der abgelehnten Freigabe von Fall 4711 ein Sachbearbeiter die Buchungen von Hand suchen und stornieren.
- Die beteiligten Systeme gehören verschiedenen Unternehmen oder Teams und bieten keine gemeinsame Transaktion an. Ein Beispiel sind die Systeme von Mietwagenanbieter und Hotel. Keine Datenbanktransaktion der Schadenanwendung kann eine Buchung im System des Hotels zurücknehmen. Mit einer Saga storniert die Schadenanwendung die Buchung über die vorab festgelegte Gegenaktion.
- Ein Vorgang darf Minuten oder Stunden dauern, und die beteiligten Systeme sollen ihre Daten in dieser Zeit nicht für andere Programme sperren. In einer gemeinsamen Transaktion blieben die betroffenen Daten bis zum Ende des Vorgangs gesperrt, und andere Programme müssten so lange warten. In einer Saga bestätigt jedes System seinen Schritt sofort und gibt die Daten damit wieder frei.
- Der Stand jedes Vorgangs soll jederzeit nachvollziehbar sein. Ohne Saga-Log weiß nach einer ausbleibenden Antwort niemand, welche Buchungen noch storniert werden müssen. Das Saga-Log zeigt für Fall 4711, dass das Hotelzimmer storniert ist, eine Gebühr von 20 Euro angefallen ist und die Stornierung des Mietwagens noch offen ist. Bleibt eine Antwort aus, geht der Vorgang nicht verloren.
Eine Saga ist nicht das Richtige
- Alle Änderungen eines Ablaufs liegen in der Datenbank der Schadenanwendung, etwa wenn die Schadenanwendung zu Fall 4711 nur eine Zahlung und einen Vermerk speichert. Dann bündelt das Team der Schadenanwendung die Änderungen in einer gewöhnlichen Datenbanktransaktion. Scheitert eine Änderung, verwirft die Datenbank alle zusammen. Das Team muss deshalb keine Gegenaktionen entwerfen und testen, und andere Programme sehen keine Zwischenstände.
- Ein Schritt lässt sich fachlich gar nicht aufheben und kann nicht ans Ende des Ablaufs gelegt werden. Ein Beispiel: Das Hotel hat nur noch Zimmer, die sich nicht stornieren lassen, und der Kunde braucht das Zimmer, bevor die Freigabe des Falls geprüft ist. Für diese Buchung gibt es keine Gegenaktion, und eine Saga könnte den Ablauf nach einer Ablehnung nicht ausgleichen. Dann entscheidet ein Sachbearbeiter vor der Buchung, ob die Versicherung das Zimmer auch bei einer späteren Ablehnung bezahlt, und bucht das Zimmer von Hand. So steht schon vor der Buchung fest, wer das Zimmer bezahlt.
- Zwischenstände dürfen auf keinen Fall sichtbar werden, weil sie bereits rechtliche Folgen hätten. Ein Beispiel ist eine Zahlung an den Kunden, die im Buchhaltungssystem der Versicherung schon gebucht ist, bevor die Schadenanwendung den Fall freigegeben hat. Eine Saga zeigt solche Zwischenstände, weil jedes System seinen Schritt sofort bestätigt. Gehören alle beteiligten Systeme der Versicherung und unterstützen sie eine gemeinsame Transaktion, bindet das Team der Schadenanwendung sie mit einem Two Phase Commit in eine gemeinsame Transaktion ein. Die Systeme bestätigen ihre Änderungen nur alle zusammen oder gar nicht, und bis dahin sieht kein anderes Programm eine vorläufige Zahlung. Gegenaktionen braucht das Team dann nicht. Weil die Systeme die betroffenen Daten bis zur gemeinsamen Bestätigung sperren, passt das nur für Abläufe, die Sekunden dauern. Für die Systeme von Mietwagenanbieter und Hotel ist das meist nicht möglich, weil sie fremden Unternehmen gehören.
- Der Kunde kann auf Hotel und Mietwagen warten, bis die Freigabe des Falls geprüft ist. Dann stellt das Team der Schadenanwendung den Ablauf um: Die Schadenanwendung fragt zuerst die Freigabeprüfung und bucht Mietwagen und Hotelzimmer erst nach der Freigabe. Eine Ablehnung kommt dann, bevor etwas gebucht ist, und es gibt nichts auszugleichen. Scheitert danach die Hotelbuchung, braucht der Kunde den Mietwagen trotzdem, und die Reservierung bleibt bestehen. Gegenaktionen muss das Team dann nicht entwerfen und testen.
Nachteile und typische Fehler
Für jeden Schritt muss das Team der Schadenanwendung eine Gegenaktion entwerfen, umsetzen und testen. Mit jedem zusätzlichen Schritt wächst die Zahl der möglichen Fehlerfälle, die das Team durchdenken muss. Der Ablauf braucht eindeutige Kennungen, Regeln für Wiederholungen und einen einsehbaren Stand jedes Vorgangs, damit Sachbearbeiter hängengebliebene Vorgänge finden und klären können. Das Saga-Log muss dauerhaft gespeichert sein, damit die Schadenanwendung nach einem eigenen Absturz weiß, wo der Vorgang steht. Während eine Saga läuft, sehen andere Programme Zwischenstände. Ein Beispiel ist eine Hotelbuchung für einen Fall, der später abgelehnt wird. Die Gegenaktionen hängen davon ab, wie die Anbieter Stornierungen annehmen. Ändert das Hotel zum Beispiel den Aufruf für eine Stornierung, muss das Team der Schadenanwendung die Gegenaktion für das Hotelzimmer ändern. Weil die Schadenanwendung den Ablauf steuert, hängt jeder laufende Vorgang an ihr. Fällt die Schadenanwendung aus, ruht der Ablauf, bis sie wieder läuft.
Typische Fehler und woran man sie erkennt:
- Gegenaktion scheitert: Die Schadenanwendung storniert das Hotelzimmer, und das Hotel berechnet dafür eine Gebühr von 20 Euro. Der ursprüngliche Zustand ist damit nur teilweise wiederhergestellt. Lehnt ein Anbieter eine Stornierung ganz ab, bleibt der Vorgang offen, bis ein Sachbearbeiter ihn klärt. Erkennbar ist das an Vorgängen, die lange offen bleiben, und an Folgen wie Gebühren, die im Saga-Log verzeichnet sind.
- Fehlende Antwort als Fehlschlag gedeutet: Die Schadenanwendung reserviert beim Mietwagenanbieter einen Wagen, doch die Antwort des Mietwagenanbieters bleibt aus. Die Schadenanwendung wertet die Reservierung als gescheitert und reserviert einen zweiten Wagen, obwohl die erste Reservierung ausgeführt wurde. Der Mietwagenanbieter führt dann zwei Reservierungen für Fall 4711, das Saga-Log nur eine. Erkennbar ist das an Vorgängen, bei denen das Saga-Log und das System des Mietwagenanbieters verschiedene Stände zeigen.
- Doppelte Stornierung ohne Kennung: Die Schadenanwendung schickt die Stornierung des Mietwagens ohne die Kennung
S-4711. Die Stornierung kommt beim Mietwagenanbieter an, nur seine Bestätigung geht verloren. Die Schadenanwendung wiederholt die Stornierung. Ohne Kennung erkennt der Mietwagenanbieter nicht, dass diese Reservierung schon storniert ist. Der Mietwagenanbieter storniert deshalb eine andere Reservierung desselben Kunden oder berechnet die Stornierung ein zweites Mal. Erkennbar ist das an mehreren Stornierungen für denselben Vorgang beim Mietwagenanbieter. - Falsche Reihenfolge: Die Schadenanwendung schickt dem Kunden die Mitteilung, dass Hotel und Mietwagen gebucht sind, noch vor der Freigabeprüfung. Danach lehnt die Freigabeprüfung den Fall ab, und die Schadenanwendung storniert Hotelzimmer und Mietwagen. Die Mitteilung lässt sich nicht zurücknehmen. Erkennbar ist das an Kundenanfragen zu Buchungen, die bereits storniert sind.
- Verlorener Stand nach Absturz: Die Schadenanwendung speichert den Stand nicht nach jedem Schritt im Saga-Log. Die Schadenanwendung storniert das Hotelzimmer und stürzt ab, bevor sie den Mietwagen storniert. Nach dem Neustart weiß die Schadenanwendung nicht, wie weit der Ausgleich gekommen ist, und storniert den Mietwagen nicht mehr. Der Mietwagen bleibt reserviert. Erkennbar ist das an Buchungen bei Anbietern, zu denen es keinen offenen oder abgeschlossenen Vorgang mehr gibt.
Weiterführend
Verwandte Ansätze
- Compensating Transaction: beschreibt die einzelne Gegenaktion, die die Wirkung eines bestätigten Schritts fachlich aufhebt, wie die Stornierung des Hotelzimmers. Eine Saga verbindet mehrere solcher Gegenaktionen zu einem Ablauf.
- Orchestration: Ein steuerndes Programm ruft die Beteiligten der Reihe nach auf, so wie die Schadenanwendung Mietwagenanbieter und Hotel aufruft.
- Choreography: Die Beteiligten reagieren ohne steuerndes Programm auf Ereignisse der anderen. Auch so lässt sich eine Saga umsetzen, der Gesamtstand ist dann aber schwerer zu überblicken, weil kein einzelnes Programm ihn kennt.
- Idempotency: beschreibt, wie der Mietwagenanbieter eine wiederholte Stornierung an der Kennung
S-4711erkennt und sie kein zweites Mal ausführt.
Quellen
- Chris Richardson: Pattern: Saga: beschreibt die Saga als Folge lokaler Transaktionen mit selbst entworfenen Gegenaktionen, die Steuerung durch ein Programm oder über Ereignisse und die fehlende Abschirmung von Zwischenständen.
- Microsoft: Saga design pattern: vertieft die Unterscheidung zwischen ausgleichbaren und nicht mehr aufhebbaren Schritten, die Folgen sichtbarer Zwischenstände und die Notwendigkeit, wiederholte Schritte ohne zusätzliche Wirkung auszuführen.