The HTTP Status Code is part of the server´s response, this shows us how things went in a request. A request result can have different results as success or error. Here is a summary of HTTP status codes:
In Mule, when you get an error response from an HTTP Request, it eases the management of such errors by automatically mapping them to a list of errors. The list of errors is quick, simple, and handled in flows using error handlers.
But there is a slight problem: the connector just has the most used and standard error codes. Typically, most projects do not need to go deeper into these error codes, but they can be used anytime.
If you know what error codes can be mapped, you will save a lot of time. Seeing the next table will help you:
Even in this table, we do not add all the status codes existing, you can find a lot of pages that can show you a more complete list of HTTP status codes.
There are plenty of ways to manage these status codes, but we will show you two ways: easy and quick.
But first, we need to know what and how Mule returns these non-mapped errors. It returns to us a MULE:UNKNOWN type error, but this type of error can come from other kinds of errors, too. Then, we need to check the response code to be sure it is the one we want. Mule adds the following property error.errorMessage, where you can find response information and the HTTP response details. Inside the errorMessage property, we have the error.errorMessage.attributes.statusCode value, which shows us the HTTP response code.
In this way, we need to handle the non-mapped errors. We accomplish that by adding an error handler and catching the error returned by Mule.
Mule flow after step one. In this case, our error handle will contain an On Error Propagate connector.
Mule flow after step two, showing validation needed to check an HTTP Error Code not mapped.
Mule Flow with just a logger as a logic on the error handler, only for illustrative purposes.
The first way allows us to manage the errors in our flow and add all logic there, we could find situations where managing the error in our flow is not enough. If we already have a global error handler for all HTTP codes or if we want to add a global logic for that error, there are cases where we need a different solution. We will show you how to do it.
HTTP Connector In their Response validator configuration to show how it needed to be set.
Mule flow after step two, showing how choice connecter should be added..
Mule flow after adding a raise error connector.
Global error handler that will contain our error flow for our error raised on the last step.