Waiting

Ordering laptops takes time. In the current process model, it’s up to the user that handles the Order laptop task to wait for the laptop to arrive and then complete the task. That’s not really the way it works, though, because Order laptop is done once the order is placed. After that, we need to wait. Making these orchestration parts explicit is where BPMN can shine.

Open the model in Camunda Modeler and add a new task after the order laptop, before the joining parallel gateway. Call it Adopt laptop. Set the type of task to a Receive Task. This type of task causes the process to wait for a message and continue after the message arrives. Now the Order laptop user task can be completed straight away and the process will only continue after the message has been received.

Configure the Task

Open the properties pane in Camunda Modeler with the Adopt laptop task selected. We need to configure the type of message that the process expects to complete this task. Open the Message section of the properties and select Global message reference Create new… in the dropdown menu. Name the message adopt-laptop.

Save the model and deploy it to Camunda.

Correlate a Message

Head over to Tasklist in the Camunda webapp and start a new process instance for Onboard Developer. Complete the Order laptop user task that is created.

Inspect the process state in Cockpit. The process instance is waiting for the message to arrive.

Open a new window in your terminal application and execute the following command.

curl --header "Content-Type: application/json" \
  --request POST \
  --data '{"messageName" : "adopt-laptop", "resultEnabled": true}' \
  http://localhost:8080/engine-rest/message

For Camunda, sending a message is called correlating a message and it can be done in various ways. Here, we’ve used the REST API with a simple curl request.

The --data argument that’s supplied can contain a lot more complicated criteria to match exactly the right process instances that are awaiting a message. Here, we simply match on the message name alone (adopt-laptop), but you can imagine that in real world scenarios you would have to provide more specific criteria.

With the waiting added to the orchestration, the system’s execution of the process matches more closely to the way the process really works. You can imagine that should anything ever go wrong during one of the onboardings, when the Trainink colleagues take a look at the process, it’s useful that the state of the process matches closely to the way users experience it. Having a user task outstanding, even though the actions have been performed, is a lot less clear than the process model with the additional receive task. Besides that benefit, the process engine will keep track of the execution times for all of the activities. The additional task will automatically split the user task time from the waiting time at the receive task, providing much more insight into where time passes when the process executes.