Quick intro to handling Error in Mule 4

In MULE 4 when a event is processed Messaging errors happens within the flow when there is some kind of processing issue and the flow execution stops. This post explains how messaging errors are handled and how the error objects are created when a Messaging Error occurs. These Error Objects and are handled with error handler. Each error handler contains one or more error handler scopes. Each error scope can contain many number of event processors.

In mule error is defined by an error object and has two properties:

error.description: a string that provides a description regarding the problem.

error.errorType: an object used to characterize the problem and allow routing within an error handler defined by namespace and identifier. (see Fig 1.)

Each errorType has a parent. VALIDATION:INVALID_BOOLEAN has VALIDATION:VALIDATION as the parent which has MULE:VALIDATION as the parent. The listener can also be configured to respond error description (see Fig 2).

plektonlabs-mule-error-nomenclatureFig 1: Nomenclature of  Mule error Object
mule-error-types1
Fig 2. Listener component body is modified to show error description.

In the http listener (Fig. 2) change the error options under Response tab to error.description that way the response will give an idea of the error generated.

Application level error 

 In a Mule applications  implements a fail-safe in case an error is thrown in the flow and it wasn’t been able to be caught anywhere within the application. This is referred to as application level error handling and can be implemented two ways:

(a) Mule Default Error Handler: If no error handler is defined then Mule default error handler is used which implicitly and globally handles all messaging errors thrown in the application. It stops the application and logs the error. 
(b) Global Error Handler: The Global Error Handler can be configured to process errors and can be customised, therefore you can put an On-Error Propagate or an On Error Continue scope in the global error handler.

The global error handler is usually configured in global.xml with global configuration (Fig 3a). In this example an On error continue is used. Once the listener is triggered the payload is set to ” success begin main flow” (Fig 3a). The “Is number” validator throws an error.  The error is handled by global error handler since there is no error handler scope in the flow. On Error Continue scope handles the error and set the payload to  “Error – Main Flow”.  A success 200 response is returned (Fig. 3b)

Flow level error handler 

Handling errors at the application level is a good approach but often flows need specific logic to handle errors when an error happens within the flow (i.e. reprocessing logic, error logging, etc). In Mule 4 deals this with by allowing specific error handling logic within each of the flows. There are two error handling scopes in Mule 4 (a) On Error Propagate (b) On Error Continue.

Fig 3a. Setting up global error handler
Fig 3b. Is number validator throws an error and the event is passed to global error handler scope. The payload is set to “error-main flow” and error description is not returned. The subsequent flow after the error is not executed.
On error continue: 
  • All the processors in the error handling scope are executed.
  • At the end of the scope the rest of the flow that threw the error is not executed.The event is passed on to the next level as if no error was generated.
  • HTTP listener returns success response.

Once the listener is triggered the payload is set to ” success begin main flow” (Fig 4a). The “Is number” validator throws an error.  The On Error Continue scope handles the error and set the payload to  “Error – Main Flow”.  A success 200 response is returned (Fig. 4b)



Fig 4a. Is number validator throws an error and the event is passed to on error continue scope. The payload is set to “error-main flow” and error description is not returned. The subsequent flow after the error is not executed.
Fig 4b. Is number validator throws an error and the event is passed to on error continue scope. The payload is set to “error-main flow” and returns the response payload .
On error propagate:
  • All the processors in the error handling scope are executed.
  • At the end of the scope the rest of the flow that threw the error is not executed. The error is rethrown at the next level and handled there.
  • HTTP listener returns error response.

Once the listener is triggered the payload is set to ” success begin main flow” (Fig 5a). The “Is number” validator throws an error.  The On Error Propagate scope handles the error and but does not set the payload to  “Error – Main Flow” but rethrows the error.  An error response of 500 response is returned (Fig. 5b) describing the error along with the payload.

Fig 5a. Is number validator throws an error and the event is passed to on error propagate scope. The payload is not set to “error-main flow” but returns the payload along with error description. The subsequent flow after the error is not executed.
Fig 5b. Is number validator throws an error and the event is passed to on error propagate scope. The payload is not set to “error-main flow” but returns the payload along with error description.

Share This Post

Share on facebook
Share on linkedin
Share on twitter
Share on email

More To Explore

Blog

The Use of APIs in the Business Supply chain

Supply chains that mostly rely on legacy EDI (electronic data interchange) systems, a technology introduced over half a century ago to support communication with business

Blog

The 5 Foundations of API Governance

For many, governance is a necessary but tedious task. But when done right, governance offers a clear direction, breaks down barriers, and enables different parts

How can we help?

A little about yourself and we're ready to go

We pride ourselves on swift communication and prompt responses. Let us know what you're thinking and how we can help you.

Contact Information​

Head Office
75 Cornwall Drive, Ajax ON L1T3G2

Toronto Office
602 – 8133 Warden Ave, Markham, ON L6G 1B3, Canada

Phone: +14168902757
Email: info@plektonlabs.com

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.