Advanced Process Integration Tips - Dealing with Unexpected Errors

Using advanced process integration techniques becomes essential as you evolve your developer skills while integrating more and more of your business workflows. One of the most common questions is how to effectively handle unexpected errors without just dropping out of a workflow?

During the development phase, it is expected that developers deal with unexpected behavior along with predictable and unpredicted errors that might happen during the execution of code. Consider the following situation:

There are several business outcomes to solve in our example scenario, all it takes is that the developer properly handles this incidents. There are cases where only the main business scenarios are described by the business owners, and the development team does not have enough information to implement the exception handling. In these cases, the Business Analyst of the project should be involved in order to define the outcomes of these scenarios.

When handling errors like this, for example, in a Java or Javascript code, the developer directly implement exception handling with try and catch; When considering the endpoint layers, developers likely uses HTTP codes to transmit a proper message to the consumer; but, how to deal with exceptions and errors when working with a business workflow?

Exceptions done right

Give a look at the following situation, considering it is at an initial development phase. The "happy path" for this trip schedule flow is:

1. The user selects a trip (User Task);
2. An embedded subprocess starts to handle pre-reservation;
3. Both hotel and flight tasks are parallelized for quicker processing ( Divergent Parallel Gateway); Flight and hotel availabilities are checked (RestTask);
4. Flight and hotel are pre-reserved (Rest Task);
5. The process only ends steps are completed for both flight and hotel( Convergent Parallel Gateway);
6. Finally, the user confirms the trip(User Task).

There are two gaps in this process that can lead to instances aborted or failed:

• First uncovered scenario: The selected option (flight or hotel) is not available (a business exception);
• Second uncovered scenario: One or more rest services are unavailable (a runtime exception);

Business exceptions

Business exceptions are errors that are not technical. They are not caused by unexpected errors in the code itself. Some examples of business exceptions:

• Sell a product that does not exist in the inventory;
• Reserve a seat in a full theater movie
• Register a monthly payment twice in the same month

These exceptions are examples of behaviors directly related to each domain. The recommended way to handle business exceptions would be to capture them using error events, and then triggering following actions to handle the error according to the desired business logic. By using this approach, the whole process - including the handling of errors - is clear for all the personas involved in the project. This will facilitate validation by the business users and ease further maintenance or development enhancements.

Look at the following process of a store which is in tackling their own digital transformation. They allow their customer to select products in a rich multi-channel online store, once payment is confirmed, a personal shopper manually chooses the items. Finally, the delivery team takes the order to the customer address.

Both tasks Charge from credit card service and reserve products from stock are service tasks. Eventually, the store can run out of available products in the stock when the task reserve products from stock is triggered. Does this look like a business exception to you?

• Reserve product from stock when the number of available products is zero.

We just identified a business exception and will name it NoAvailableProductException. Let's consider how this (Java) service treats an error like this:

if (!product.isAvailable()){
    log.error("Product is not available, throwing exception."); 
    throw new NoAvailableProductException(Response.Status.CONFLICT);
}

In this example, you can consider that NoAvailableProductException extends a more general WebApplicationException.

Now, the author of the process design knows which error the service will throw in case of a NoAvailableProductException: HTTP 409 code.

javax.ws.rs.core.Response.Status.CONFLICT relates to HTTP 409.
As per RFC specification, this code should be used in situations where the user might be able to try the same request and possibly get a different response. The server should include information about the error in the payload for the consumers.
See more details in: https://tools.ietf.org/html/rfc7231#section-6.5.8

The business automation specialist also receives the updates from the business team, and the new exception flow business scope is also defined. If the product is not available, the personal shopper should call the consumer and switch missing item for a similar one or remove it from the order. The order price will change and the new value should be charged.

Scenario 1: The BA specialist increments his process to deal with the business exception thrown in a specific task: He/She added a boundary intermediate catch event to the REST Task. The error code is configured on the error events properties.

In this way, the business analyst can capture business exceptions thrown in specific tasks and provide proper handling for each scenario. But when there are too many possible errors, this approach can make the process too verbose and might affect the clarity of the flow.

Considering that the same business exception can be thrown by more than one task, the author can choose to group the tasks in a subprocess and catch the exception in the parent process definition. See the following scenario.

Scenario 2: Tasks inside a subprocess throw an error end event, which will be catch and handled by the parent process.

Another possible approach is to store the output of the processing in a process variable instead of throwing an exception. Based on the variable value, a gateway can lead to an end error event which will be handled by an event subprocess.

Scenario 3: Process throws an error endevent, which will be handled by an event subprocess with a starting error event.

The author of the process should choose the proper option which better suits the business needs, worrying about the variable scopes and with the understanding and maintainability of the process. On scenario 2 for example, the variables contained inside the subprocess, will not be available during the handling of the exception in the parent process.

Treating business exceptions inside a business process is considered an advanced process modeling technique, and is crucial for proper implementation of successful projects. The Business Exceptions also matters for the organization improvement and the modeling of it can also lead to the creation of business monitoring dashboards.

Technical exceptions

Technical exceptions are raised within the code implementation itself and are not related to the domain flow. It can happen on script tasks, on custom code implemented on "On Entry" an "On Exit" properties of tasks and custom Work Item Handlers. Some examples of technical exceptions:

• Can't unmarshal an object into a specific class
• Try to execute an operation in a null object
• Try to cast an object which cannot be cast

Integration with external components should be handled by external services and not by treated by the process design itself.

This recommendation is based on the fact that processes that fail with technical exceptions are unrecoverable. To learn more about technical error exception handling:

https://docs.jboss.org/jbpm/release/latest/jbpm-docs/html_ single/#_technical_exceptions

These kinds of errors can and should be avoided by leveraging the usage of custom code to necessary scenarios, and by increasing the usage of the provided native features. Exceptions raised on script tasks, cannot be caught and handled by the error events demonstrated on the "Business Exceptions" examples.