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

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

Error handling scenario 8

A calling flow has an on error continue scope and a Try scope. Try scope has an on error propagate 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 the Mule event is returned to calling flow with the error object. Now calling flow also throws an error which is handled by its On Error Continue scope. After the last processor from this error scope is executed, the subsequent processors of the calling scope are not executed and a success message is returned with payload 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-8Flow" doc:id="f40036b3-ad8e-48aa-8183-b8450bb96c2e" >
<http:listener doc:name="Listener" doc:id="43556d95-0eb4-4dcc-99ce-3bdf977b79d6" config-ref="HTTP_Listener_config" path="/base8"/>
<set-payload value='"Max Mule"' doc:name='Payload = "Max Mule"' doc:id="bcb2e637-3698-41e7-bebf-fe6411abd2bf" />
<try doc:name="Try" doc:id="f8961907-593f-4d19-b780-3fd4615ab079" >
<validation:is-null doc:name="Is null" doc:id="4db01652-585c-448e-b120-cc251454fa1c" value='#["Payload is not null"]'/>
<set-payload doc:name='payload = "modified try payload"' doc:id="a7a8bae6-d8e8-4ae4-826e-58ef69809408" value='"modified try  payload"'/>
<logger level="INFO" doc:name="Logger" doc:id="d5e842bb-b921-471f-afc2-a122cdb1f811" message="#[payload]"/>
<error-handler >
<on-error-propagate enableNotifications="true" logException="true" doc:name="On Error Propagate" doc:id="03cc7adf-da74-4c99-8cd3-e2aa3a91d23d" >
<set-payload value="On error propagate - try scope" doc:name='Payload = "On error propagate - try scope"' doc:id="d2414cd7-9174-441e-951b-e6d683037271" />
<logger level="INFO" doc:name="Logger" doc:id="e0aac8a0-4d30-4e5c-8f0f-6e23c502e6e2" />
</on-error-propagate>
</error-handler>
</try>
<set-payload doc:name='payload = "modified payload"' doc:id="cce40f34-2b3c-4783-8c53-b71d55410a66" value='"modified payload"'/>
<logger level="INFO" doc:name="Logger" doc:id="b914dddc-13c6-442b-bb1d-b9bd92926d11" message="#[payload]"/>
<error-handler >
<on-error-continue enableNotifications="true" logException="true" doc:name="On Error Continue" doc:id="59f4ae8f-1512-44a4-be0a-e577080503f9" >
<set-payload value="On error continue- parent flow" doc:name='Payload = "On error continue - parent flow"' doc:id="bfc5bc83-2acf-41d2-a4df-959fcd93fcdd" />
<logger level="INFO" doc:name="Logger" doc:id="b0ae6b84-0e69-4e40-a2df-dae9d64a7326" />
</on-error-continue>
</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 Continue 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 payload is returned to the HTTP listener without any error message which can be seen in the Postman(exhibit below)

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

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