Prozess-Synchronisation

Wie stelle ich als Prozessmodellierer sicher, dass bestimmte Prozessaktivitäten nur einmalig ausgeführt werden – auch dann, wenn für denselben Kunden mehrere Prozessinstanzen gestartet wurden?

Diese Frage stellte sich uns bei der Modellierung eines Prozesses zur Abwicklung eines Telefonanbieterwechsels: Eine Bestandskundin möchte den Anbieter wechseln und dabei ihre Nummer mitnehmen. Sie lässt sich mehrere Angebote unterbreiten, was dazu führt, dass jeder potenzielle neue Anbieter die Kündigung des Vertrages und die Übergabe der Nummer anfragt. Wir müssen gewährleisten, dass die Nummer nur an einen Anbieter übertragen wird.
Dazu stellen wir sicher, dass ein Prozessteil nur von einer Prozessinstanz zur Zeit (Korrelation über einen fachlichen Schlüssel, z.B. Kundennummer, Vertragsnummer) betreten wird. Die Process-Engine prüft dabei, ob für einen fachlichen Schlüssel eine weitere Instanz desselben Prozesses besteht. Ist das der Fall, wartet die Instanz darauf, dass die andere Instanz beendet wird oder einen Status erreicht, der eine Fortführung erlaubt. Nach Beendigung des zu synchronisierenden Teilprozesses prüft die Process-Engine, ob für den fachlichen Schlüssel eine weitere Instanz besteht, die auf die aktuelle Instanz wartet. In diesem Szenario wird die andere Instanz benachrichtigt, dass sie fortgesetzt werden kann.

synchronisation_zwei_pools

Beispiel einer Prozess-Synchronisation

Das Bild zeigt exemplarisch, wie die Synchronisation modelliert werden kann. Wir haben eine Darstellung mit zwei Pools gewählt, um die Kommunikation zwischen den beiden Instanzen mithilfe eines Nachrichtenflusses verdeutlichen zu können. Ursprünglich waren wir aber von zwei Instanzen desselben Prozesses ausgegangen, die in derselben Process-Engine ablaufen.

In unserem Beispiel wird die Benachrichtigung der wartenden Instanz durch einen Send-Task ausgedrückt. Hier hätte genauso gut ein Intermediate Throw-Event stehen können. Welche Möglichkeit wir wählen ist letztlich Geschmackssache: Unserer Meinung nach hat ein Send-Task hier den Vorteil, dass deutlich wird, dass hier eine Aktivität – nämlich die Benachrichtigung der wartenden Instanz – erfolgen muss. Im anderen Fall warten wir auf das Eintreten eines Ereignisses, nämlich das Eintreffen einer Nachricht.

Alternativ zur Nachricht hätten wir auch ein Signal nutzen können. Dies hätte zum gleichen Ergebnis geführt, allerdings mit einer leicht veränderten Sematik: Die Nachricht stellt eine gerichtete Kommunikation dar, das heißt, der Sender muss entscheiden, wem er die Nachricht schickt. Das Signal hingegen stellt eine ungerichtete Kommunikation dar. In diesem Fall ist es Aufgabe des Empfängers, zu entscheiden, ob das Signal relevant ist, die Prozessinstanz also weiterlaufen darf oder nicht.


Dieses und weitere Prozessmuster finden Sie auch auf unserem Poster ‚Erfolgreiche BPM-Pattern aus der Praxis‘

Dieser Beitrag wurde unter Uncategorized veröffentlicht. Setze ein Lesezeichen auf den Permalink.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

w

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.