Tutorials A to Z » Blog Archives

Tag Archives: Mule 4

Mule 4 Mulesoft Tutorial

Retry Mechanism – Until Success Vs Flow Reference

Published by:

Retry Mechanism – Until Success Vs Flow Reference

In mule 3 we have roll back exception strategy which enable’s the ability to retry the execution in case of error and define a separate flow to be executed once the retry count has exceeded.

In mule 4 you do have re-connection strategy which we can define on the connectors but that only retries in case of failure in connection. In Mule 4 we do not have roll back exception strategy, so in this tutorial we will be looking on how we can implement the same functionality in Mule 4.

To achieve this retry mechanism, we can use Until Successful, but the issue we will face are:

  1. We would not be able to specify any specific condition on which retry should happen . For Example: We will not be able to define retry only when HTTP status code is 202.
  2. We also cannot implement error flow, once an error has occurred. For Example: Every time an error is generated we need to send the error message on to a queue before retrying.

Scenario 1: We want to implement retry mechanism on Web service call, in case of error if HTTP status code is 502 then, API should retry its Web Service Call only 3 times.

To complete the above scenario, we will be using Flow Reference.

Flow Reference in Mule 3 was not able to call its own flow in which it was defined. But in Mule 4 you can call any flow even its own flow.

Flow Diagram:

All we need is to use is flow reference to call its own flow when an error is generated. We have moved HTTP Request to another flow “HTTPFlow” and is referred by flow reference in main flow “get:\users:test-config”.

Inside HTTPFlow we have HTTP Request call on which we have implement retry mechanism. In Error handling part, “On Error Continue” is checking for the retry count if it has reached to its max or not. Inside error flow of “On Error Continue” retry count value is getting incremented and after some seconds of sleep; flow reference will again call HTTPFlow. Once the retry count has reached to its max “On Error Continue” will no longer catch the error and the final error is throw back to its parent flow.

    <flow name="get:\users:test-config">
    <ee:transform xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core" xsi:schemaLocation="http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd" doc:id="86de922d-7d4d-4d0a-b010-e1cf9e23a79d">
            <ee:message>
                <ee:set-payload><![CDATA[%dw 2.0
output application/json
---
{
  userID: [
    "1", 
    "2"
  ],
  userName: "Varun",
  subject: [
    "Maths", 
    "Mule", 
    "TIbco"
  ],
  class: {
    name: "Class 10"
  }
}]]></ee:set-payload>
            </ee:message>
        </ee:transform>
    <logger level="INFO" doc:name="Logger" doc:id="897eb15a-c379-4051-ae78-21ebbbf33cd1" />	
      <set-variable value="1" doc:name="SetRetryCount" doc:id="ae08693c-0c8e-4397-b5e2-235b8b288821" variableName="retryCount" />
    <flow-ref doc:name="HTTPFlow" doc:id="84ab16f4-0fa5-4ac4-a73e-80dd7ab20ea0" name="HTTPFlow"/>
    <logger level="INFO" doc:name="Logger" doc:id="92727a36-d8ed-4ea1-8616-3c0537598400" />
    </flow>
  <flow name="HTTPFlow" doc:id="610bee6d-59f2-4f77-a29e-d60b88aaea01" >
    <logger level="INFO" doc:name="Logger" doc:id="38537854-3f21-48a7-a6a6-31907d8bca90" message="Calling HTTP request count - #[(vars.retryCount default 0)]" />
    <http:request method="GET" doc:name="HTTPCall" doc:id="c766093c-c7ac-444f-914d-cd4d1b70676d" config-ref="HTTP_Request_configuration" path="/abc">
      <reconnect />
    </http:request>
    <error-handler >
      <on-error-continue enableNotifications="true" logException="true" doc:name="On Error Continue" doc:id="8d23329f-b006-4a56-b6a7-6e33eb748957" when="#[(vars.retryCount as Number default 0) &lt; 3 and error.muleMessage.attributes.StatusCode == 503]">
        <logger level="INFO" doc:name="Logger" doc:id="1be75ffe-a4bf-4fe1-9802-ae1309d76341" message="#[error.description]"/>
        <set-variable value="#[(vars.retryCount default 0) +1]" doc:name="Increment retryCount" doc:id="a9877e1d-d1f5-4786-93e9-58126d08f3f4" variableName="retryCount"/>
        <scripting:execute doc:name="Sleep" doc:id="531bc61a-937d-4a0c-81ce-1ea0685ce64f" engine="groovy">
          <scripting:code >def duration = Long.valueOf('3000');
sleep(duration);
return message.payload;</scripting:code>
        </scripting:execute>
        <flow-ref doc:name="HTTPFlow" doc:id="3f37c302-ec9a-4751-ab4e-dcdefb2607f5" name="HTTPFlow"/>
      </on-error-continue>
    </error-handler>
  </flow>

 

Scenario 2: Here we want to implement retry mechanism on Web service call when a specific value is received. Example if a web service call returns a value 5 then retry should happen maximum 3 times else not.

Implementation:

We have moved HTTP Request to sub flow “testSub_Flow” and is referred by flow reference in its parent flow “post:\users:application\json:test-config”.

Inside testSub_Flow  we are using flow reference to call itself. Once we have received the response from web service call “Request“, Choice router we are routeing flow processing based on response received and number of retires number.

 

Mule 4

Inbound Outbound Properties

Published by:

In this “Inbound Outbound Properties” tutorial of Mule 4 we will look on how we can set and modify Mule Inbound and Outbound Properties.

In Mule Inbound properties referees to the additional information that comes to an Mule API along with the message body/payload itself. It may consist of inbound Headers, Query Params, URI Params, HTTP method etc.
In Mule Inbound properties are preset by the sender of the message thus cannot be added or modified.

Mule Outbound Properties are headers and properties that Mule API set before ending its request to other external systems.

Inbound Properties
In Mule 3 we used to access inbound properties by #[message.inboundProperties]

Whereas in Mule 4 we access these properties by #[attributes]

Example
We have create a simple project using RAML.
The GET method of the RAML has URI Param – user_id, which can assess by #[attributes.uriParams['user_id']]

Similarly to access Query Param we do it by #[attributes.queryParams['code']]

To view all the Inbound Properties that are received by a Mule API:

#[attributes]


Output :

 

Outbound Properties
As in Mule 3 we used to set outbound properties via using Set Property Component.
In Mule 4, outbound properties no longer exist. Instead, the headers or properties (e.g. HTTP headers or JMS properties) that you wish to send as part of a request or message (e.g. HTTP request or JMS message) respectively are now configured explicitly as part of the connector operation configuration. 
Example:
To Set the outbound HTTP headers and HTTP status code for a Mule API we need to modify the HTTP Listener Configuration.

SoapUI Output –