Fachbeitrag · Wirtschaftsinformatik ·
BPMN-Kompensation: Warum eine Rückabwicklung kein Datenbank-Rollback ist
Ein Prozess kann technisch erfolgreich gelaufen sein und fachlich trotzdem zurückgenommen werden müssen. Eine Bestellung wurde beispielsweise reserviert, ein Transport beauftragt und eine Bestätigung versendet. Scheitert anschließend ein weiterer Schritt, lassen sich diese Wirkungen nicht durch das Zurücksetzen einer einzelnen Datenbanktransaktion beseitigen. Für solche Fälle braucht ein Prozessmodell ausdrücklich beschriebene Gegenmaßnahmen und einen nachvollziehbaren Zustand nach der Rückabwicklung.
Technischen und fachlichen Zustand unterscheiden
Ein Datenbank-Rollback verwirft Änderungen innerhalb der jeweiligen Transaktionsgrenze. Eine Kompensation führt dagegen eine weitere fachliche Aktivität aus, die eine bereits eingetretene Wirkung ausgleicht. Das kann eine Reservierung aufheben oder einen Auftrag stornieren. Der ursprüngliche Vorgang bleibt Teil der Historie. Eine bereits gelesene Nachricht lässt sich durch eine Gegenbuchung nicht ungelesen machen. Deshalb muss das Modell beschreiben, welche Wirkung noch umkehrbar ist und welches Ergebnis die Gegenmaßnahme tatsächlich erzeugt.
Ein Beispiel mit mehreren Beteiligten
In einem vereinfachten Bestellprozess bestätigt das Lager eine Reservierung, während ein externer Transportdienst den Abholauftrag annimmt. Danach wird die Bestellung zurückgezogen. Die Reservierung kann unmittelbar freigegeben werden; beim Transportauftrag hängt die Rücknahme möglicherweise vom Bearbeitungsstand ab. Beide Schritte bekommen eigene Statuswerte und Rückmeldungen. Der Gesamtprozess darf erst dann als zurückgenommen gelten, wenn die vereinbarten Abschlussbedingungen erfüllt sind. Ein gesendeter Stornierungswunsch allein ist noch keine bestätigte Stornierung.
Auslöser und Wiederholung festlegen
In BPMN haben Kompensationsereignisse eine besondere Bedeutung. Nicht jeder Fehler und nicht jede Unterbrechung löst automatisch sämtliche Gegenmaßnahmen aus. Auslöser, Geltungsbereich und Zuordnung müssen zum konkreten Modell passen. Auch die ausführende Prozessplattform muss diese Semantik unterstützen. Zusätzlich sollte jede Gegenmaßnahme mit einer stabilen Vorgangskennung arbeiten. Wird eine Stornierung nach einer Zeitüberschreitung erneut angefordert, darf daraus keine zweite, fachlich abweichende Änderung entstehen. Erfolgreiche und fehlgeschlagene Versuche bleiben unterscheidbar.
Den Ausnahmefall separat prüfen
Ein belastbarer Test unterbricht den Ablauf nach unterschiedlichen bereits abgeschlossenen Schritten. Danach wird geprüft, welche Gegenmaßnahmen laufen, welche Daten erhalten bleiben und wer einen nicht automatisch lösbaren Restfall übernimmt. Fachbereiche definieren den akzeptierten Endzustand; Technik legt Überwachung und Wiederanlauf fest. Kompensation garantiert keine vollständige Rückkehr in die Ausgangswelt. Sie macht vielmehr sichtbar, wie ein Unternehmen mit bereits entstandenen Wirkungen kontrolliert umgeht und wann eine bewusste manuelle Entscheidung erforderlich bleibt.
Technical insight · Business information systems ·
BPMN compensation: Why undoing a business process is not a database rollback
A process may complete several technical steps successfully and still need to be reversed for business reasons. An order might have been reserved, transport requested and a confirmation sent. If a later step fails, rolling back one database transaction cannot remove all those effects. A process therefore needs explicit counteractions and a clear definition of the state that is acceptable after the business operation has been unwound.
Separate technical and business state
A database rollback discards changes inside its own transaction boundary. Compensation instead performs another business activity to counter an effect that has already occurred. It might release a reservation or cancel an order. The original event remains part of the history. A message that has already been read cannot become unread simply because a counter-entry is posted. The model must identify which effects remain reversible and what outcome each counteraction can actually achieve.
An example involving several participants
In a simplified order process, a warehouse confirms a reservation while an external transport service accepts a collection request. The order is then withdrawn. Releasing the reservation may be immediate; cancelling transport may depend on how far processing has progressed. Both actions require their own statuses and responses. The overall process should only be marked as reversed when its agreed completion conditions are satisfied. Sending a cancellation request is not the same as receiving a confirmed cancellation.
Define triggers and repeat behaviour
Compensation events have a specific meaning in BPMN. An error or interruption does not automatically trigger every possible counteraction. The trigger, scope and association must match the actual process model, and the execution platform must support the relevant semantics. Each counteraction should also use a stable business identifier. If a cancellation is requested again after a timeout, the repeated request must not create another, different business change. Successful attempts and failed attempts need to remain distinguishable.
Test the exceptional route separately
A meaningful test interrupts the process after different completed steps. It then checks which counteractions execute, which data remains and who takes ownership of any unresolved exception. Business teams define acceptable final states; technical teams define monitoring and restart behaviour. Compensation cannot guarantee a complete return to the original world. It provides an explicit way to handle effects that have already happened, while showing when an informed manual decision is still necessary.