Blog

CMMN erklärt: Teil 3 – Abhängigkeiten mit Sentrys modellieren

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):

Lifecycle von Task und Stage

Zustand Der Task/die Stage ist …
Available … verfügbar und wartet darauf, dass seine Eintrittsbedingung erfüllt ist.
Enabled … bereit und wartet darauf, vom Benutzer gestartet zu werden.
Disabled … gesperrt und wartet darauf, vom User wieder bereit gemacht zu werden.
Active … aktiv, d.h., jemand oder etwas führt den Task gerade aus.
Suspended … pausiert worden und wartet darauf, fortgesetzt zu werden.
Failed … fehlerhaft beendet worden.
Completed … erfolgreich beendet worden.
Terminated … durch den User oder eine Abbruchbedingung abgebrochen worden.

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).

Case "Patient Behandeln" mit If und On

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.

Eintrittsbedingung lauscht auf Abbruchbedingung

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:
Timeout

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?

Holisticon AG — Teile diesen Artikel

Über den Autor

Die Holisticon AG ist eine Management- und IT-Beratung aus Hamburg. Wir entwickeln beste Individualsoftware, Webplattformen und Apps. Geschäftsprozesse durchdringen wir und automatisieren sie. Große Datenmengen machen wir mit Smart-Data-Ansätzen beherrschbar. ...und das alles agil.

5 Kommentare

  1. Hallo Malte,

    Stages und was man damit so anstellen kann, fände ich für einen 4. Teil tatsächlich interessant.

    Geht das in Richtung wiederverwendbare Sub-Cases?

    Grüße,
    Stefan

  2. Hallo Stefan,

    dann sollst du deinen 4. Teil kriegen :)

    Um es vorweg zu nehmen: Stages lassen sich leider nicht wiederverwenden, aber man kann andere Cases über Case Tasks aufrufen.

    Viele Grüße,
    Malte

    • Hallo Mario,

      einen vierten Teil gibt es leider noch nicht. Da haben sich verschiedene andere Dinger vorgedrängelt ;)

      Was wäre denn Dein Wunsch-Thema?

      Viele Grüße
      Malte

Antwort hinterlassen