Author: Sanket Kangle

Error handling scenario 1: 

In this scenario, there is a flow level error handler with an On error propagate scope. As the flow is executing and the error occurs at the event processor labeled E. Because of this processor P and any subsequent processors will never be executed as shown in the exhibit below.

In this scenario, the Mule event is passed to the first processor of the flow level error handler. after all processors from an on error propagate scope are executed, the error gets rethrown. As this flow was the calling flow, the error response is returned to the HTTP listener as shown in the exhibit below.

Let us see this scenario with a working example.

The XML of the above flow is as follows.

Debug the application to understand how the error is handled.

Once your application is successfully deployed, Go to Postman or Advance rest-client and send a request to the API. As seen in the exhibit below, the payload is not set yet.

Moving one step forward, the payload is set to “Max Mule” (exhibit below)

When another step is taken, the error is thrown by the “is null” validation processor

As we take another step, the Mule event is passed through the flow level error handler.(exhibit below)

The processors in on error propagate scope are run and you can see the payload is now set to “on error propagate-flow level error handler” 

The error is also logged on the console.

The logger inside the On Error propagate scope logs the payload when taken the next step and the application ends, and the error message is sent back to the HTTP listener and can be seen from the postman.

Error handling scenario 2

In this scenario, there is a flow level error handler with an On error continue scope. As the flow is executing and the error occurs at the event processor labeled E. Because of this processor P and any subsequent processors will never be executed as shown in the exhibit below.

In this scenario, the Mule event is passed to the first processor of the flow level error handler. after all processors from an on error continue scope are executed, then the error does not gets rethrown and a success message is returned. As this was the calling flow, a success message is returned to the HTTP listener as shown in the following exhibit.

Let us see this scenario with a working example.

The XML of the above flow is as follows.

Debug the application to understand how the error is handled.

Once your application is successfully deployed, Go to Postman or Advance rest-client and send a request to the API. As seen in the exhibit below, the payload is not set yet.

Moving one step forward, the payload is set to “Max Mule” (exhibit below)

When another step is taken, the error is thrown by the “is null” validation processor

As we take another step, the Mule event is passed to the flow level error handler. (exhibit below)

The processors in on error continue scope are run and you can see the payload is now set to “on error continue-flow level error handler”

The error is also logged on the console.

The logger inside the On Error continue scope logs the payload when taken the next step and the application ends, and the success message is sent back to the HTTP listener and payload can be seen from the postman.

Error handling scenario 3

In this scenario, we will examine the effects of an error occurring in the child flow. the source flow will call the child flow and passes the Mule event to it. An error occurs in the event processor labeled E and subsequent processors are not executed. The error is rethrown and the subsequent processors in calling flow also are not executed.

The source flow and child flow, both have flow level error handlers with an on error propagate scope. When the error occurs at processor E, the Mule event is directed towards the first processor in on error propagate scope of child flow. After scope execution is completed, the error is rethrown to calling flow. In calling flow, again it is handled by the on error propagate scope and finally, the error response is returned to the HTTP listener.

Let us see this scenario with a working example.

The XML of the above flow is as follows.

Debug the application to understand how the error is handled.

Once your application is successfully deployed, Go to Postman or Advance rest-client and send a request to the API. As seen in the exhibit below, the payload is not set yet.

Moving one step forward, the payload is set to “Max Mule” (exhibit below)

With another step, the flow reference will pass the Mule event to the child flow. (exhibit below)

When another step is taken, the error is thrown by the “is null” validation processor(exhibit below)

with the next step, the Mule event is passed is flow level error handler(exhibit below)

The payload is modified by the processor in on error propagate scope with the next step.(exhibit below)

When we come out of the error scope, the remaining flow is suspended and the Mule event is returned to the calling flow with the error object. (exhibit below)

Now, as there is an error in the calling flow, the Mule event is passed to the flow level error handler of the calling flow. (exhibit below)

The payload is modified by the processor in on error propagate scope with the next step. (exhibit below)

With the next step, the payload is logged, remaining processors of the flow are suspended and an error response is sent back to the HTTP listener, which can be seen in the response of the Postman.

Leave a Comment