BPMN in Action: Welches Ereignis gewinnt?

In den meisten BPMN-Prozessmodellen gibt es Verzweigungen. Wohl am häufigsten werden exklusive Gateways verwendet. Dort wird anhand von Daten – z. B. die Höhe einer Auftragssumme – entschieden, welcher Weg gewählt wird. Im Gegensatz dazu erfolgt die Entscheidung bei einem ereignisbasierten Gateway anhand von Ereignissen. Dabei wird auf das Eintreten mehrerer Ereignisse gewartet. Das Ereignis, das zuerst eintrifft, „gewinnt“ – und sein Pfad wird ausgewählt.

Unten wird ein typisches Beispiel für den Einsatz eines ereignisbasierten Gateways gezeigt. Dabei wird auf das Eintreffen einer Nachricht gewartet. Trifft sie nicht innerhalb einer bestimmten Frist ein, wird im Prozess reagiert, z. B. indem bei dem betreffenden Partner nachgefragt wird.

Leider verfügt das BPM-System Bonita, mit dem die Beispiele dieser Serie erstellt wurden, nicht über den ereignisbasierten Gateway. Im Video wird gezeigt, wie man dasselbe Verhalten auch auf andere Weise erreichen kann.

Weiterlesen

BPMN in Action: Which event wins?

Most BPMN models contain splits in the control flow. Most frequently used is probably the exclusive gateway. Such a gateway decides which way to go – based on data, such as the value of an order. An event-based gateway, on the other hand, decides on the basis of events. This gateway waits for several events to occur. The event that occurs first, „wins“ – and the path of this event is selected.

The process presented in the video contains a typical example of how to use an event-based gateway. At the gateway, the process waits for a message to arrive. If it isn’t received within a certain time span, a reaction is triggered, such as reminding the partner of the overdue message.

Unfortunately, the BPM-system Bonita – which is used for creating the examples in this series – doesn’t support event-based gateways. The video shows how to achieve the same behavior in a different way.

Link to the video

Weiterlesen

BPMN in Action: Wozu sind Mehrfachaktivitäten da?

Bei einer mit drei kleinen Strichen markierten BPMN-Aktivität handelt es sich um eine Mehrfachaktivität, englisch Multi-Instance-Aktivität. Wie der Name schon sagt, kann eine solche Aktivität mehrfach ausgeführt werden. Anders als bei einer Schleife muss dies jedoch nicht streng nacheinander erfolgen, bis eine bestimmte Bedingung erfüllt ist. Stattdessen wird eine Mehrfachaktivität für jedes Element einer Liste ausgeführt. Dies kann auch parallel, d. h. in beliebiger Reihenfolge, oder sogar zeitgleich (z. B. durch verschiedene Benutzer) erfolgen.

In Video wird dies am Beispiel eines Auftrags mit beliebig vielen Auftragspositionen gezeigt, die einzeln geprüft werden sollen. Das in der kostenlosen Community-Edition von Bonita ausführbare Modell steht wieder zum Download zur Verfügung.

Weiterlesen

BPMN in Action: When to Use Multi-Instance Activities?

A BPMN activity marked with three small lines, is a multi-instance activity. As the name already indicates, such an activity can be performed several times. Other than with a loop, you don’t need to carry out the activity instances one after the other, until a certain condition is fulfilled. Instead, a multi-instance activity is performed for each element of a list. This can be done in parallel, i. e. in any arbitrary order, or even simultaneously (e. g. by different users).

The video shows an example with an order that contains several line items. Each line item is inspected separately. You can download the model and execute it in the free community edition of Bonita.

Weiterlesen

BPMN in Action: Kommunikation von Prozessen über eine Message Queue

Im letzten Beitrag ging es darum, dass ein auf einer Process Engine ausgeführter Prozess mit einem zweiten Prozess kommuniziert, der auf einer anderen Process Engine installiert ist. Dabei wurde die REST-Schnittstelle der zweiten Process Engine genutzt. Da die REST-Schnittstellen von Process Engines nicht standardisiert sind, müssen die Aufrufe speziell an die zweite Engine angepasst werden.

Flexibler ist der im folgenden Beispiel gezeigte Ansatz, bei der eine Message Queue (Nachrichtenwarteschlange) genutzt wird. Dabei stellen die beteiligten Prozesse gesendete Nachrichten in eine von einem Message Broker verwaltete Warteschlange hinein und entnehmen für sie bestimmten Nachrichten daraus. Mit diesem Verfahren ist es auch einfacher, eine der beteiligten Process Engines auszutauschen. Ebenso kann ein Prozess mit einem komplett anderen System kommunizieren, z. B. einem ERP-System. Dies wird im Beispiel mit Hilfe einer kleinen, selbst geschriebenen Java-Klasse gezeigt, die die Rolle des zweiten Prozesses übernimmt.

Weiterlesen

BPMN in Action: Process Communication via a Message Queue

In the last post I have shown how a process running on a process engine can communicate with a second process that is installed on a different process engine. For the communication, the REST interface of the second process engine was used. Since there isn’t any standard for process engines‘ REST interfaces, the calls must be adapted to the specifics of the second engine’s interface.

A more flexible approach is the use of a message queue (MQ). Such a message queue ist provided by a message broker. The involved processes communicate by inserting and removing messages from a queue. With this approach it is easier to exchange one of the process engines with a different engine. It is even possible that a process communicates with an entirely different system, such as an ERP system. For this example, a small Java class has been written that is used as a replacement for the second process.

Weiterlesen

BPMN in Action: Collaboration of Two Process Engines

In the previous post I have shown how to model separate BPMN processes that communicate using message flow. In order to execute such a process collaboration, all processes need to run in the same process engine. However, if you have processes from different business partners with their own BPM systems, the processes are executed in different process engines.

The video shows how to implement the communication between processes in different systems, using a REST interface. One of the processes is executed in Bonita, the other one in Camunda. The Bonita process exchanges messages with a support process that handles the communication with the Camunda process via Camunda’s REST interface.

Download

The following zip file contains the Bonita project file as well as the BPMN process for camunda.

Weiterlesen

BPMN in Action: Zusammenspiel zweier Process Engines

Wie im vorangegangenen Beitrag gezeigt wurde, kann man mit BPMN separate Prozesse modellieren, die über Nachrichtenflüsse kommunizieren. Damit eine solche Kollaboration mehrerer Prozesse ausgeführt werden kann, müssen sie beide in ein und derselben Process Engine laufen. Gehören die Prozesse, die zusammenspielen sollen, jedoch zu verschiedenen Geschäftspartnern mit ihren jeweils eigenen BPM-Systemen, dann laufen die Prozesse in verschiedenen Process Engines.

Im Video wird gezeigt, wie die Kommunikation über eine REST-Schnittstelle erfolgen kann. Hierbei wird der eine Prozess in Bonita ausgeführt, der andere in Camunda. Der Bonita-Prozess tauscht Nachrichten mit einem Hilfsprozess aus, der sich um die Kommunikation mit dem Camunda-Prozess über die von Camunda bereitgestellte REST-Schnittstelle kümmert.

Download

Die folgende zip-Datei enthält die Bonita-Projektdatei und den BPMN-Prozess für camunda.

Weiterlesen

BPMN in Action: Zusammenspiel von Prozessen mit Nachrichtenflüssen

Eine Besonderheit von BPMN gegenüber anderen Prozessmodellierungsnotationen besteht darin, dass man Kollaborationen modellieren kann – also das Zusammenspiel von zwei oder mehr eigenständigen Prozessen, die Nachrichten miteinander austauschen. So kann ein Prozess eine Nachricht verschicken und dadurch einen anderen Prozess starten, oder es wird eine Nachricht an eine existierende Prozessinstanz verschickt, die an einem nachrichtenempfangenden Zwischenereignis bereits auf diese Nachricht gewartet hat.

Oft nutzt man Nachrichtenflüsse um das Zusammenspiel der Prozesse unterschiedlicher Geschäftspartner zu modellieren, z. B. zwischen dem Beschaffungsprozess eines Kunden und dem Angebotsprozess eines Lieferanten. Allerdings nutzen diese in der Regel nicht gemeinsam dasselbe BPM-System. Ist es auch sinnvoll, Kollaborationen innerhalb einer Organisation zu verwenden – obwohl man dasselbe Verhalten meist auch durch einen einzigen Prozess mit mehreren Lanes erzielen könnte?

Durchaus – die Aufteilung in separate Prozesse unterstützt lose Kopplung, Wiederverwendung und Trennung von Verantwortlichkeiten.

Im Video wird die Modellierung und Ausführung einer Kollaboration gezeigt. Außerdem wird erläutert, wie man mit Hilfe einer Korrelation dafür sorgt, dass die Nachrichten bei den richtigen Prozessinstanzen ankommen.

Weiterlesen

BPMN in Action: Process Collaboration & Message Flow

A special feature of BPMN compared to other process modelling notation is the possibility to model process collaborations. A collaboration consists of two or more separate processes that communicate via message flow. A process can send a message that starts another process, or a message is sent to an existing process instance that has already been waiting for this message at a message-catching intermediate event.

It is common to use collaborations for modelling the interactions between different business partners, e. g. between the procurement process of a customer and the order handling process of a supplier. However, business partners usually don’t use a shared BPMS platform. Does it also make sense to use collaborations within a single organization – although the same behaviour could be achieved by modeling a single process with several lanes?

The answer is yes, since the separation into different processes supports loose coupling, process re-use and separation of concerns.

The video presents a model of a collaboration and its execution by a processes engine. It also shows how to use a correlation in order to make sure that messages are received by the correct process instances.

Weiterlesen