Let's review the different options available to you when creating a new Workflow. In this tutorial, you will learn more about the different events and tasks you can create inside your workflow as well as other instrumental concepts. Much of this was covered in the What are Workflows article. This information is more specific to how these tools look and operate within FreeAgent.
|
Type of events |
||
|
Type |
Description |
Example |
|
Start |
None Start Event: There’s no “technical” (message or timer-based) trigger for starting a workflow instance with the None Start Event, which is used to describe some “business event” that signifies when we should start a new instance. |
|
|
Message |
Message Start Event: Starts a workflow instance when Zeebe receives a message published by some other system. Could be used for workflows that integrate with and react to messages published on e.g. Apache Kafka. |
|
|
Timer |
Timer Start Event: Starts a workflow instance based on some time characteristic that can be expressed in ISO 8601. Could be used for workflows that need to be scheduled at a regular interval. |
|
|
Error |
In process automation, you often encounter deviations from the default scenario. One way to resolve these deviations is using an error event, which allows a process model to react to errors within a task. |
|
Tasks
Tasks in Zeebe are used to represent something that needs to be done before a workflow instance can progress to the next step. There are two different types of tasks supported bya Zeebe:
- Service Task: A unit of work that needs to be carried out by some external worker; for many Zeebe use cases, the external worker would be a microservice. If you’re familiar with the e-commerce order process we use as an example throughout the docs, you’ve seen the Service Task in a workflow model. The order process contains three different Service Tasks, and the work that needs to be completed at each step could be carried out by three distinct microservices.
- Receive Task: A Receive Task indicates that Zeebe needs to receive a message and correlate it to the correct workflow instance before the token can progress. The Receive Task makes it possible for a workflow instance to wait and then react to a message published by some system separate from Zeebe.
Intermediate Catch Events
Intermediate Catch Events are used to model things that need to happen before our model can progress to the next step (as opposed to modelling work that needs to be done by a microservice, for which we’d use the Service Task). There are two types of Intermediate Catch Events in Zeebe.
- Intermediate Message Catch Event: Similar to the Receive Task, the Intermediate Message Catch Event is used when Zeebe needs to receive a message from an external system before a workflow instance token can progress to the next step. (Later in the post, we’ll explain the difference between the Receive Task and Intermediate Message Catch Event.
- Intermediate Timer Catch Event: An Intermediate Timer Catch Event acts as a stopwatch. When a workflow instance arrives at the event, a timer is started. When the timer fires (e.g., after a specified interval), the workflow instance progresses according to the sequence flow.
Gateways
Gateways are used to control the flow of a workflow instance token. A gateway can be used for parallel execution or to specify when a token should only take one of the multiple paths. Zeebe currently supports three types of gateways:
1. Exclusive (XOR) Gateway: A token will take only one of the outgoing sequence flows from an Exclusive Gateway. Every sequence flow has a condition that is evaluated based on the current workflow instance payload. In the example below, a workflow instance will follow a different path depending on whether the total price of items in the order is greater than or less than / equal to $100.
2. Parallel Gateway: When a workflow instance token arrives at a parallel gateway, all outgoing sequence flows are followed. Execution of parallel paths continues independently until e.g. another merging parallel gateway. In the example below, we can execute the Process Payment and Fetch Items tasks concurrently, and we won’t progress to the “Ship Package” task until both of these tasks are complete.
3. Event-based Gateway: An event-based gateway makes it possible to decide on a sequence flow for a workflow instance token based on events. Each outgoing sequence flow of the Event-based Gateway needs to be connected to an Intermediate Catch Event (message or timer). When a workflow instance token arrives at an event-based gateway, it waits there until the first of the events is triggered. It then takes the outgoing sequence flow of this first triggered event and continues. In the example below, a token will wait at the Event-based Gateway until we correlate the relevant message to the instance or after 60 minutes, whichever comes first.
Message and Timer Boundary Events
Message and Timer Events can also be attached to activities to either a) interrupt the activity to which the boundary event is attached and follow the sequence path out of the boundary event only or b) create an additional execution without interrupting the activity to which the boundary event is attached.
1. Interrupting Boundary Events: These interrupt the activity to which they’re attached, and a token will follow only the sequence flow out of the attached event. We might attach an Interrupting Message Boundary Event to the “Fetch Items” task in our order workflow and cancel the order as a whole if the customer issues a cancellation request while this “Fetch Items” task is in progress. In this case, the Fetch Items task would not be completed, and the instance token would also not progress to the Ship Package task.
2. Non-interrupting Boundary Events: Non-Interrupting Boundary Events create a parallel execution following the sequence flow out of the boundary event without interrupting the initial execution path. We might attach a Non-Interrupting Timer Boundary Event to the “Fetch Items” task in our order workflow and send a delay notification to a customer if this task hasn’t been completed within 48 hours then send another update every 48 hours after that. The token will still follow the “happy path” as modeled, meaning that the “Fetch Items” task will not be cancelled. Zeebe supports both Non-Interrupting Message Boundary Events and Non-Interrupting Timer Boundary Events.
Until now, the Receive Task and Intermediate Message Catching Event looked similar in terms of functionality. The ability to attach Boundary Events is a unique feature of the Receive Task. For example, if we haven’t received an expected message within a specified time period, we could trigger an escalation.
Embedded Subprocess
A Subprocess is an activity that contains other activities, gateways, events, etc., which itself is part of a larger process. A Subprocess is completely defined inside a parent process, and that’s why it’s often called an Embedded Subprocess. In Zeebe, the primary use case for a Subprocess is to create a new scope for events.
Events that occur during the execution of a Subprocess can be caught by a Boundary Event on the boundary of the Subprocess. For a different take on an order cancellation example, we might allow a customer to cancel an order as long as we haven’t yet completed the Ship Package task. We can use an Embedded Subprocess to express this logic.