Das ist ja spannend –

Senden/Empfangen Task vs. Ereignis

 

Ich habe gerade ein spannendes Thema am Rande touchiert –
Grund genug, diesen Eintrag zu schreiben.

Da war eine Aussage, dass man allenfalls Senden/Empfangen Tasks verwenden sollte, um die Kollaboration zwischen Prozess und Prozessteilnehmern zu modellieren anstelle von Zwischenereignissen (d.h. auf Zwischenereignisse vollständig zu verzichten, rein deskriptive Ebene). Also ich habe das so verstanden: angenommen ein Gesuchstellungs-Prozess benötigt eine Rückfrage beim Gesuchsteller, soll diese Kollaboration über Senden/Empfangen Tasks  und Datenspeicher gelöst werden. Ein versuch, dies zu modellieren war in etwa:

Was halten Sie davon?

Ich sehe folgende Vorteile:

1. Ich brauche lediglich ein generisches Start- und Endereignis (keine Zwischenereignisse).
2. Die Kommunikation (Kollaboration) wird mit Sende/Empfangen Tasks gemacht, was den Leser vom Wissen um (Zwischen-)Ereignisse entlastet.

Ich habe folgende Probleme:

1. Es wird wohl implizit angenommen, dass der Gesuchsteller sein Gesuch in der Gesuch-DB speichert (in seinem Prozess, der als Black-Box dargestellt ist)
2. Die Kollaboration ist nicht interpretationsfrei modelliert – was ist mit Fristen etc.?
3. Es ist schon richtig, dass Datenspeicher dauerhaft sind. Nur handeln wir uns mit einer solchen Lösung die ganzen Fragen nach dem Zugriff auf diese Daten ein (Sicherheit, Anwendungsteile dafür etc.). Im Diagramm ist dies nicht ersichtlich, die Schnittstelle zum Gesuchsteller muss erklärt werden.
4. Unschönheit: Sender/Empfänger Task sind nicht in der Ebene 1 vorhanden (deskriptive Ebene) sondern sind Elemente der analytischen Ebene.

Zu Punkt #1. und #3. sehe ich auf die Schnelle folgende Verbesserung:

Wir legen die Daten der Kollaboration auf den Payload der Nachrichtenflüsse als Nachrichten-Objekte an die Schnittstelle. Die Speicherung übernehmen dann die Senden/Empfangen Tasks. Ich musste dazu die Vorlagen-DB einzeichnen und man beachte die Datenflussrichtung.

Problem #2. Habe ich nicht gelöst, im Gegenteil – es ist absolut unklar, wie die Zusatzinfo zurückkommt. Problematisch könnte ebenfalls sein, dass nach einholen der Info gerade die Rückmeldung gemacht wird (ohne vorgängigen Entscheid). Also, Verbesserungs-Versuch:

Das Problem mit abgelaufenen Firsten (z.B. für die Zustellung der Zusatzinformation durch den Gesuchsteller) ist ohne Zwischenereignisse leider nicht mehr möglich zu modellieren.

Zu meiner Ehrrettung noch meine favorisierte Lösung (natürlich mit Ereignissen und weniger Datenflüssen 😉 ):

Sie fragen sich, was der Data-Input „Gesuch“ bedeutet? Das werde ich im nächsten Beitrag untersuchen.