Introduction to Processor Level Error Handling in Anypoint Platform(Mule 4) Part-1

Previous part: Introduction to Flow Level Error Handling in Anypoint Platform(Mule 4) Part-5

Handling Errors at Processor Level

For more fine-grain error handling of elements within a flow, processor level error handling is used. A “Try” scope is used for the same. Any number of processors can be added to a Try scope. The Try scope has its own error handling section to which one or more error scopes can be added.

Error handling scenario 7

A calling flow has an on error propagation scope and a Try scope. Try scope also has an on error propagation scope. In try scope, the error occurs at processor labeled as E, and subsequent processors are not executed.

As the flow is executing and the error occurs at the processor E, the error is thrown to the On Error Propagate scope of Try scope. After the last processor from this error scope is executed, the subsequent processors of Try scope are not executed and Mule event is returned to calling flow with error object. Now calling flow also throws error which is handled by its On Error Propagate scope. After the last processor from this error scope is executed, the subsequent processors of calling scope are not executed and error response is returned to the HTTP listener.

Let us see this scenario with a working example

The XML of the above flow is as follows

<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:validation="http://www.mulesoft.org/schema/mule/validation"
xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns="http://www.mulesoft.org/schema/mule/core"
xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/validation http://www.mulesoft.org/schema/mule/validation/current/mule-validation.xsd http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd">
<flow name="scenario-7Flow" doc:id="599ae7d9-76ae-422b-a0a4-d3ba949074cb" >
<http:listener doc:name="Listener" doc:id="d12ca8dd-0209-4616-9391-0c691c6b005b" config-ref="HTTP_Listener_config" path="/base7"/>
<set-payload value='"Max Mule"' doc:name='Payload = "Max Mule"' doc:id="b62a73ef-25e0-474e-a97c-c7a9a5eb8372" />
<try doc:name="Try" doc:id="1b2f69aa-e5b8-4842-b6a0-59749672290e" >
<validation:is-null doc:name="Is null" doc:id="e20315e4-a784-43c2-85b9-6eefac08b849" value='#["Payload is not null"]'/>
<set-payload doc:name='payload = "modified try payload"' doc:id="390a14a4-e735-4863-abc1-9eb5002eac0e" value='"modified try  payload"'/>
<logger level="INFO" doc:name="Logger" doc:id="a7379fe6-7868-4ae7-9910-d02908dd2268" message="#[payload]"/>
<error-handler >
<on-error-propagate enableNotifications="true" logException="true" doc:name="On Error Propagate" doc:id="3c9bab6b-67d7-4cf7-bd68-55b394c4961f" >
<set-payload value="On error propagate - try scope" doc:name='Payload = "On error propagate - try scope"' doc:id="8706db03-03bf-4b19-8d49-1718e55f041f" />
<logger level="INFO" doc:name="Logger" doc:id="d8c34783-8d52-4497-b0bf-1192d231fef8" />
</on-error-propagate>
</error-handler>
</try>
<set-payload doc:name='payload = "modified payload"' doc:id="3110897b-fb01-4740-9134-4971ab9c1a7a" value='"modified payload"'/>
<logger level="INFO" doc:name="Logger" doc:id="5e1048e3-a298-4975-be5f-fbfb912ab626" message="#[payload]"/>
<error-handler >
<on-error-propagate enableNotifications="true" logException="true" doc:name="On Error Propagate" doc:id="938a157e-ee2a-4c9c-ab4d-b8571d0f8f53" >
<set-payload value="On error propagate- parent flow" doc:name='Payload = "On error propagate - parent flow"' doc:id="70efff90-c047-4c9c-bed8-787968a7a3a3" />
<logger level="INFO" doc:name="Logger" doc:id="be3bfb8f-8516-4476-a524-54c11e349d94" />
</on-error-propagate>
</error-handler>
</flow>
</mule>

Debug the application to understand how the error is handled.

Once your application is successfully deployed, Go to Postman or Advance rest-client and send a request to the API. As seen in the exhibit below, the payload is not set yet.

In another step, the payload is set to “Max Mule” and it will be on Try scope. (exhibit below)

When taken another step, it will start executing processors in Try scope. (exhibit below)

In another step, Is null validation component will throw an error. (exhibit below)

This error is now handled by an On Error Propagation scope of the Try scope. (exhibit below)

in another step, the processor inside this error scope will modify the payload (exhibit below)

In the next step, as the Error scope is complete, the remaining processors of the try scope are not executed and the Mule event is returned to the calling flow with an error response. (exhibit below)

Now, as the calling flow has an error, the Mule event is passed to the On Error Propagate scope of the parent flow. (exhibit below)

in another step, the processor inside this error scope will modify the payload (exhibit below)

In the next step, as the Error scope is complete, the remaining processors of the parent flow are not executed and the error response is returned to the HTTP listener which can be seen in the Postman(exhibit below)

Next part: Introduction to Processor Level Error Handling in Anypoint Platform(Mule 4) Part-2

Give claps if you found this article useful. Stay tuned for upcoming articles.

All the images/exhibits are from the author unless given credit

Thanks for reading the article! Wanna connect with me?
Here is a link to my Linkedin Profile

Sanket Kangle - Lead Engineer - Apisero Inc. | LinkedIn