Until Successful Scope in Mule

Until Successful Scope in Mule

Here we are using Message Enricher in mule 3 in Anypoint studio 6.2

The until successful scope is one of the scopes available in Mule which processes messages through its processors until the process succeeds. By default, until successful’s processing occurs asynchronously from the main flow. After passing a message into the until successful scope, the main flow immediately regains control of the thread. However, you can configure until successful to run synchronously relative to the main flow.

The until successful component requires a mandatory object store to work. However, Anypoint Studio doesn’t enforce this. If an object store is not declared, Anypoint Studio throws an InitializationException. The object store needs to be exclusive for each Until Successful instance.

Below is the exception which will be thrown if object store is not declared for Until Successful:

org.mule.module.launcher.DeploymentInitException: InitialisationException: A ListableObjectStore must be configured on Until Successful.

By default, the Until Successful scope runs asynchronously, but you can always configure it as synchronous. For example, if the parent flow is calling a child flow in the Until Successful scope, the main flow will not halt for child flow to complete, it will immediately regains control of thread.

IMP Attributes of Until Successful Scope

objectStore-ref: Reference to the org.mule.api.store.ListableObjectStore that is used to store events pending to process or reprocess.

maxRetries: Specifies the maximum number of retries that are attempted.

millis Between Retries: Specifies the minimum interval between two attempts to process, in milliseconds. The actual interval depends on the previous execution, but should not exceed twice this number. The default value is 60000 milliseconds (one minute).

deadLetterQueue-ref: The endpoint or message processor to which undeliverables messages are sent after all retries have been executed unsuccessfully.

When All Else Has Failed

If message processing keeps failing and the maximum number of retries is exceeded, the default behavior of the until successful message processor consists of logging the message details and dropping it.

If we want to perform a specific action on the discarded message (for example, storing it in a file or database), it is possible to configure a "Dead Letter Queue endpoint” where dropped messages are sent.

Until-Successful and Object Store
This message processor needs a ListableObjectStore instance in order to persist messages pending (re)processing. There are several implementations available in Mule, including the following:

DefaultInMemoryObjectStore: default in-memory store.

DefaultPersistentObjectStore: default persistent store.

FileObjectStore: file-based store.

QueuePersistenceObjectStore: global queue store.

SimpleMemoryObjectStore: in-memory store.

Synchronous Until Successful :

Out of the box, the until successful scope processes messages asynchronously. After passing a message into the until successful scope, the main flow immediately regains control of the thread, thus prohibiting any returned response from the processing activities which occur within the scope.

However, in some situations, you may need until successful to process messages synchronously so that the main flow waits for processing within the scope to complete before continuing processing. To address these needs,  Mule enables you to configure the scope to process messages synchronously.

When set to process message synchronously, until successful executes within the thread of the main flow, then returns the result scope’s processing on the same thread.

When set to process synchronously, the until-successful scope does not accept the configuration of the following child element and attributes:

threading-profile (synchronous until-successful does not need a ThreadPool)

objectStore-ref (synchronous until-successful is not required to persist messages between retries)

deadLetterQueue-ref (when the retry count is exhausted, Mule executes the exception strategy)

Here is the flow of Until Successful :

In this flow it retries to retrieve data from table until it retrieved it successfully. I have given 
Max retries : 2 
Milliseconds between retries : 5000

Same MySQL db is used with demodata schema and table name instead of info i have  intentionally made mistake in table name and given as infoo so that scope retries till its max given limit i.e., 2.

DB query :

Until successful settings :

path : /until

url : http://localhost:8085/api/until
method : GET

So after first unsuccessful attempts it retries two times as we have given Max retries : 2 

with the gap of 5000 milliseconds

Postman output :

XML project code :

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

<mule xmlns:db="http://www.mulesoft.org/schema/mule/db" 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"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/db http://www.mulesoft.org/schema/mule/db/current/mule-db.xsd
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd">
    <http:listener-config name="HTTP_Listener_Configuration" host="" port="8085" doc:name="HTTP Listener Configuration" basePath="/api"/>
    <db:mysql-config name="MySQL_Configuration" host="localhost" port="3306" user="root" password="*******" database="demodata" doc:name="MySQL Configuration"/>
    <flow name="test_unsuccessfulFlow">
        <http:listener config-ref="HTTP_Listener_Configuration" path="/until" doc:name="HTTP"/>
        <until-successful maxRetries="2" doc:name="Until Successful" synchronous="true" millisBetweenRetries="5000">
            <db:select config-ref="MySQL_Configuration" doc:name="Database">
                <db:parameterized-query><![CDATA[select * from infoo]]></db:parameterized-query>
        <object-to-string-transformer doc:name="Object to String"/>
        <set-payload value="#[payload]" doc:name="Set Payload"/>