Errors are inherently part of software development. They can happen because of several reasons. One common definition of a software error is a mismatch between the program and its specification. In other words, we can say, a program has an error when the program does not do what the end-user expects. In this blog post, we want to share few concepts about dealing with errors in BPMN and of course in Camunda.

BPMN uses the error event to handle the occurrence of errors during the execution of a certain activity or at a certain point in the flow of a process. There are few basic considerations

• The error event can appear as an
  • start event only for event sub-processes (catching type)
  • intermediate attached event (catching type)
  • end event (throwing type)

There is only place to throw an error, at the end of a flow. The reasoning behind is, an error cuts the normal flow of a process, and it does not make sense to continue until the error is handled. Handling an error can only be done in an activity coming from an attached event, or inside one event sub-process.

Let’s now imagine the following situation, an activity needs to handle many errors. If this is the case for several activities in a process, the result is:

• one error attached event is required for each error to be handled

A direct consequence of the previous statement is that the process gets cluttered. So what can be done to avoid cluttering the process?

One thing to understand is that in BPMN two types of errors are recognized, and each type can be dealt better with specific symbols and behaviors of a given BPMN engine, in our case the Camunda Platform engine, the following table can help visualize the possibilities.

Type of error	Definition	Handling
Business Errors	Should be handled in the logic of the process	With symbols: Error, Escalation
Technical Errors	Should be handled by the engine as error in the implementation i.e. code, connection, infrastructure, etc.	As incident in the Camunda engine

Now, how can technical and business error be set apart? By answering the following question: Does the error have some business meaning and causes an alternative process flow (like “item not on stock” in an inventory process) or is it a technical malfunction in the infrastructure or code (like “network currently down”)?

When we let technical errors be handled by the engine, such as in the case of incidents, nothing is to be done in the process diagram, reducing the need to add explicit error events. But there are still many other business errors that might occur and clutter the model.

One possible solution is, using an event sub-process that can distinguished between all business errors. However doing this with plain BPMN is a real challenge. With Camunda BPMN Platform there is the possibility to implement the mentioned solution, it requires the use of the class:

org.camunda.bpm.engine.delegate.BpmnError

The class provides a constructor where we can define a code and a message:

BpmnError(String errorCode, String message)

with the errorCode and the message, a creative approach inside a event sub-process can be implemented.

The first step is that the activity that contains the possible errors, does the actual throwing proactively i.e. checking in code the conditions that produce the business errors and the throwing them as in the following code snippet:

if (some variable checkings and so on ...) { 
    throw new org.camunda.bpm.engine.delegate.BpmnError("GenericError", "errorB"); 
}

The second step is, having an event sub-process catching always the same errorCode and then distinguishing the errors using the message variable together with a X-OR gateway that redirects the flow to specific remedy actions. Important here is that using the properties panel of the Camunda modeler, we need to configure the start event of the event sub-process to define the name of the message variable field.

Using this approach will reduce the need to add one error attached event for each possible error to handle, effectively reducing the cluttering in the model. The model keeps its readability by having a general error handling mechanism, and if required, activities can still have single error attached events for special cases.

Putting everything together in a model the solution looks like this:

An example made for educational purposes with javascript can be found in the following github repository:

GitHub – bassgelo/BPMNErrorHandlingDemo: BPMN Error Handling Demo

Written by
Gerardo Manzano
Engineering Manager at JIT