Retrying only in case of connectivity failure

 

We have seen people exploiting until successful scope. People just put everything under until successful scope to retry and that is not the right way.

We should retry only for a particular scenario we have been asked to retry for.

e.g. when calling an API, if you have been asked to retry only in case of connectivity failures, then you should not be retry for 400 bad request, or 500 internal server error or any other.

Here is how you can build your similar logic around it. This is not the only way but one of the ways to handle this complexity.

 

 

  • Wrap the sub flow in try block.
  • Use until successful scope to retry your piece of components. Here we are just dealing with an API call, but you can have a flow reference or any other component.
  • Generate error or success inside until successful scope using the another try catch block.
  • Use on error continue using the namespace you want to retry for.
  • Use the validation/raise error module to raise error for errors other than connectivity failures, since we still need to propagate the errors to parent flow.
  • Save the error object in a variable to refer for error message in parent flow.

Code Snippet of the flow:

</pre>
<?xml version="1.0" encoding="UTF-8"?>

<mule xmlns:validation="http://www.mulesoft.org/schema/mule/validation" xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
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/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
http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd
http://www.mulesoft.org/schema/mule/validation http://www.mulesoft.org/schema/mule/validation/current/mule-validation.xsd">
<http:request-config name="HTTP_Request_configuration" doc:name="HTTP Request configuration" doc:id="bc3b9a39-fa97-40ce-ac4d-9e93f2d13a15" />
<sub-flow name="system-call-mulesy-api-SubFlow" doc:id="e7744997-0a77-4968-9173-0c6e9cd3ae05" >
<try doc:name="Try" doc:id="0134da90-47d1-493e-9313-ba0f59469b85" >
<logger level="INFO" doc:name="Logger" doc:id="b3fbc9fb-e2ac-4496-9d3a-b6e8969b1013" message="request sent" />
<until-successful maxRetries="${request.max.retries}" doc:name="Until Successful" doc:id="8df4cefb-a092-46ee-a8b2-d699c1f1cbe4" millisBetweenRetries="${request.retry.interval.millisec}" >
<try doc:name="Try" doc:id="f6cf85ed-caa4-4238-a59c-255f48a690eb" >
<http:request method="#[vars.http.method]" doc:name="call mulesy api endpoint" doc:id="5f5b4613-89d2-4c09-8b2f-d661c4d051ea" config-ref="HTTP_Request_configuration" path="#[vars.http.path]" sendCorrelationId="ALWAYS" responseTimeout="${http.response.timeout}" >
<http:body ><![CDATA[#[vars.http.request]]]></http:body>
<http:headers ><![CDATA[#[output application/java
---
vars.http.headers]]]></http:headers>
<http:uri-params ><![CDATA[#[output application/java
---
vars.http.uriparameters]]]></http:uri-params>
<http:query-params ><![CDATA[#[output application/java
---
vars.http.queryparameters]]]></http:query-params>
</http:request>
<remove-variable doc:name="Remove Error Variable" doc:id="59ca0501-fa40-416e-a058-091b19889ca8" variableName="error_object" />
<error-handler >
<on-error-continue enableNotifications="true" logException="true" doc:name="On Error Continue for Connectivity Faliures" doc:id="9d816c5a-c190-4c97-8f32-6ad0cfa4849f" when='#[error.errorType.identifier != "CONNECTIVITY"]' >
<logger level="INFO" doc:name="Logger" doc:id="0dec79a4-6864-432a-b6c8-480770569bb3" message="Not retrying since not a connectivity failure with error #[error.description] with correlation id #[correlationId]" />
<ee:transform doc:name="Create Error Variable" doc:id="593a65ac-7f92-4ac4-a87e-95f083e54ff5" >
<ee:message />
<ee:variables >
<ee:set-variable variableName="error_object" ><![CDATA[%dw 2.0
output application/java
---
error]]></ee:set-variable>
</ee:variables>
</ee:transform>
</on-error-continue>
</error-handler>
</try>
</until-successful>
<validation:is-true doc:id="80de8828-ce5d-4b9c-8036-246b304df360" expression="#[vars.error_object == null]" message="#[vars.error_object.detailedDescription]" doc:name="Check for errors other than connectivity errors" />
<logger level="INFO" doc:name="Logger" doc:id="f0ccf1d0-a331-47ee-b39e-38025a5d4215" message="response received" />
<error-handler >
<on-error-propagate enableNotifications="true" logException="true" doc:name="On Error Propagate for other errors" doc:id="a0413010-bf51-4a60-952f-4e3c6af5333e" >
<logger level="ERROR" doc:name="Logger" doc:id="314b3f7a-f816-4423-a5e7-f57b7eeb930a" message="error in flow #[flow.name] with error #[error.description] and response payload #[error.muleMessage.payload] #[vars.error_object.muleMessage.payload] with correlation id #[correlationId]" />
</on-error-propagate>
</error-handler>
</try>
</sub-flow>
</mule>
<pre>

 

 

  
Thank you for taking out time to read the above post. Hope you found it useful. In case of any questions, feel free to comment below. Also, if you are keen on knowing about a specific topic, happy to explore your recommendations as well.
 
For any latest updates or posts on our website, you can follow us on LinkedIn. Look forward to connecting with you there.


Share this:
Subscribe
Notify of
guest
1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Anil
Anil
7 months ago

In case of success, there won’t be an error variable so you’ll end up with warnings There is no variable named ‘error_object’. Check the ‘variableName’ parameter in the ‘remove-variable’ component which could cause performance issues.