Table of Contents:

Introduction

This example is found in the folder tutorial1_basic_messaging

The simulation scenario has 2 static nodes called A and B.

If you run the simulation with ONE GUI, you will that join nodes’ names and adresses are joined in the GUI, so e.g. node B is shown as B1, as it has been assigned the address 1:

This example includes 2 processes, each per host:

  1. Process A, run by A, sends a message called “Hello” to the address “1” with some content attached to it. After sending the message, the process will wait until it receives a message called “Response Message”, after which the process ends.

Process A

  1. Process B, will first wait for a message called “Hello”, and after receiving it, will respond to the sender of “Hello” with a message called “Response Message”.
    1. Note that B uses a dynamic process variable as the recipient address for sending response message

Process B

Taking note of the exact names of messages is important, because while the host/node who is running Process B may potentially receive various messages, the process should only react to the “Hello” message. Thus, the process has to explicitly declare its’ interest in messages using their names. More on this later.

Creating Process A

Let’s create a new BPMN model for Process A using the STEP-ONE version of Flowable modeller. The model key is used by the simulator to identify and start an instance of the process.

Send Message Task

To define the task for sending a message called “Hello” from A, choose the “Send BP Message” task from the Flowable modeller palette. To fully define a message task, you specify:

The following video shows an example of creating a Send BP Message task in the modeller:

In the above, the message name is set to “Hello”, message size is fixed as 128 bytes, the destination address is set to “1”, and a single variable called “messageContent” is attached to the message. The value of messageContent is set in the simulations settings file.

Note: The process elements also have names, in the above, the element “Send BP Message” has the name Send “Hello”. The element name is for easier human readabilty of the process model and is different from the message name (“Hello”) which is being sent!

Catch message event

Next, we add an Intermediate catching event for messages - this will make the process wait for a certain message to arrive. A message catching event definition has to include what message the event will wait for. For any process definition, the set of messages it is interested in has to be declared. Each message definition consists of an ID and Name. The name has to exactly match the same value the message sender is using.

Message definitions of a process can be set in the modeller by:

  1. Open the properties of the entire process, by making sure no process element is currently selected (e.g. click on the background to de-select).
  2. In the bottom properties panel, select “Message definitions”
  3. Add a new message definition.

Now, you can assign the message definition to the message catch event. The catch event is a generic Flowable Intermediate message catching event in the palette. The following video demonstrates these steps:

In this case, we define a message with the name “Response Message” and make the catch event refer to that message.

To complete the process, make sure all process elements are connected with sequence flows (arrows) and add an End event (as done in above video).

Creating Process B

Process B is similar to A, except it will first try to catch a message and then respond by sending another new message. As a reminder, Process B will look like this:

Process B

Using process variables

To respond to the Hello message, we will again use the Send Process Message task, but this time, we won’t hardcode the recipients address. Instead, we will use a process variable to specify the destination address. In STEP-ONE, whenever a Catch message event catches a message, the process engine automatically creates a new process variable “last_msg_source_address” and assigns the address of the message’s sender to it.

So, Process B can use that variable to specify the destination. To use a variable in the process definition parameters, use the syntax:

${ variable_name }

The ${ .. } represents an expression which will be resolved during runtime using variables available in the process. For process B, the destination value would look like:

Running the example

Run the ONE simulation in GUI mode and advance the simulation by 1 step. If you open the Processes Info window for each node, you will see that both hosts are running respective processes.

The red boxes in the below screenshot highlight the variables of the processes. Note that for Process A, the messageContent variable exists, while for Process B, it does not. Certain variables are automatically created by STEP-ONE, such as the one message sender address mentioned above or localhost, which is the address of the host running the process.

In the Event log at the bottom, notice that A0 has created a Hello message with an unique identifier.

Advance the simulation by 2 more steps. At step 3, you should see the following:

At step 3, note that in the event log, we can see that A succesfully delivered the Hello message to B. We also see that B also began creating and transmitting the Response message. Further, notice that Process B now has the messageContent variable available to it, since it was attached to the Hello message from A.

Finally, if you advance to timestep 4, you will see the Response message has finished transferring, and now both processes have finished. The Processes Info window shows for finished processes the timestamps of when they were started and finished (e.g. started at 1 and finished at 4 for Process B).

Both processes are started from the ONE configuration file with the autoStartedProcessKeys option.

Back to Home