Processor Level Error Handling with hands-on using Anypoint Studio(Mule 4) — Part 2
Author: Sanket Kangle
Click here for the link to part one of the article.
Error handling scenario 2
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 the 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)
Error handling scenario 3
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 the 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.xsd
http://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 the 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)
