Will man Abhängigkeiten zwischen Tasks und Stages darstellen, geht das nur über die sogenannten Sentries oder auf Deutsch: Wächter. Aber was ist das überhaupt und wie verwendet man sie richtig? In diesem Beitrag wollen wir das erklären.

Wächter, das sind doch …

In den vorhergehenden Teilen wurden die Wächter bereits unter ihrem englischen Namen Sentry verwendet, aber nicht ausführlicher erklärt. Dabei gibt es hier sehr vieles, dass man wissen sollte, wenn man Abhängigkeiten modelliert.

Die ersten beiden Teile sind übrigens hier und hier nachzulesen und bieten aufeinander aufbauend eine kleine Einführung in die CMMN. Es lohnt sich sicherlich, auch hier noch mal einen kurzen Blick reinzuwerfen.

Sentry lässt sich, wie schon mehrfach dezent angedeutet, als Wache, Wachposten oder Wächter übersetzen. Aber, ähm, was bewachen die eigentlich?

Wächter des Lebens

Wächter bewachen den Lebenszyklus von verschiedenen Bestandteilen eines Cases – insbesondere der hier im Fokus stehenden Tasks und Stages. Gleichzeitig reagieren sie auch auf den Lebenszyklus anderer Elemente. Um die Funktionsweise der Wächter besser zu verstehen, ist es also mit Sicherheit hilfreich, die Lebenszyklen von Stages und Tasks wenigstens mal gesehen zu haben.

Zum Glück teilen sich die beiden den gleichen Lebenszyklus und der sieht so aus (Erklärung unter dem Bild):

Von Interesse sind hier folgende Übergänge:

• von Available zu Enabled (enable)
• von Available zu Active (start)
• von irgendeinem Zustand zu Terminated

Genau diese Transitionen im Lebenszyklus werden von den Wächtern bewacht.
Je nachdem, für welchen Übergang sie verwendet werden, bezeichnet man die Wächter als Eintritts- oder Abbruchbedingung.

Anatomie eines Wächters

Ein Wächter hat – neben einem Namen :) – mehrere On-Parts und einen If-Part.

Die vom Wächter bewachte Transition wird durchgeführt, wenn der Wächter erfüllt ist. Dies trifft zu, wenn seine On-Parts ausgelöst wurden und sein If-Part erfüllt ist.

If-Part

Was ein If-Part ist, ist schnell erklärt. Dahinter versteckt sich nämlich nur ein Ausdruck, der auf dem Case File (Siehe Teil 1) ausgewertet wird. So lässt sich z.B. während des Check-Ins beim Arzt prüfen, ob die Versichertendaten vorliegen und dann gegebenenfalls ein neuer Task starten, um diese zu erfassen.

On-Part

Der On-Part ist ein wenig anders. Er ist mit einem Ereignis – einer Lifecycle-Transition eines anderen Elements – verknüpft. Wenn diese Transition ausgeführt wurde, ist der On-Part erfüllt. Es heißt dann, der On-Part „findet statt“, wie es in der CMMN-Spezifikation frei übersetzt heißt.
Mit dem On-Part lassen sich z.B. Abfolgen von Tasks modellieren, indem man auf die complete Transition eines anderen Tasks wartet.

Um das mal zu verdeutlichen, erweitern wir das in Teil 1 begonnene Beispiel um den Task „Versichertendaten erfassen“ (z.B. Karte auslesen), sobald der Patient am Schalter eingecheckt wird (On-Part) und seine Versichertendaten nicht vorliegen (If-Part).

Anatomische Besonderheiten

On-Parts müssen sich nicht immer auf so profane Dinge wie Tasks oder Stages beziehen, sie können auch mit Case File Items und – Achtung! – anderen Wächter verknüpft sein!

On-Part mit Daten

Mit einem Case File Item verknüpft, reagiert ein Wächter z.B. auf das Erzeugen, Ändern oder Löschen von Daten. Eine neue Adresse wurde hinzugefügt? Dann gleich mal fragen, an welche der vielen Adressen in Zukunft die Rechnung gehen soll. Gar kein Problem!

On-Part und andere Wächter – oder: Kompensationen und Timeouts

Verknüpfungen mit anderen Wächtern gehen nur, wenn der eine als Eintrittsbedingung dient und der andere als Abbruchbedingung. Damit kann man modellieren, dass ein Task A aktiviert wird, wenn ein Task B durch seine Abbruchbedingung abgebrochen wird. Dies ist praktisch, wenn ein aktiver Task bei Abbruch von Außen durch eine andere Tätigkeit kompensiert werden muss oder eine alternative Tätigkeit ausgeführt werden soll.

Beispielsweise möchte man eine in Bearbeitung befindliche Bestellung sauber zurückrollen, wenn der Kunde die Bestellung abbricht. Dann würde man das in etwa wie folgt modellieren. Der Task „Bearbeitung rückgängig machen“ könnte auch gut ein Process Task sein, der über einen rigiden Prozess alles vollautomatisch aufräumt.

Der Kreis mit dem Männeken drin ist übrigens ein Event Listener, ein User Event Listener, um genau zu sein. Es gibt übrigens noch einen anderen Event Listener, den Timer Event Listener.

Letzterer ist total praktisch, wenn man einen Task abbrechen möchte, der zu lange andauert. In dem Fall würde man ihn mit der Abbruchbedingung eines Tasks verbinden:

Geister-Wächter

In den CMMN-Diagrammen, die man hier bisher sehen konnte, hatte nicht jeder Task einen Wächter, was aber auch nicht viel gestört zu haben scheint. Aber was heißt es denn genau, wenn ein Task weder Eintritts- noch Abbruchbedingung hat?

Eine fehlende Abbruchbedingung hat keine besondere Auswirkung. Das war also einfach :)

Wenn aber keine Eintrittsbedingung vorhanden ist, dann wird einfach angenommen, das eine da wäre und dass die immer erfüllt ist. (Pro Tipp: Jetzt wäre der richtige Zeitpunkt, um kurz nach oben zu „Anatomie eines Wächters“ zu scrollen und nochmal nachzulesen, was das bedeutet ;) )
Man könnte also sagen, auch wenn keine Eintrittsbedingung modelliert ist, dann ist doch zumindest der Geist eines erfüllten Wächters vorhanden… ;)

Schlusswort

Wir haben jetzt hoffentlich verständlich erklärt, wie man Abhängigkeiten zwischen Tasks modelliert.
Was kommt als nächstes?

Das wissen wir noch nicht so genau. Bei den bisherigen Artikeln dieser Reihen wurden die Stages ein wenig vernachlässigt, also wäre es sicherlich nicht schlecht, ein wenig auf diese einzugehen.
Ihr dürft euch aber gern auch Themen wünschen oder einfach auch Fragen stellen – wozu gibt es sonst die Kommentarfunktion?