Camunda execution exercises

As you learned in Camunda basics for execution, Zeebe Play makes it possible to execute and complete BPMN processes with service tasks even before those tasks have been implemented. Practice more of that to become truly familiar with

• service task configuration

• input and output mapping expressions

• exclusive gateway path condition expressions

• process deployments

• process instances

• completing processes using Zeebe Play.

Eventually you’ll iterate enough to also learn configuration of multi-instance tasks.

Sole service task

Let’s start with simple:

1. Model a process with just a single service task.

2. Give the process Name and ID that you can recognize from Zeebe Play user interface.

3. Deploy process to Zeebe, start an instance of it and complete its service task as shown in the chapter Execute with Zeebe Play.

sole-service-task.bpmn

Add exclusive gateway

And then dive straight to the deep end…

1. Re-use the model from the previous exercise.

2. Add exclusive gateway after the sole service task and split the flow with a path to an alternative end event: Work not completed.

3. Add local variable completed with FEEL expression false into service task Inputs.

4. Add process variable workCompleted with FEEL expression completed into service task Outputs. (You may check chapter Feel expressions on how it evaluates local variable back into process scope.)

5. Add FEEL expression workCompleted as condition for the path from the exclusive gateway to the original end event.

6. From the element context modeling palette, make the new path to the new end event the Default Flow.

7. Deploy process to Zeebe, start two instances of it and complete their service tasks properly with variables as shown in the chapter Execute with Zeebe Play to reach both end events (in separate instances, of course).

add-exclusive-gateway.bpmn

Handle BPMN error

Let’s then refactor a little and add a new feature:

1. Re-use the model from the previous exercise.

2. Remove end event Work not completed and route the path to path back to the service task instead.

3. Add a error boundary event to service task with a path to a new Work abandoned.

4. Configure the error boundary event to expect error with some specific error code.

5. Deploy process to Zeebe, start an instance of it and Throw Error with the code you just configured on its service task to reach the new end event Work abandoned.

add-boundary-error.bpmn

Embedded sub-process wrapping

This iteration should not change any behavior of the process, but would make the model ready for multi-instance:

1. Re-use the model from the previous exercise.

2. Add Expanded SubProcess and drag everything else in the process inside it.

3. Add new start event Work requested to lead the flow into the sub-process.

4. Add new end event Request completed to end the process after sub-process.

5. Deploy process to Zeebe and start enough instances of it to test with Zeebe Play that all the previous features of the process remain.

wrap-with-subprocess.bpmn

Multi-instance sub-process

Work often comes in batches, and BPMN supports that with multi-instance. An single BPMN element or even a complete embedded sub-process can be configured to be multi-instance, causing every item in a collection to be given its own instance of the element or sub-process. Let’s make your freshly refactored sub-process to work over a collection:

1. Re-use the model from the previous exercise.

2. Add new service task Get work items between the main start event and the sub-process.

3. Add local variable results with FEEL expression [] into service task Inputs and process variable workItems with FEEL expression results into service task Outputs.

4. Toggle sequential multi-instance on the embedded sub-process

5. Configure multi-instance properties on the sub-process as following:

   • Input collection: workItems

   • Input element: workItem

   • Output collection: workItemsCompleted

   • Output element: workCompleted

6. Add local variable ẁorkCompleted with FEEL expression false into the sub-process’ Inputs to ensure it remain in sub-process’ scope.

7. Deploy process to Zeebe, start an instances of it, open it at Zeebe Play, complete the first service task with variables {"results": [null, null, null]}, continue to complete the process and, eventually, confirm that it ends with workItemsCompleted process variable having meaningful result.

multi-instance-subprocess.bpmn

multi-instance-subprocess-with-timer.bpmn

Toggle element multi-instance

Configure multi-instance properties