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

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

Error handling scenario 6

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. Child flow has an on error continue scope and calling flow has an on error continue or propagate scope(both will work in the same manner)present in them.

When an error happens at processor E, the Event is passed to the on error continue scope of child flow. After the scope is executed, the error is not rethrown in the calling flow without executing further processors further processors of the calling scope are not suspended as the error response is not returned by child flow. A success message with payload is returned to the HTTP listener once calling flow execution ends.

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-6" doc:id="23ca57a5-ca7b-4f17-a9bd-55f0c860044e" >
<http:listener doc:name="Listener" doc:id="50eb4913-7403-4cc5-a88d-7af471acb566" config-ref="HTTP_Listener_config" path="/base6"/>
<set-payload value='"Max Mule"' doc:name='Payload = "Max Mule"' doc:id="83b78174-774a-4907-8c78-8103c94df208" />
<flow-ref doc:name="Flow Reference" doc:id="ce4b120c-f1e2-4d7b-87d1-f63275cbf196" name="child-flow-6"/>
<set-payload doc:name='payload = "modified payload"' doc:id="413ecbe6-7f6c-45b7-afe2-ecf79ff6c02e" value='"modified payload"'/>
<logger level="INFO" doc:name="Logger" doc:id="a3c020c6-f434-477c-b091-36edf184474a" message="#[payload]"/>
<error-handler >
<on-error-propagate enableNotifications="true" logException="true" doc:name="On Error Propagate" doc:id="64c7beb9-0169-4b09-80bc-ddb60b80e8c3" >
<set-payload value="On error propagate- parent flow" doc:name='Payload = "On error propagate - parent flow"' doc:id="0d21aea0-4061-46db-bf6e-0ae01e14fecf" />
<logger level="INFO" doc:name="Logger" doc:id="ba73f7ca-9712-48d5-82bf-afde05b056b4" />
</on-error-propagate>
</error-handler>
</flow>
<flow name="child-flow-6" doc:id="4401255c-a29d-46c0-97a4-ebc4466e0701" >
<validation:is-null doc:name="Is null" doc:id="df5f8cd6-a2b5-4339-92ca-2766df491f6f" value='#["Payload is not null"]'/>
<set-payload doc:name='payload = "modified child payload"' doc:id="039ee0e7-0815-4344-8a8a-cb1a950f0ca7" value='"modified child  payload"'/>
<logger level="INFO" doc:name="Logger" doc:id="a4fc6672-0b37-42cf-b01e-3f2e2a38e4f1" message="#[payload]"/>
<error-handler >
<on-error-continue enableNotifications="true" logException="true" doc:name="On Error Continue" doc:id="2aa82186-d532-41e0-b847-d3f4c6c4db13" >
<set-payload value="On error continue- child flow" doc:name='Payload = "On error continue- child flow"' doc:id="b9ad879f-0060-4f7e-ae7c-b953def399e3" />
<logger level="INFO" doc:name="Logger" doc:id="871f55a0-134b-40ca-a988-39f3763696f6" />
</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.

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 without the error object. (exhibit below)

Now, as there is NO error in the calling flow, the Mule event is not passed to the flow level error handler of the calling flow. hence it doesn’t matter if it is on error continue or on error propagation scope, the parent flow will execute fully and a success message is returned with payload to HTTP Listener.(exhibit below)

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

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