Compensation-Aktivitäten

Der CompensationHandler eines Scopes kann durch die Compensate- und CompensateScope-Aktivität, die gemeinsam als Compensation-Aktivitäten bezeichnet werden, aus einem FCT-Handler des Vater-Scopes aufgerufen werden. Dadurch können Scopes, die unmittelbar in einem Scope eingeschlossen sind, kompensiert werden. Solche Scopes sind alle Kinder-Scopes, die nicht in einem anderen Scope oder FCT-Handler eingeschlossen sind. Das bedeutet, dass Kinder-Scopes, die von einer strukturierten Aktivität oder EventHandlers eingeschlossen sind, ebenfalls aus dem FCT-Handler des Vater-Scopes kompensiert werden können.

Die CompensateScope-Aktivität wird benutzt, um einen bestimmten Kinder-Scope zu kompensieren. Das target-Attribut spezifiziert dabei den Name des zu kompensierenden Scopes.

Listing 23 zeigt ein Beispiel für die Definition einer CompensateScope-Aktivität.

<compensateScope target=“RecordPayment“/>

Listing 23: Definition einer CompensateScope-Aktivität

Die Compensate-Aktivität kompensiert alle Kinder-Scopes in DCO (vgl. Abschnitt 5.5).

Beide Compesation-Aktivitäten können Source- und Target-Container spezifizieren.

Wenn ein Scope in einer while-, repeatUntil- oder forEach-Aktivität, sowie in EventHandlers, spezifiziert ist, dann werden mehrere Instanzen von diesem Scope ausgeführt. Eine Compensation-Aktivität, die einen solchen Scope kompensiert, muss dann für jede erfolgreich ausgeführte Scope-Instanz die CompensationHandler-Instanz aufrufen. Wenn ein Fehler bei der Ausführung einer CompensationHandler-Instanz signalisiert wird, dann muss die Compensation-Aktivität alle anderen CompensationHandler-Instanzen der CHIG (vgl.

Abschnitt 5.5) terminieren.

Eine CompensationHandler-Instanz hat Zugriff auf den Zustand des Scopes in dem er enthalten ist, sowie den Zustand aller umgebenden Scopes. Der Zustand eines Scopes beinhaltet alle in ihm deklarierten Variables, PartnerLinks sowie CorrelationSets. Wird ein Scope fehlerfrei beendet, ist sein Zustand immer noch verfügbar. Der Grund ist, dass der CompensationHandler für diesen Scope noch ausgeführt werden kann.

In Abbildung 25 ist das EWFN für die Compensate-Aktivität dargestellt. Damit der Fall behandelt wird, dass mehrere CompensationHandler-Instanzen für Scopes, die in einem Schleifen-Konstrukt oder EventHandlers enthalten sind, aktiviert werden, stellt Abbildung 25 eine Compensate-Aktivität dar, die drei Kinder-Scopes kompensiert, wobei angenommen wird, dass der zweite Scope in einem Schleifen-Konstrukt enthalten ist.

Abbildung 25: Compensate-EWFN

Die innere Struktur des Compensate-EWFN besteht aus den CompensationHandler-EWFNs aller Kinder-Scopes. Die Schnittstelle zu dem aufrufenden FCT-Handler bilden die Plätze

start, ended und failed. Das Terminieren der CompensationHandler-Instanzen wird über die Plätze from_MW, to_MW, terminated_CH und terminate_CH geregelt. Der Fault-Platz ist identisch mit den failed-Plätzen derjenigen inneren Aktivitäten, die nicht in einem Scope eingeschlossen sind. Der Platz CH stellt eine Aggregation der CH-Plätze aller zu kompensierenden Kinder-Scopes dar. In dem Beispiel des Compensate-EWFNs aus Abbildung 25 wird der CH-Platz durch die CH-Plätze der drei Scopes, die kompensiert werden müssen, ersetzt.

Anhand der nachfolgenden drei Szenarien wird der Kontrollfluss im Compensate-EWFN betrachtet.

Im ersten Szenario wird die Compensate-Aktivität aktiviert und sie wird fehlerfrei ausgeführt.

In diesem Fall liegt ein CF-Token auf dem start-Platz des Compensate-EWFNs. Die Transition T1 führt anhand der Prozessbeschreibung eine DCO (vgl. Abschnitt 5.5) aus.

Deswegen muss sie mit den start- und ended-Plätzen aller aufzurufenden CompensationHandler-Instanzen verbunden sein. T1 schreibt also ein CF-Token auf den start-Platz des nächsten aufzurufenden CompensationHandler und wartet auf ebenfalls ein CF-Token auf seinem ended-Platz. Danach wird der nächste, gemäß dem DCO, CompensationHandler aufgerufen. Wird auf einem ended-Platz ein FAIL-Token gelesen, dann wird das Kompensieren gestoppt, d.h. T1 schreibt kein CF-Token auf den start-Platz der nächsten aufzurufenden CompensationHandler-Instanz. Für solche CompensationHandler, die nicht einer DCO unterliegen, wird T1 direkt ein CF-Token auf ihren start-Plätzen schreiben und am Ende, bevor der Kontrollfluss das Compensate-EWFN verlässt, diese CF-Tokens aus den ended-Plätzen synchronisieren. Wird ein FAIL-Token auf einen ended-Platz geschrieben, d.h. ein Fehler wurde signalisiert, dann wird die Transition T2, wie im Szenario 2 beschrieben, die Kontrolle übernehmen und das Terminieren aller laufenden CompensationHandler-Instanzen veranlassen. Die Transition T1 muss allerdings die CompensationHandler-Instanz für den zweiten Scope eventuell mehrfach aufrufen. Dazu wird der CH-Platz dieses Scopes benutzt. Für jedes in ihm enthaltene Tupel wird ein CF-Token auf den start-Platz seiner CompensationHandler-Instanz geschrieben. DCO wird dabei anhand der scopeID bestimmt. Zum Schluss dieses Szenarios wartet T1 auf ein CF-Token auf dem ended-Platz der letzten, gemäß dem DCO, aufgerufenen CompensationHandler-Instanz, sowie auf die CF-Tokens von allen CompensationHandler-Instanzen, die nicht anhand eines DCO aufgerufen worden sind. Als letztes wird ein CF-Token über den ended-Platz an den aufrufenden FCT-Handler gesendet.

Im zweiten Szenario wird ein Fehler bei der Ausführung einer CompensationHandler-Instanz signalisiert. Der Fehler wird in den Fault-Platz des Compensate-EWFNs landen. Danach wird T2 schalten und das Terminieren aller CompensationHandler-Instanzen veranlassen. Da das Terminieren ähnlich wie im FaultHandler-EWFN verläuft, wird auf eine genaue Beschreibung verzichtet. Die einzigen Unterschiede bestehen in dem Wert ch, der in den to_MW- und aus from_MW-Platz geschrieben und gelesen wird, sowie, dass die Transition T2

T1 einfach dieses Token auf den ended-Platz und damit ist das Szenario zu Ende. Der Grund warum das Token nicht an die einzelnen CompensationHandler-Instanzen weiterpropagiert wird, ist, dass in einem CompensationHandler keine Links verwendet werden dürfen, die außerhalb von ihm definiert sind.

Da die Übersetzung der CompensateScope-Aktivität sehr ähnlich ist, wird auf diese verzichtet.