Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03298.jsonl.gz/937

Eines der neuen Elemente der BPMN 2.0 ist der ereignisgesteuerte Unterprozess. Nur wozu ist dieses Element dienlich und kann es wirklich sinnvoll eingesetzt werden? Wird dieses Element gar verkannt?
In der Tat kommt selbst in unseren BPMN Methode und Stil Kursen dieses Element oft ein wenig zu kurz. Der Umstand, dass der Ereignis-Unterprozess neben den Ereignissen als asynchrones Flussobjekt aufgefasst werden kann, birgt einige Möglichkeiten für mein aktuelles Lieblingsthema, die agilen Prozesse.
Also, kurz Rekapitulation über die Funktionsweise:
Ein Ereignis-unterprozess ist das einzige Element, welches „schwebend“ in einer Orchestrierung vorkommen darf. Ein Ereignis-Unterprozess wird mit einer gepunkteten Linie markiert und darf keine ein- und ausgehenden Sequenzflüsse haben.
Der hier abgebildete Ereignis-Unterprozess ist zeitgesteuert. Das heisst, wenn eine bestimmte Zeitmarke erreicht wurde, startet dieser Unterprozess. Oder der Unterprozess startet über ein spezifisches Ereignis, wie nachfolgend abgebildet eine Nachricht, auf welches er hört:
Der Unterprozess selbst wird mit einem typisierten Ereignis gestartet und stellt somit eine Ausnahme dar, weil normale Unterprozesse nie typisierte Start-Ereignisse aufweisen dürfen.
Der Ereignis-Unterprozess wird wie oben abgebildet nun also den Unterprozess, in welchem er eingebettet ist, unterbrechen und wird darauf folgend abgearbeitet. Dieses Verhalten wird über das Attribut isInterrupting (=false) auf dem Start-Ereignis im Unterprozess gesteuert. Wird das Start-Ereignis des Ereignis-Unterprozesses auf nicht-unterbrechend gesetzt, fährt der Vater-(Unter)prozess nach Eintreffen des Ereignisses ganz normal weiter.
Anmerkung: Handelt es sich bei dem Unterprozess, welcher den Ereignis-Unterprozess beinhaltet, um einen Multi-Instanz Unterprozess, wird nur die gerade betroffene Instanz unterbrochen.
Es können sich nun interessante Fragen stellen wie zum Beispiel:
Kann der Vater-Unterprozess (welcher den Ereignis-Unterprozess einbettet) beendet werden, solange ein nicht-unterbrechender Ereignis-Unterprozess noch läuft?
Antwort: Der Vater-Unterprozess erreicht das Ende (alle Tokens sind angekommen und die End-Ereignisse erreicht) und fällt in den Status „Completing“. Es wird dann solange gewartet, bis alle Ereignis-Unterprozesse beendet wurden. Tricky: Es können natürlich während dieser Wartezeit wieder Ereignisse für den Ereignis-Unterprozess eintreffen, was eine neue Instanz desselben anlegt.
Oder was geschieht, wenn unterbrechende Error oder Escalations-Ereignisse den Ereignis-Unterprozess auslösen?
Antwort: Der Vater-(Unter)Prozess fällt im Falle eines Fehler in den Status „Failing“ und wartet, bis der Ereignis-Unterprozess abgearbeitet ist. Während dieser Zeit können keine weiteren Fehler-Ereignisse mehr aufgefangen werden. Im Falle einer unterbrechenden Eskalation fällt der Vater-(Unter)Prozess in den Status „Terminating“ und wartet, bis der Ereignis-Unterprozess abgearbeitet wurde. Es können während dieser Zeit keine neuen Ereignisse (Escalationen) empfangen werden. Der Zugriff aus dem Ereignis-Unterprozess auf den Kontext (bsplw. auf Datenobjekte) des Vater-(Unter)Prozesses ist möglich.
Zur Frage, ob ein Fortsetzen eines Ereignis-Unterprozesses auch nach Beendingung des Vater-(Unter)Prozesses möglich wäre, finden wir in der Spezifikation einen obskuren Text (S.440, §3), der mich selbst nach längerem analysieren und Beiziehen von zusätzlichen Experten nicht wirklich schlauer gemacht hat. Im Falle eines unterbrechenden Ereignisses kann offenbar der Ereignis-Unterprozess sein Ereignis zum Ende erneut werfen. Dadurch wird der Vater-(unter)Prozess zwar terminiert, die Kontrolle an ein allenfalls angebrachtes Boundary-Ereignis abgegeben (reine Vermutung), aber der Ereignis-Unterprozess läuft dann „Kontext-frei“ weiter.
Hier bin ich gespannt auf Ihr Feedback – kann mir das jemand tiefer Erklären oder hat jemand eine Vermutung dazu?
Das wirklich spannende an den Ereignis-Unterprozessen ist aber Ihre Agilität und vielseitige Verwendung. Es lässt mich seit einiger Zeit stark darüber nachdenken, ob mit diesem Konstrukt die Agilität und Ereignis-Orientierung erhöht werden kann. Ich werde in einem späteren Artikel darauf zurückkommen.