In der BPMN 2.0 sind Versand- und Empfangsaufgaben eine Alternative zu den Nachrichtenereignissen bei nahezu gleicher Semantik. Aber wozu braucht man überhaupt diese Alternative?

Aufgaben und Ereignisse – oder: Wovon redet der hier überhaupt?

• Eintretendes Nachrichtenereignis:
  Empfängt eine Nachricht, kann als Startereignis auch einen Prozess instanziieren.
• Empfangsaufgabe:
  Empfängt eine Nachricht, kann auch einen Prozess instanziieren.
• Ausgelöstes Nachrichtenereignis:
  Sendet eine Nachricht. Auch als Endereignis verwendbar.
• Versandaufgabe:
  Sendet eine Nachricht.

Noch ein Unterschied:
Ereignisse werden ausgelöst oder treten ein – Aufgaben werden ausgeführt. Das beeinflusst natürlich auch die Benennung der Elemente: „Paket entgegennehmen“ wäre eine mögliche Beschreibung einer Empfangsaufgabe, denn sie drückt aus, dass hier etwas aktiv getan wird. Für das korrespondierende Ereignis ist das aber nicht mehr passend, denn hier muss etwas passieren: „Paket entgegengenommen“

Vorteile der Nachrichten-Aufgaben

Wer tut was wann?

Aufgaben haben immer jemanden, der sie ausführt, was sehr praktisch sein kann, um klare Verhältnisse zu schaffen. Nehmen wir als Beispiel einen Brief, den Ihre bessere Hälfte geschrieben, kuvertiert und adressiert hat und Ihnen dann übergibt, um ihn bei nächster Gelegenheit in den Briefkasten zu werfen. Und damit Sie besser verstehen, was sie möchte, hat sie Ihnen netterweise ein BPMN-Diagramm gezeichnet – ein ganz alltäglicher Fall also ;)

Mit einem Ereignis modelliert, wird aus dem Modell überhaupt nicht klar, was Ihre Aufgabe ist. Sollen Sie ihn einwerfen? Sollen Sie Ihre Frau erinnern, ihn einzuwerfen? Die Platzierung des Ereignisses in Ihrer Lane hat – nebenbei – auch keine Zuordnungsemantik! Aus dem Prozessmodell geht also überhaupt nicht eindeutig hervor, wer was tun soll – der Streit ist vorprogrammiert!

Hätte Ihre Frau eine Versandaufgabe verwendet, wäre sofort klar, was sie möchte und Sie würden den Brief bei nächster Gelegenheit einwerfen. Unfrankiert. Aber sich darum zu kümmern, war ja auch keine Ihrer Aufgaben ;)

Parallelität darstellen

Im nächsten Beispiel wollen wir eine E-Mail schreiben und verschlüsselt versenden. Da die E-Mail für jeden Empfänger einzeln verschlüsselt werden muss, entstehen so auch mehrere individuelle Nachrichten, die einzeln versendet werden müssen. Würde man das mit Ereignissen modellieren, sähe das in etwa so aus:

Durch Verwendung einer Versandaufgabe lässt sich das eleganter darstellen:

Man könnte zwar auch das Senden aller Nachrichten in einem Service Task verstecken, aber die hier gewählte Form bietet neben der deutlich gesteigerten Ästhetik auch noch weitere Vorteile: Schlägt das Senden einer oder mehrerer Nachricht fehl, kann durch angeheftete Ereignisse für jede betroffene Nachricht einzeln und gezielt auf die Art des Fehlers reagiert werden. Hätten wir nur eine nicht-parallele Aufgabe zum Senden aller Nachrichten, müsste diese eine Art Fehlerprotokoll erzeugen, das von weiteren Service Tasks umständlich ausgewertet werden müsste.

Angeheftete Ereignisse

Wie gesagt, bieten Nachrichten-Aufgaben – wie alle anderen Aufgaben auch – die Möglichkeit, eintretende Ereignisse an sie anzuheften. So könnte man beim Warten auf eine wichtige Nachricht (z.B. das Paket mit den neuen Klamotten für den bevorstehenden Sommerurlaub – die man natürlich sehr kurzfristig online bestellt hat, anstatt einfach in den Laden … ach egal) das Überschreiten der Wartezeit durch ein Zeitereigniss an der Empfangsaufgabe modellieren. Sieht dann auch sehr schick aus:

Würde man das statt der Empfangsaufgabe eine entsprechendes Ereignis modellieren, wäre man gezwungen, ein ereignisbasiertes Gateway einzubauen, was nicht wirklich die Lesbarkeit steigert:

Einschränkungen

Verwendet man Nachrichten-Ereignisse, muss man aber auch aufpassen, dass man ihnen nicht zu viel zumutet – denn letztlich können sie nur so viel wie ihre Ereignis-Geschwister: Nachrichten senden und empfangen. Ok, ein klein wenig mehr dürfen sie können, aber man muss aufpassen, dass man auf der gewählten Abstraktionsebene bleibt. So ist es meiner Meinung nach in dem obigen E-Mail-Beispiel kein guter Stil, das Verschlüsseln und das Senden in der Versandaufgabe, die dann „E-Mail verschlüsseln und versenden“ heißen würde, zusammenzufassen. Damit würde die Aufgabe nämlich deutlich mehr tun als das reine Senden, was bei dem Detaillevel dieses Diagramms unpassend wäre. Auf einem anderen Detaillierungsgrad könnte man aber durchaus den ganzen Vorgang vom Schreiben bis zum Senden zusammenfassen. Das wäre beispielsweise bei strategischen Prozessmodellen der Fall, wenn man eine Aufgabe wie „Kunden benachrichtigen“ hat.

Auch kann und sollte man nicht jedes Nachrichtenereignis einfach so durch eine entsprechende Aufgabe ersetzen. Bei Nachrichtenereignissen, die an Aktivitäten angeheftet sind, ist das natürlich offensichtlich – denn anheftbare Aufgaben gibt es nämlich nicht.
Des Weiteren halte ich persönlich es für keinen guten Stil, einen Prozess mit einer Aktivität beginnen zu lassen, weil dadurch das auslösende Ereignis nicht mehr so deutlich in den Vordergrund tritt. Nichtsdestotrotz würde die BPMN 2.0 das Starten eines Prozesses über eine Empfangsaufgabe erlauben.

Fazit

Die Versand- und Empfangsaufgaben sind eine wundervolle Bereicherung für die Prozessmodellierung und können helfen, die Modelle aussagekräftiger und verständlicher zu gestalten.
(Ein Fazit kann ja auch mal kurz sein, oder?)