Author: Sanket Kangle

Click here for link to part one of the article.

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. Child flow has an on error propagate scope, and calling flow has an on error continue scope present in them.

When an error happens at processor E, the Event is passed to the on error propagate scope of child flow. After the scope is executed, the error is rethrown in the calling flow without executing further processors in the calling flow and handled by calling flow’s On error continue scope. Further processors of the calling scope are suspended, and a success message with payload 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-5″ doc:id=”addb5e0f-2f13-4e1b-9f4c-870b15e8061c” >
<http:listener doc:name=”Listener” doc:id=”f5a4a09d-7fd6-4ee1-8155-fe19a5f30c52″ config-ref=”HTTP_Listener_config” path=”/base5″/>
<set-payload value='”Max Mule”‘ doc:name=’Payload = “Max Mule”‘ doc:id=”1b890bf5-a9ae-4ece-8e77-5a2300f7702c” />
<flow-ref doc:name=”Flow Reference” doc:id=”91f4e45b-0fde-44dc-bf21-97ff39e06dd3″ name=”child-flow-5″/>
<set-payload doc:name=’payload = “modified payload”‘ doc:id=”57e57c9a-f6c7-4993-922d-b0a44e70c961” value='”modified payload”‘/>
<logger level=”INFO” doc:name=”Logger” doc:id=”83e14210-3988-4697-a63c-9a6064ea4c16″ message=”#[payload]”/>
<error-handler >
<on-error-continue enableNotifications=”true” logException=”true” doc:name=”On Error Continue” doc:id=”aef610fb-7c4e-4b38-aba9-b5662934210c” >
<set-payload value=”On error continue- parent flow” doc:name=’Payload = “On error continue- parent flow”‘ doc:id=”50754cd0-e438-46cf-b5a9-5c0f65e8df4f” />
<logger level=”INFO” doc:name=”Logger” doc:id=”c3f8544f-15e9-453c-9fa6-376a190c3543″ />
</on-error-continue>

</error-handler>

</flow>
<flow name=”child-flow-5″ doc:id=”b786fb0a-2f2f-4ee2-b358-63335e16e668″ >
<validation:is-null doc:name=”Is null” doc:id=”aec3610a-5579-4437-aa15-20bf4fcacdd3″ value=’#[“Payload is not null”]’/>
<set-payload doc:name=’payload = “modified child payload”‘ doc:id=”a6c33f04-9999-4123-8c46-a567b092d45c” value='”modified child  payload”‘/>
<logger level=”INFO” doc:name=”Logger” doc:id=”22bf7109-1a13-4cdf-bc93-ca202a851cb9″ message=”#[payload]”/>
<error-handler >
<on-error-propagate enableNotifications=”true” logException=”true” doc:name=”On Error Propagate” doc:id=”11ace283-76e1-4033-bab9-8215b5680292″ >
<set-payload value=”On error propagate- child flow” doc:name=’Payload = “On error propagate- child flow”‘ doc:id=”e080a407-4ea4-425d-a924-03ce4f7b8ae7” />
<logger level=”INFO” doc:name=”Logger” doc:id=”307f19dc-c305-45bc-8233-75e1330f9502″ />
</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)

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 continue scope with the next step. (exhibit below)

With the next step, the payload is logged, remaining processors of the flow are suspended, and a “success” response with payload is sent back to the HTTP listener, which can be seen in the Postman’s response.

Error handling scenario 5

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 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)

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)

Leave a Comment