Logging error responses in MuleSoft Scatter-Gather

The Scatter-Gather component in MuleSoft is a very nice component when you want to execute several steps in parallel. However, when an error occurs in one of the parallel flows, for example when a webservice returns a HTTP 500 response, you probably want to be able to log not only the error message, but also the error payload/body so you’re able to analyze the issue(s). After some debugging and research, it turned out to be fairly easy to achieve this using 3 steps in the Catch Exception Strategy.

The first step is to copy the exception variable to a flowVar, otherwise you will not be able to use this variable from the Transform Message in the next step.

Next, you will be able to build the actual log message using a Transform Message. In our case, we chose to include the following data in the log message:

• The message from the exception. This is the top level error message.
• The Element from the info HashMap. This contains information about where the error occurred in the flow file.
• Then we will check if the exception also contains an exceptions This is the case when the error(s) occur within one or more of the Scatter-Gather flows. Because we first check if this property exists, the exception handler is still compatible with faults that occur outside the Scatter-Gather as well. From the inner exceptions, we will extract the message and detailedMessage, but more interesting is that we can also access the MuleMessage from the Scatter-Gather flow, and select the (error) payload(s) from this.
• Finally we will also log the value of the payload at the moment the error occurred.

Finally we will actually log the message that we have build in the previous step and do the rest of our error handling, like setting the error response to the payload and returning an HTTP 500 code. The entry in the logfile will look something like this

{
  "error": "Unexpected error occurred",
  "message": "Exception(s) were found for route(s): \r\n\t1: 
Response code 500 mapped as failure.\r\n\t4: Response code 500 
mapped as failure.",
  "element": "/logging-scatter-gather-fault-payloads/processors/0 @ 
logging-scatter-gather-fault-payloads:logging-scatter-gather-fault-
payloads.xml:24 (Scatter-Gather)",
  "causedBy": [
    {
      "message": "route number 1 failed to be executed. Failed to 
route event via endpoint: 
org.mule.module.http.internal.request.DefaultHttpRequester@2ae745a0
.",
      "detailMessage": 
"org.mule.module.http.internal.request.ResponseValidatorException: 
Response code 500 mapped as failure.",
      "payload": "An 'unexpected' error occurred!"
    },
    {
      "message": "route number 4 failed to be executed. Failed to 
route event via endpoint: 
org.mule.module.http.internal.request.DefaultHttpRequester@2c10840e
.",
      "detailMessage": 
"org.mule.module.http.internal.request.ResponseValidatorException: 
Response code 500 mapped as failure.",
      "payload": "An 'unexpected' error occurred!"
    }
  ],
  "payload": null
}

Be aware that MuleSoft (Java) starts counting on 0, so in the above example, the second and fifth flow of the Scatter-Gather component (which is specified on line 24 of the flow XML file) have failed. We can verify this behavior if we check the demo implementation of the flow: