In BPM/SOA-Projekten stellt sich immer wieder recht schnell die Frage, wie transaktionales Verhalten in einem Prozess zu realisieren ist. Eine Menge von Aktivitäten eines Prozesses soll in einem transaktionalen Kontext ausgeführt werden – doch wie ist dies zu bewerkstelligen in einem Umfeld, in dem eine Prozessteuerung eine Reihe unabhängiger Services orchestriert, die wiederum in ihren eigenen Transaktionen laufen?
Die Antwort liefert uns die Prozessmodellierung: BPMN kennt das Konzept transaktionaler Subprozesse in Kombination mit Kompensierungs-Ereignissen und -Aktivitäten. Kompensierung bedeutet, dass bereits ausgeführte Prozessschritte dadurch zurückgerollt werden, indem konkrete Gegenmaßnahmen durch einen weiteren Prozessschritt eingeleitet werden.
Innerhalb eines transaktionalen Subprozesses (in BPMN gekennzeichnet durch eine doppelte Umrandung) wird jeder Aktivität über ein angeheftetes Kompensierungs-Zwischenereignis (gekennzeichnet durch ein „Zurückspulen“-Symbol) eine Kompensierungs-Aktivität zugeordnet. Bricht die Transaktion ab, so wird für jede Aktivität, die bereits erfolgreich abgeschlossen wurde, die jeweilige Kompensierung ausgeführt. In diesem Zusammenhang kommt das Abbruch-Event (gekennzeichnet durch das „X“) mit ins Spiel. Als auslösendes (End-)Ereignis innerhalb eines transaktionalen Subprozesses bewirkt es den Abbruch der Transaktion und damit das Auslösen der Kompensierungen. Als an die Transaktion angeheftetes Zwischenereignis bestimmt es den weiteren Ablauf des Prozesses nach dem Abbruch der Transaktion. Doch damit nicht genug: durch das Konzept der Kompensierung kann eine Transaktion auch dann noch zurückgerollt werden, nachdem sie eigentlich schon erfolgreich abgeschlossen wurde. Außerhalb der Transaktion signalisert ein auslösendes Kompensierungsereignis, dass die Kompensierung der referenzierten Transaktion nachträglich durchgeführt werden soll.
Schauen wir uns dies anhand des klassischen Beispiels einer Reisebuchung einmal an:
Eine Reisebuchung besteht aus einer Flug- und einer Hotelbuchung, die potenziell parallel vorgenommen werden können. Ist eine der Buchungen nicht möglich, so muss die andere Buchung (falls sie schon ausgeführt wurde) wieder storniert werden. Ein Fehler bei einer einzelnen Buchung löst also den Abbruch der Transaktion aus und führt dazu, dass der Prozess mit einer Fehle-Nachricht an den Kunden reagiert. Außerhalb der eigentlichen Transaktion führt ein Fehler bei der Belastung der Kreditkarte zur Stornierung der gesamten Buchung.
Dieses Modellierungs-Paradigma bedeutet für die technische Umsetzung in einer Serviceorientierten Architektur, dass für alle Services, die potenziell in einem transaktionalen Prozesskontext benutzt werden sollen, entsprechende Methoden zur Kompensation bereitgestellt werden müssen. Die Umsetzung transaktionalen Verhaltens erfolgt dann nicht durch ein technisches Konstrukt (wie z.B. bei Datenbanken oder im Java EE-Umfeld gewohnt), sondern durch die entsprechende Umsetzung eines Prozessablaufs.
