How do you deal with connector errors during the execution of your BOS processes?

This article will present two different ways to deal with errors in your processes: error events and exceptions. We will provide an example for each, and we will give you their pros and cons so you can choose the one that best fits your needs.

Sending and Receiving error events

This method allows you to associate a error with a name to a connector.  If the connector fails, the process will catch that error with a boundary error event associated to that error name.

Error handling with a boundary error event

This will provide an alternate path that is taken to deal with your error.

However, this method has some major drawbacks:

• One can only associate a single named error to a connector, even if it can throw different types of errors. For example, for a database query connector, the server might be down or your query’s syntax might be incorrect, but the error raised by the failed connector will be the same.
• Upon receiving the error signal, you will no longer have access to the name of the error that occurred.

Throwing and Catching Exceptions

Another solution which is more complex, but also more powerful, is to use Java exceptions for error handling.

In this case, if you are developing your own connectors and using the Bonita API to execute some tasks, you can catch the exceptions that are raised by your connector.

Here is an example of a process that executes a task via a subprocess:

Exception handling via a subprocess

In this example the parent process will execute a “Caller step.”

This caller step will launch the subprocess and execute the “Exception throwing step” with this method:

runtimeAPI.executeTask(activity.getUUID(), false);

This automated task will execute a connector that throws a Java Exception. This exception will be then be thrown by the execute task method and can be used to provide appropriate error handling.

You can log the error and even store the Exception object as a reference to the last error that occurred.

Errors happen – so it’s useful to deal with them in advance with boundary events or exception handling.

You may download the example processes from the contribution page here:
Error management sample processes for BOS 5.5.1

Here is a recurrent use case: imagine a process design in which you have a human task that is a bottleneck preventing the execution of several other human tasks.

This stalled task might be at risk of exceeding a deadline, or needs to be cancelled. How can you warn the next actors who are waiting for an input to start their own work?

The current available option is to implement this go-around with a boundary event linked to an automated task that sends an email, then loops back to the parent activity. However, this is a bit awkward and clutters up your process diagram.

Here is a contribution that provides a better way of handling this kind of situation: a connector that will allow you to “get the next tasks’ actors.”

With this, you can retrieve a list of unique user names from the human tasks that are directly connected to your bottleneck task. Warning them of  a stalled process will simply require adding an email connector, or extending this one to send emails.

You can find this useful connector in Community Contributions.

Reporting is critical to decision making and the administration of a business application. Yet, too few people know about the real power of reporting and its ease of use.

Here’s a short video that will introduce you to the built-in reporting features that Bonita Open Solution provides.

You’ll see the default user dashboard and how to configure it to include some basic reports such as: “Steps per priority”, “Average step pending time” and “Number of cases started”.

Extract valuable information from your application in a few clicks!

You can use this feature to monitor runtime issues – solving them leads to better performance management, for instance, detect tasks that are exceedingly time-consuming and perhaps improve the process design to get rid of the bottlenecks.

Also, reporting can provide additional information needed when performing load balancing. For example, by detecting a variation in the volume of cases started; you may allocate more or less resources to it (be it servers or human operators).