Introduction to Processor Level Error Handling in Anypoint Platform(Mule 4) Part-3
Previous part: Introduction to Processor Level Error Handling in Anypoint Platform(Mule 4) Part-2
Error handling scenario 9
A calling flow has an on error continue or propagate scope and a Try scope. Try scope has an on error continue 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 continue 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 without the error object. Now calling flow does not throw an error hence the subsequent processors of the calling scope are 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.xsdhttp://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd"><flow name="scenario-9Flow" doc:id="7f3836bd-d55b-46b8-9aa8-3a07f86c240c" ><http:listener doc:name="Listener" doc:id="a2a95a16-cb86-4434-a65e-218f8600a468" config-ref="HTTP_Listener_config" path="/base9"/><set-payload value='"Max Mule"' doc:name='Payload = "Max Mule"' doc:id="ae6acbfb-249f-4fa3-b953-0be43576e862" /><try doc:name="Try" doc:id="ebd33df7-8f4b-456c-980f-bcdcc45e0885" ><validation:is-null doc:name="Is null" doc:id="8e0d28d6-8cc8-4737-bc03-1279c14a34e4" value='#["Payload is not null"]'/><set-payload doc:name='payload = "modified try payload"' doc:id="0a385481-681f-4c31-a58e-d042c30010e0" value='"modified try payload"'/><logger level="INFO" doc:name="Logger" doc:id="c1a88c70-25b6-4fa8-87ea-de5560f2968c" message="#[payload]"/><error-handler ><on-error-continue enableNotifications="true" logException="true" doc:name="On Error Continue" doc:id="a05e6bb2-539c-4922-b92a-9bc24412a8f7" ><set-payload value="On error continue - try scope" doc:name='Payload = "On error continue - try scope"' doc:id="226bbba5-3f0e-4287-ae75-9b8d2ceeb7ca" /><logger level="INFO" doc:name="Logger" doc:id="f7cf7561-291b-42a0-a054-3bec8416a803" /></on-error-continue></error-handler></try><set-payload doc:name='payload = "modified payload"' doc:id="95afa96c-1e06-4962-9d81-fa514be657d2" value='"modified payload"'/><logger level="INFO" doc:name="Logger" doc:id="b5d29247-1830-4a6d-bf7d-687d93fbffb7" message="#[payload]"/><error-handler ><on-error-continue enableNotifications="true" logException="true" doc:name="On Error Continue" doc:id="2d4139af-7f1f-4dea-a1f7-0e707a0b6c60" ><set-payload value="On error continue- parent flow" doc:name='Payload = "On error continue - parent flow"' doc:id="862a6dd9-1d22-449c-ba51-ec412198023f" /><logger level="INFO" doc:name="Logger" doc:id="311d3c41-3876-4f65-9806-99e2f0211f5c" /></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 Continue 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 without an error response. As the calling flow does not have an error, the Mule event is passed to the next processors of calling flow. (exhibit below)
in another step, the set payload processor of the calling flow will modify the payload (exhibit below)
In the next step, as the calling flow is complete, the payload is returned to the HTTP listener without any error message which can be seen in the Postman(exhibit below)
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