Compensating Transaction
Einen abgeschlossenen Schritt fachlich rückgängig machen
Die Idee und ihr Nutzen
Weil die Trocknung schnell beginnen muss, beauftragt eine Versicherung nach einem Wasserschaden sofort einen Trocknungsbetrieb und reserviert für die betroffene Familie ein Hotelzimmer, noch bevor feststeht, ob der Vertrag den Schaden abdeckt. Danach stellt die Deckungsprüfung der Versicherung fest, dass der Vertrag gekündigt war. Die beiden Partner haben Auftrag und Reservierung zu diesem Zeitpunkt bereits angenommen, und die Versicherung kann beides nicht durch eine Änderung in ihrer eigenen Datenbank ungeschehen machen. Stattdessen schickt ihre Ablaufsteuerung, das Programm, das die Schritte des Ablaufs auslöst, neue, ausgleichende Aufträge. Das Hotel erhält „Reservierung aufheben“, der Trocknungsbetrieb „Auftrag stornieren“. Ein solcher ausgleichender Auftrag heißt Compensating Transaction.
Wie funktioniert es?
Am Montagmorgen meldet eine Familie einen Wasserschaden in ihrer Wohnung. Die Ablaufsteuerung der Versicherung beauftragt sofort den Trocknungsbetrieb, und der Trocknungsbetrieb bestätigt mit „Auftrag angenommen“. Von da an plant der Trocknungsbetrieb seine Mitarbeiter ein. Danach reserviert die Ablaufsteuerung beim Hotel drei Nächte für die Familie, und das Hotel bestätigt die Reservierung. Mittags fragt die Ablaufsteuerung die Deckungsprüfung, das Programm der Versicherung, das prüft, ob der Vertrag gilt. Die Deckungsprüfung meldet „Vertrag seit einem Monat gekündigt“; die Versicherung zahlt also nicht. Trocknungsauftrag und Hotelreservierung müssen nun fachlich ausgeglichen werden, und zwar in umgekehrter Reihenfolge, weil spätere Schritte oft auf früheren aufbauen. Hier wurde das Hotelzimmer nur reserviert, weil die Familie während der Trocknung nicht in der Wohnung bleiben kann. Zuerst schickt die Ablaufsteuerung „Reservierung aufheben“ an das Hotel, und das Hotel bestätigt die Stornierung. Dann schickt die Ablaufsteuerung „Auftrag stornieren“ mit der Stornonummer S-17 an den Trocknungsbetrieb. Aufträge von anderen Programmen nimmt der Trocknungsbetrieb über eine Schnittstelle entgegen. Diese Schnittstelle ist gerade nicht erreichbar, und der Versuch scheitert. Zehn Minuten später wiederholt die Ablaufsteuerung die Stornierung mit derselben Stornonummer S-17, damit die Stornierung nicht doppelt wirkt. Nach zehn Minuten ist eine kurze Störung der Schnittstelle meist vorbei, und der Trocknungsbetrieb hat noch keine Mitarbeiter losgeschickt. Jetzt gelingt die Stornierung. Zum Schluss erfährt die Familie, warum die Versicherung nicht zahlt und dass Hotel und Trocknung storniert sind.
Die Ablaufsteuerung löst die Schritte nacheinander aus und vermerkt nach jeder Bestätigung eines Partners, welcher Schritt erledigt ist. Zu jedem Schritt, der sich fachlich ausgleichen lässt, ist im Voraus ein ausgleichender Auftrag festgelegt, kurz Gegenaktion. Zu „Trocknungsbetrieb beauftragen“ gehört „Auftrag stornieren“, zu „Hotelzimmer reservieren“ gehört „Reservierung aufheben“. Zu „Betrag auszahlen“ kann „Rückforderung einleiten“ gehören; ob das Geld tatsächlich zurückkommt, ist damit noch nicht gesichert. Hotel und Trocknungsbetrieb speichern ihre Aufträge in ihren eigenen Systemen, in die die Versicherung nicht eingreifen kann. Jeder Partner legt selbst fest, welche Aufrufe er über seine Schnittstelle anbietet, beim Trocknungsbetrieb „Auftrag annehmen“ und „Auftrag stornieren“. Die Ablaufsteuerung ruft diese Aufrufe auf. Eine gemeinsame Datenbanktransaktion über alle Systeme gibt es nicht. Eine Datenbanktransaktion ist eine Gruppe von Änderungen, die eine Datenbank nur ganz oder gar nicht speichert; innerhalb einer einzigen Datenbank lässt sich eine Änderung so zurücknehmen, solange sie noch nicht endgültig bestätigt ist. Der Ablauf dauert außerdem Stunden, von der Meldung am Montagmorgen bis zur Deckungsprüfung am Mittag, und so lange hält niemand eine Datenbanktransaktion offen, weil sie die betroffenen Daten die ganze Zeit sperrt.
Eine Gegenaktion löscht nichts. Sie ist ein neuer Vorgang, der neben dem ursprünglichen steht: Die Reservierung bleibt in den Unterlagen sichtbar, daneben steht ihre Stornierung. So lässt sich später nachvollziehen, was geschehen ist. Eine Gegenaktion stellt auch nicht den Zustand vor Beginn des Ablaufs wieder her. Sie gleicht nur aus, was die erledigten Schritte bewirkt haben. Manche Schritte lassen sich gar nicht ausgleichen, etwa eine bereits verschickte E-Mail. Für solche Schritte gibt es nur eine nachträgliche Richtigstellung, etwa eine zweite E-Mail. An der gleichbleibenden Stornonummer erkennt der Partner bei einer Wiederholung, dass er diese Stornierung schon erhalten hat. Das ist nötig, weil ein gescheiterter Aufruf nicht in jedem Fall heißt, dass der Partner nichts getan hat: Bleibt nur die Antwort aus, kann die Stornierung beim Trocknungsbetrieb trotzdem angekommen sein. Gelingt eine Gegenaktion auch nach mehreren Versuchen nicht, erhält ein Sachbearbeiter die Aufgabe, den Partner direkt anzurufen.
Ausgleich: Hotel und Trocknung wieder stornieren
Wann ist es sinnvoll und wann nicht?
Eine Compensating Transaction lohnt sich
- Ein Ablauf läuft über mehrere Programme oder externe Partner, und es gibt keine gemeinsame Rücknahme aller Änderungen. Scheitert ein späterer Schritt, müssen die erledigten Schritte mit den Aufrufen aufgehoben werden, die die Partner dafür anbieten. Mit festgelegten Gegenaktionen storniert die Ablaufsteuerung Hotel und Trocknung, sobald die Deckungsprüfung den gekündigten Vertrag meldet, statt dass Aufträge ohne Deckung weiterlaufen.
- Jeder Schritt hat eine fachlich sinnvolle Gegenaktion, die der jeweilige Partner auch anbietet. Der Trocknungsbetrieb bietet zum Beispiel den Aufruf „Auftrag stornieren“ an. Nur dann kann die Ablaufsteuerung jeden erledigten Schritt selbst ausgleichen, ohne dass ein Sachbearbeiter den Partner anrufen muss.
- Schritte müssen aus fachlichen Gründen früh ausgeführt werden, bevor alle Prüfungen abgeschlossen sind. Die Familie bekommt so sofort Hilfe, weil Trocknung und Hotel schon vor der Deckungsprüfung beauftragt werden. Ohne Gegenaktionen müsste die Versicherung mit beiden Aufträgen bis zur Deckungsprüfung am Mittag warten.
Eine Compensating Transaction ist nicht das Richtige
- Alle Änderungen liegen in einer einzigen Datenbank, und der Ablauf dauert nur Sekunden. Die Datenbank kann dann alle Änderungen selbst zurücknehmen, solange sie noch nicht endgültig bestätigt sind. Dann fasst das Entwicklungsteam alle Änderungen in einer Datenbanktransaktion zusammen, und die Datenbank speichert alles oder nichts. Gegenaktionen zu entwerfen, zu bauen und zu testen entfällt.
- Alle beteiligten Datenbanken gehören der Versicherung und unterstützen ein gemeinsames Bestätigungsverfahren. Der Ablauf dauert nur Sekunden. Dann verbindet das Entwicklungsteam die Datenbanken mit einem Two Phase Commit: Zuerst sagen alle Datenbanken zu, dass sie ihre Änderung speichern können. Danach speichern alle Datenbanken gemeinsam, oder alle verwerfen ihre Änderung. Gegenaktionen entfallen, weil keine Änderung gespeichert bleibt, wenn eine andere scheitert. Mit externen Partnern wie dem Hotel geht das meist nicht, weil das Hotel seine Reservierungen in seinem eigenen System speichert.
- Schritte haben Folgen, die sich nicht aufheben lassen. Beispiele sind ausgezahltes Geld und bereits begonnene Handwerksarbeiten. Eine Gegenaktion wie „Rückforderung einleiten“ sichert nicht, dass das Geld zurückkommt. Stattdessen setzt die Versicherung solche Schritte an das Ende des Ablaufs, nach allen Prüfungen. So kommt es nicht zu einer Auszahlung, die die Versicherung danach zurückfordern muss.
- Ein Schritt scheitert nur an einer kurzen Störung. Die Reservierung beim Hotel scheitert zum Beispiel, weil die Schnittstelle des Hotels kurz nicht erreichbar ist. Ein Ausgleich würde dann den Trocknungsauftrag stornieren, obwohl die Reservierung wenige Minuten später gelungen wäre. Stattdessen wiederholt die Ablaufsteuerung den gescheiterten Schritt nach einer Pause mit derselben Auftragsnummer. Der Ausgleich der erledigten Schritte und die Stornogebühren dafür entfallen.
- Die Hilfe kann warten, bis die Deckung geprüft ist. Dann prüft die Versicherung die Deckung zuerst und beauftragt Hotel und Trocknungsbetrieb erst danach. Bei einem gekündigten Vertrag ist dann noch nichts beauftragt, und es gibt nichts auszugleichen. Die Hilfe beginnt aber erst nach der Deckungsprüfung, bei der Familie also erst mittags statt am Montagmorgen.
Nachteile und typische Fehler
Zwischen einem Schritt und seiner Gegenaktion sind die Zwischenstände für andere sichtbar. Das Hotel kann das Zimmer in dieser Zeit anderen Gästen verweigern, obwohl die Reservierung gleich wieder aufgehoben wird. Jede Gegenaktion muss wie ein eigener Geschäftsvorgang gebaut und getestet werden, einschließlich ihrer Wiederholung. Gegenaktionen können Kosten verursachen, etwa Stornogebühren des Hotels oder eine Ausfallpauschale des Trocknungsbetriebs. Die Ablaufsteuerung muss den Fortschritt jedes Ablaufs dauerhaft speichern, damit sie nach einem Absturz feststellen kann, welche Schritte erledigt sind und welche Gegenaktionen noch fehlen.
Typische Fehler und woran man sie erkennt:
- Gegenaktion endgültig gescheitert: Die Stornierung beim Trocknungsbetrieb gelingt auch nach vielen Versuchen nicht, und niemand wird benachrichtigt. Der Trocknungsbetrieb beginnt mit der Arbeit und stellt sie in Rechnung. Erkennbar ist das an Abläufen, deren Ausgleich seit Stunden nicht abgeschlossen ist.
- Doppelte Stornierung: Die Ablaufsteuerung schickt bei jedem Versuch eine neue Stornonummer. Beim ersten Versuch kommt die Stornierung beim Trocknungsbetrieb an, nur seine Antwort bleibt aus. Die Ablaufsteuerung wiederholt die Stornierung, diesmal mit der Stornonummer S-18 statt S-17. Der Trocknungsbetrieb hält die Wiederholung für eine neue Stornierung und berechnet die Ausfallpauschale womöglich zweimal. Erkennbar ist das an mehreren Stornierungen zum selben Auftrag beim Trocknungsbetrieb.
- Fortschritt nicht gespeichert: Die Ablaufsteuerung stürzt nach der Hotelstornierung ab und hat danach keinen Vermerk mehr, dass die Trocknung noch storniert werden muss. Erkennbar ist das an Aufträgen bei Partnern, zu denen bei der Versicherung kein laufender Vorgang mehr gespeichert ist.
- Gegenaktion löscht Daten: Statt die Stornierung beim Hotel als neuen Vorgang zu speichern, löscht die Ablaufsteuerung die ursprüngliche Reservierung aus den Unterlagen der Versicherung. Später lässt sich nicht mehr nachvollziehen, warum das Hotel eine Stornogebühr verlangt. Erkennbar ist das an Rechnungen von Partnern zu Vorgängen, die in den eigenen Unterlagen fehlen.
Weiterführend
Verwandte Ansätze
- Saga: beschreibt Abläufe über mehrere Programme, in denen Gegenaktionen typischerweise eingesetzt werden.
- Idempotency: sorgt dafür, dass ein wiederholter Auftrag wie die zweite Stornierung nur einmal wirkt.
- Orchestration: Ein zentrales Programm steuert den Ablauf und löst im Fehlerfall die Gegenaktionen in der richtigen Reihenfolge aus.
Werkzeuge und Umsetzungen
- Temporal: Plattform für lang laufende Abläufe. Gegenaktionen lassen sich als eigene Schritte programmieren, und Temporal setzt einen Ablauf nach einem Absturz beim nächsten noch nicht erledigten Schritt fort. Ob der Partner die Stornierung tatsächlich ausgeführt hat, muss das Programm weiterhin selbst prüfen.
- Apache Seata: Rahmenwerk für Abläufe über mehrere Dienste. In seinem Saga-Modus ruft Seata bei einem Fehler die hinterlegten Gegenaktionen automatisch auf.
- Axon Framework: Java-Rahmenwerk, das lang laufende Abläufe mit Gegenaktionen unterstützt.
- Conductor: Ablaufsteuerung, in der für jeden Ablauf ein eigener Ausgleichsablauf für den Fehlerfall hinterlegt werden kann.
Quellen
- Microsoft: Compensating Transaction pattern: beschreibt Gegenaktionen bei Abläufen über mehrere Dienste, wiederholbare Ausgleichsschritte, gespeicherten Fortschritt und den Übergang an Menschen, wenn ein Ausgleich nicht automatisch gelingt.
- Chris Richardson: Pattern: Saga: beschreibt einen Ablauf über mehrere Dienste als Folge lokaler Transaktionen mit Gegenaktionen und nennt die fehlende Abschirmung der Zwischenstände als Nachteil.