Introduction to Flow Level Error Handling in Anypoint Platform(Mule 4) Part-3

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

Error handling scenario 4

In this scenario, we will examine the effects of an error occurring in the child flow. the source flow will call the child flow and passes the Mule event to it. An error occurs in the event processor labeled E and subsequent processors are not executed. The error is rethrown and the subsequent processors in calling flow also are not executed.

The source flow and child flow, both have flow level error handlers with an on error propagate scope. When the error occurs at processor E, the Mule event is directed towards the first processor in on error propagate scope of child flow. After scope execution is completed, the error is rethrown to calling flow. In calling flow, again it is handled by the on error propagate scope and finally, the 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="parent-flow" doc:id="dc0ffe8d-8805-41d0-b6e3-dc974f308ee6" >
<http:listener doc:name="Listener" doc:id="1d18a766-77a7-4d0e-a914-17aa06145e14" config-ref="HTTP_Listener_config" path="/base4"/>
<set-payload value='"Max Mule"' doc:name='Payload = "Max Mule"' doc:id="798a5c23-9025-4c32-97bc-067971746a1b" />
<flow-ref doc:name="Flow Reference" doc:id="af31cf79-56dc-42ca-9fd8-faf2495af04a" name="child-flow"/>
<set-payload doc:name='payload = "modified payload"' doc:id="571982af-f038-4ffa-b046-c93d3d22f049" value='"modified payload"'/>
<logger level="INFO" doc:name="Logger" doc:id="98865610-e775-4f22-b5bb-1b90da435bae" message="#[payload]"/>
<error-handler >
<on-error-propagate enableNotifications="true" logException="true" doc:name="On Error Propagate" doc:id="43e77e01-0e81-4f4a-8972-5aafd6714ac0" >
<set-payload value="On error propagate- parent flow" doc:name='Payload = "On error propagate - parent flow"' doc:id="78039a8d-842f-4349-b3fa-8e7b787780ec" />
<logger level="INFO" doc:name="Logger" doc:id="92114eaf-0a1e-4e30-8eb3-417652cfd20d" />
</on-error-propagate>
</error-handler>
</flow>
<flow name="child-flow" doc:id="ede71256-b462-43de-b6fc-79409dae58bf" >
<validation:is-null doc:name="Is null" doc:id="57a109ce-82f6-4c3d-b141-1a9044eb144a" value='#["Payload is not null"]'/>
<set-payload doc:name='payload = "modified child payload"' doc:id="1edbb2f7-a9b7-4e5b-a2ec-50040e4fc9c5" value='"modified child  payload"'/>
<logger level="INFO" doc:name="Logger" doc:id="07119fad-2f0a-4d63-a2c4-bc6139730b0c" message="#[payload]"/>
<error-handler >
<on-error-propagate enableNotifications="true" logException="true" doc:name="On Error Propagate" doc:id="ebfd6863-d3ef-45c0-82ea-6863030f3aa4" >
<set-payload value="On error propagate- child flow" doc:name='Payload = "On error propagate- child flow"' doc:id="2d51cd6d-60ad-40ca-9c13-59e03a204a7c" />
<logger level="INFO" doc:name="Logger" doc:id="554f13bc-6972-4c3b-9075-1e4c0250ed35" />
</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.

Moving one step forward, the payload is set to “Max Mule” (exhibit below)

With another step, the flow reference will pass the Mule event to the child flow. (exhibit below)

When another step is taken, the error is thrown by the “is null” validation processor(exhibit below)

with the next step, the Mule event is passed is flow level error handler(exhibit below)

The payload is modified by the processor in on error propagate scope with the next step.(exhibit below)

When we come out of the error scope, the remaining flow is suspended and the Mule event is returned to the calling flow with the error object. (exhibit below)

Now, as there is an error in the calling flow, the Mule event is passed to the flow level error handler of the calling flow. (exhibit below)

The payload is modified by the processor in on error propagate scope with the next step.(exhibit below)

With the next step, the payload is logged, remaining processors of the flow are suspended and an error response is sent back to HTTP listener, which can be seen in the response of the Postman.

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

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