Error Handling Strategy in Mule 4

Author: Putul Mandal

Introduction:

This document explains  various error handling techniques in Mule 4 and along with validators.

Let’s understand the scenarios:

  1. Calling a flow without queryParam
  2. Calling a flow with queryParam but null value
  3. Calling a flow with queryParam and value as “number”. 

These are the three points we will be validating.

Here we are just simply making a project and we are not logging anything and after the application is deployed we will see without passing any queryParam and passing a queryParam we will see the difference between the two.

  1. Without queryParam:

We can now go and check in the console

Here in Query String it is empty.

  1. When queryParam is passed but without value

Now we can go in the console and we can see that when we  pass the queryParam but without value so then also it exists now let’s see when we pass the queryParam with value.

  1. When queryParam is passed with value.

Now we we go and check in the console

Here we can see that  it exists with the value we passed.

So from all  the three conditions we can make the difference.

Use of Validators:

For using validators first we have to add the validation module to the mule palette.

  • First we will use the validate size to check whether anything exists in our array or not.For that we will drag and drop the validate size from the mule palette to the above flow and will do its configuration.
  • Click ok to configure and then give min value to 1 .

Then deploy the application and once the application is deployed and when we send request from Advanced REST Client without giving any queryParams the response will be like this:

Now we have not giving any error handling in the flow then also it is handled by the default error handler i.e, the on error propagate default error handler and giving the response with printing the validator message i.e, ‘input parameters missing’. Now we will add error handling to our flow before that we should know all these defined below:

About error we can say that any error will have few defined components.

  1. Error description – will always be string. Syntax: error.description
  2. Error type – will always be Object. Syntax: error.errorType
  3. Error cause – will always be a Java Object. Syntax: error.cause
  4. Error message- Syntax: error.message

We can go back to the flow and click the listener responses and we can see there the error.description part.

Scope: In error handling there are two scopes.

  • On Error Propagate
  • On Error Continue

Coming to the flow now in which we will drag and drop the on error propagate scope and in the scope will add a set payload giving a message.

Now redeploy the application.

We will get a response like this i.e, 500 Server Error when we will give the request without giving any queryParams.

In On Error Propagate it works like a Rollback function i.e, even when the error is thrown it does some action and terminates the entire flow and then throws the entire error to its parent flow it means that it handles the error but it does not kill the error.

Now instead of On Error Propagate we will put On Error Continue in the flow and give a set payload there giving a message.

Again redeploy the application and send the same request.

We will get a response like this.

Here we can see that in On Error Continue it is not throwing the error to the parent flow it’s giving an 200 OK response.From here we can make the difference between both error scope i.e, in On Error Propagate it is giving 500 Server Error and also it is giving the message given in the validator but in On Error Continue it is giving 200 OK Response and giving the message given in the set Payload of the error Scope.

Now we will check by giving queryParams but the value will be null.So when we will provide queryParams but no value for it it will not show any error as the queryParams is there.

Coming to the flow add a Set Payload and give a message there to check whether it is executing or not.

Deploy the application and send requests providing queryParams the response will be like this as shown.

Here we can see that it is executing the flow without throwing any error and the Set Payload message is printed.

Now we will use the Is not null validator to check that the queryParam is null or not and if it is it will throw error.In the same flow drag and drop a Is not null validator and do the configuration as shown.

Now debug  the application when the application is deployed send the request to see the response.

Then come to the flow to see the response.

Here we can see that the error is thrown as we have not passed any value to the queryParams so it will be handled by the error scope.

As the error scope is On Error Continue to so it will handle the error and give the response 200 OK and print the message given in set payload of the error scope.

Basically in error handling the error scopes handle the error either give 200 OK response or 500 Server Error but they give the response to the parent flow i.e, the main and not the same flow.So here it is printing the message given in the set payload of the error scope and after that the flow stops as this is a single flow.Here if we would be having another flow i.e, the main flow then it would handle the error and again continue in the same flow.

Now as we have been done with the requirements i.e, Flow needs to have a queryParam , queryParamshould not be Null.So now we will check that the value of the queryParam should be “number”. For that we will use the Is number validator.

Coming to the flow drag and drop the Is number validator as shown below and do the configuration.

Now again debug the application and when the application is deployed then send the request passing queryParams  and passing the value which is not a number .

We will get the error as we are not passing numbers and the error will be handled by the On Error Continue scope.

And then the flow will be stopped.

Error Type And Error Handler: Global Error Handler

In this we are having two flows.

Here we will add error handling in the flow and the error which will be handled here will be handled by the global error handler which we will add.

Coming to the flow add error scopes to the flow as shown below:

Here we are adding On Error propagate scope and here we can define the type of error as shown in the figure.

Here after defining the type of the error we have added a set payload and a logger and in the payload we have given the statement in which it give the description of the error. We can add more error scopes in the same flow defining different types as we have added as shown below:

This is the full flow.We have added three scopes now whichever error will be there it will be handled by that error scope.Now we will do the error mapping where we can add our defined error.

Here we are mapping errors in the validate size by giving names. We are going to the error mapping part and there we are adding as shown in the figure.Now add one more mule configuration file and name it global error as shown below where we will do the global error handler part.

Now in the globalError file add an error handler as shown below to add error scopes there.

Now add this error handler to the global elements so it will be used by the flow.To add it in global  follow the steps i.e,

  •  go the global elements 
  • click on create and 
  • then in the global configuration click the configuration as shown in the figure.

After that choose the global handler and then it is added in global elements like this.

As we can see now that it is added in the global elements as shown in the figure below:

So now coming to the global error handler part we will add error scopes there, basically in global error handler we only add ANY here we will use the error which we have mapped and the ANY error as we know first it will try to handle the error in the same flow and if it is not handled there then it will come to the global error handler and it will be handled there.So now in the global error handler we will add On Error Propagate scope and a set payload and a logger where we will give the error.description in the payload as shown in the fig. Below

We will add another error scope for the type Any error.

So now we can deploy and check the errors.

We use cookies on this site to enhance your user experience. For a complete overview of how we use cookies, please see our privacy policy.