Exception handling in workflows using Flowable

This is the 3rd blog of the series “Business Process automation”. If you haven’t checked them till now, I strongly recommend having a look. Part 1, Part 2

Exceptions are part of any process. As a process modeler or an application developer, we always tend to write robust applications. Developers building business processes must able to handle exceptions to the business case to ensure that the process itself is resilient and can continue after failures occur. The exception handling logic differs based on what is your problem statement and what tools you have at your disposal. In this blog, I tried to define various exception handling methods using pattern language. Each pattern follows a specific structure, called Context (a common setup where you see the problem is repeating), Problem (statement), Forces (conditions under which the proposed solutions can be recommended), and a Solution. So let’s jump into it.

1. XOR or Exclusive Gateway

Context

You are tasked to create a workflow.

Problem

You want to handle the non-happy flow in the workflow.

Forces

• You want a naive approach to model non-happy scenario.
• Your tool is not fully BPMN2.0 specification compliant.

Solution

The BPMN service tasks allow the execution of a custom java code. When executing, you can catch the error and set some variables. And then use it in the BPMN diagram to model the flow. Let me tell you, it’s not an actual exception handling but modeling the flow based on result variables. You can use expression like ${IS_SUCCESSFUL == false} for XOR gateway.

Handle error via XOR gateway

The “Validate Data” service task executes following Java delegate.

Alternate Solutions

As mentioned, this is not a correct way of exception handling. If you want to go with a more BPMN compliant way, refer to the below solutions.

2. Error Boundary Event (BPMN 2.0)

BPMN 2.0 specifications adds capability to catch error events and trigger custom process flow. We will discuss them in details below.

Context

You are tasked to create a workflow.

Problem

You want to handle the non-happy flow in the workflow, and divert the execution flow based upon event.

Forces

• Your tool is BPMN2.0 specification compliant.
• You want to handle multiple error scenarios arising from a particular activity/process context.

Solution

A boundary event is attached to a boundary of the activity or a subprocess that can be triggered while the associated task is being performed. As the name suggested, Error Boundary Event will listen for any errors being thrown out of associated activity, and if the thrown error code matched with its definition, it will alter the flow and start executing its attached flow.

Error Boundary Event

The above process retrieves the contact details by calling some service or REST API. User selects the contact to which he/she wants to send the mail. The service task “Prepare for Mail” validates the input, checks whether the email address is blank or empty, if so, it throws a BpmnError. I have attached the Error boundary event with Error Code WRONG_EMAIL_DETAILS, which matched with one thrown from our java code below.

You can see a similar pattern used in the implementation of Service Registry —

The service registry is a feature of Flowable Enterprise offering which allows you to invoke any REST API or Java beans using modeler friendy UI.

Error handling in service registry

In workflow above “Call HTTP Service” is a service registry that calls a REST endpoint. Service registry allows you to handle HTTP status codes via a property called “Handle status codes”. You can specify the HTTP status codes you want to handle e.g. 404 and when flowable encounters the error, it will throw a BpmnError with prefixing Service to status code, e.g. Service404.

3. Use Internal Transactions

Context

You want to handle exceptions arising after activity executions.

Problem

In case of exceptions you don’t want to complete an activity but to roll back the transaction to a previously known state.

Forces

• You need to validate user inputs.
• You need to validate the service response.

Solution

The Flowable workflow engine executes the workflow steps in clearly identifiable database transactions. If in any step exception occurs, it rollbacks all executed activities and comes back to its original state. As this is well tested and guaranteed behavior from the engine, we can leverage it to handle scenarios like

• User uploads the file in User task. We need to check the contents of the files, and if they are not OK, we will show an error message to a user.
• When a user submits data, we will persist that data to the database. If an error occurs we will ask users to retry.

There is a very good blog post from Flowable about database transactions and asynchronous flags. You must check it out to get more insight about working.

Using Internal Transactions

Once a user submits the Upload File user task, the flowable engine will create the new transaction starting from the end of the user task and execute the “Validate Output” service task. The service task code is —

Notice when the ExcelValidator#validate method returns false, we throw FlowableIllegalArgumentException which results in the rollback of the current transaction. The flowable engine is configured to display the exception message on the form as below —

Consequences

This approach allows you to use internal transactions for rolling back to previous stages. But it does not do anything to handle the side effects of executed activities. E.g. You have a cash transfer process, wherein in the first step, you debit the amount and in the next step, you credit the amount. But at the second stage, if the transaction fails, you are left in the inconsistent stage as you have not credited the money back into the debitor’s account.

To handle side effects you need to use compensations.

4. Compensation (BPMN 2.0)

The BPMN 2.0 transactions and compensation allow for compensating already executed actions during rollbacks.

Context

You are creating a transactional process, where activities produce side effects.

Problem

You need to compensate for the side effects of the failed activities in transactions in case of failure.

Forces

• The workflow is transactional.
• Workflow steps create side effects in the system.
• The workflow engine is BPMN 2.0 compliant.

Solution

Compensation is concerned with undoing steps that were already successfully completed because their results and possible side effects are no longer desired and need to be reversed. If an Activity is still active, it cannot be compensated, but rather needs to be canceled. Cancellation in turn can result in compensation of already successfully completed portions of an active Activity, in case of a Sub-Process. Compensation is performed by a compensation handler. A compensation handler performs the steps necessary to reverse the effects of an Activity. In the case of a Sub-Process, the compensation handler has access to Sub-Process data at the time of its completion (“snapshot data”).

Throw Compensation Event

Compensation is triggered by a Throw Compensation Event , which typically will be raised by an error handler, as part of cancellation, or recursively by another compensation handler. That Event specifies the Activity for which
compensation is to be performed, either explicitly or implicitly.

Compensation Boundary Event

The compensation boundary event activates when the attached activity is finished. When a compensation event is thrown, it executes the attached logic.

Transaction and Compensation Handling

In the example above, when the “Trigger Cancellation” event is thrown, the compensation activities namely “Undo Book Hotel” and “Undo Book Flight” get executed as many times as their host activities. This allows you to write to compensating logic to undo the work done by the host activities.

Covering all the details about compensation will require another blog post. I will add the link once I write one.

5. Handling errors form child process

Context

Your workflow contains multiple subprocesses which complete in an error state.

Problem

The subprocesses sometimes end with an Error end event and the callee process needs to take action based on the error state.

Forces

• Subprocesses end with “Error End Event”

Solution

It’s always a good practice to denote all states of workflow. This approach is advocated while creating a re-usable process. E.g if you create the KYC process, it may complete in an error state, when documents are not correct. In this case, you want to propagate the message to the caller, and it needs to divert flow accordingly. To handle this scenario, you end the subprocess with “Error end event”.

Child Process ending with Error End Event

You need to use the same error code as the child process to configure the “Error Boundary Event” of Call Activity.

Parent Process with Error Boundary Event

In this blog post, I tried to cover the most followed patterns of error handling with some examples. I hope you liked it. Let me know your favorite pattern in the comments.

The above patterns allow the modeler to choose the correct implementation of handling error. But what if you are a support engineer or a platform developer and you want to track exceptions coming out of the engine or jobs created in the workflow? If you are curious, wait for my next blog post, where I will write about how to monitor and manage the jobs.