Background

Mule API architecture suggests 3 layers of implementation i.e Experience layer, Process layer, and System layer.

What happens if an error occurs at System layer? You might have observed that whenever a system API throws an error (for example 404), the HTTP call in Process API goes into exception (org.mule.module.http.internal.request.ResponseValidatorException).

If you are using the generic apiKit Global Exception Mapping, it will be handled by 500 and your process API will return "500: Internal server Error: Response code 404 mapped as failure." Moreover, your Experience API will return "500: Internal Server Error: Response code 500 mapped as failure."

The client application that is consuming your experience API will have no clue of what went wrong with the response it received.

Requirement

We wish to propagate the response of system API to Experience API, so the client application consuming the experience API can figure out what exactly went wrong.

Solution

In the process API, the HTTP component that invokes the systems API, configure the "Target" as a flow variable.

In Exception handling Strategy, a catch exception strategy within a choice exception strategy can be used.

Set the Execute when: #[exception.causedBy(org.mule.module.http.internal.request.ResponseValidatorException)]

Set the property HTTP status by trimming the response message available.

Set the Payload with appropriate response data along with the flow variable saved.

Repeat the same with Experience API.

Conclusion

If data abstraction is not the requirement and we wish to propagate the error code from underlying APIs to client applications, this process can be used.