Skip to main content

Variables and incidents

Every process instance created for the process model used in the getting started tutorial requires an orderValue so the XOR gateway evaluation will happen properly.

Let’s look at a case where orderValue is present and was set as a string, but our order-process.bpmn model required an integer to properly evaluate the orderValue and route the instance.

./bin/zbctl --insecure create instance order-process --variables '{"orderId": "1234", "orderValue":"99"}'

Advance an instance to an XOR gateway​

To advance the instance to our XOR gateway, we’ll create a job worker to complete the Initiate Payment task:

./bin/zbctl --insecure create worker initiate-payment --handler cat

We’ll publish a message that will be correlated with the instance, so we can advance past the Payment Received intermediate message catch event:

./bin/zbctl --insecure publish message "payment-received" --correlationKey="1234"

In the Operate interface, you should now see the process instance has an incident, which means there’s a problem with process execution that must be fixed before the process instance can progress to the next step.

operate-incident-process-view

Diagnosing and resolving incidents​

Operate provides tools for diagnosing and resolving incidents. Let’s go through incident diagnosis and resolution step by step.

When we inspect the process instance, we can see exactly what our incident is: Expected to evaluate condition 'orderValue>=100' successfully, but failed because: Cannot compare values of different types: STRING and INTEGER

operate-incident-instance-view

To resolve this incident, we must edit the orderValue variable so it’s an integer. To do so, take the following steps:

  1. Click on the edit icon next to the variable you’d like to edit.

operate-incident-edit-variable

  1. Edit the variable by removing the quotation marks from the orderValue value.
  2. Click the checkmark icon to save the change.

operate-incident-save-variable

We were able to solve this particular problem by editing a variable, but it’s worth noting you can also add a variable if a variable is missing from a process instance altogether.

There’s one last step: initiating a “retry” of the process instance. There are two places on the process instance page where you can initiate a retry:

operate-retry-instance

You should now see the incident has been resolved, and the process instance has progressed to the next step.

operate-incident-resolved-instance-view

Complete a process instance​

If you’d like to complete the process instance, create a worker for the Ship Without Insurance task:

./bin/zbctl --insecure create worker ship-without-insurance --handler cat

The completed process instance with the path taken:

operate-incident-resolved-path-view