Blog

10.09.2021. | Autor: Gerardo Manzano

BPMN Error Handling Mechanism – Dealing with many errors in a process

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 ErrorsShould be handled in the logic of the processWith symbols: Error, Escalation
Technical ErrorsShould 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

Weitere Blog

12.08.2021.

Company insights – the teams behind JIT

Autor: Melissa Pürstinger

If you’re an attentive reader of our blog posts you might have already noticed that the topics and projects the people of JIT are working on are quite diverse. We are an IT company that is successfully covering more than one area and that is only possible because of the vibrant and motivated teams behind […]

Blog lesen
29.07.2021.

Ruby external task worker

Autor: Maximilian Kamenicky

“The value of a system is often defined by how well it integrates with other systems” The best software is limited if you cannot integrate it with existing frameworks. In the case of Camunda, this fact is all the more true. Imagine a workflow automation engine without a way to interact with the existing software. […]

Blog lesen
15.07.2021.

REST Schnittstelle von Camunda Plattform in External Java Service Tasks aufrufen

Autor: Maximilian Kamenicky

Erfahren Sie mehr darüber, wie man mit Camunda REST-Webservices aufrufen und nutzen kann. In dieser Blog-Serie zeigt Ihnen unser Experte zwei unterschiedliche Möglichkeiten um dieses Ziel zu erreichen.Der erste Beitrag (REST Schnittstelle von Camunda Plattform via Java Service Task aufrufen) hat gezeigt wie dies über Java Service Tasks geht. Wie man dies über externe Services […]

Blog lesen