Circuit Breaker for Anypoint MQ

  • Written By Arpit Mehrotra
  • 23/12/2021

Circuit Breaker is a design pattern used in software development. It is used to detect failures and encapsulates the logic of preventing a failure from constantly recurring, when the external service is not available or external system is down for maintenance. It also uses a retry pattern to retry the message at defined interval to process the message successfully.

In this blog we demonstrate how we can implement the Circuit Breaker for Anypoint MQ.

Circuit Breaker pattern

The basic idea behind the Circuit Breaker is very simple. You wrap a protected function call in a Circuit Breaker object, which monitors for failures. Once the failures reach a certain threshold, the circuit breaker trips, and all further calls to the Circuit Breaker return with an error, without the protected call being made at all.

Circuit Breaker - Anypoint MQ

Circuit Breaker States

Open: The Subscriber source doesn’t attempt to retrieve messages and skips the message silently until the configured trip timeout occurred.

Closed: The starting state where the Subscriber source retrieves messages normally from MQ based on its configuration

Half Open: After trip timeout elapses, the Subscriber source goes to a Half-Open state. In the next poll for messages, the Subscriber source retrieves a single message from the service and uses that message to check if the system has recovered before going back to the normal Closed state.

To demonstrate the Circuit Breaker we will create a new Mule application and subscribe the message from a queue and make a call to the rest endpoint, the objective of the Circuit Breaker is when the rest API is not available for a longer duration Anypoint subscriber will stop consuming the message from Anypoint message queue for a particular time and give time to external service to become available again.

How it works in MuleSoft

The Circuit Breaker capability is bound to the error handling mechanism provided by Mule. You can bind any error to a circuit failure. For example, you can bind HTTP:TIMEOUT, MULE:RETRY_EXHAUSTED, or even a custom error from your app, such as APP:CUSTOM_ERROR

If a Mule flow finishes its execution with an error, the Subscriber checks if the error is for the defined ErrorTypes then it counts consecutive occurrences for that error until errorsThreshold is reached. When errorsThreshold is reached, the circuit trips and stops polling for new messages the duration specified by tripTimeout

Step 1: To test this scenario first we will create a MQ if not exist in Anypoint platform

Step 2: Create a new mule application and drag and drop Anypoint MQ subscriber operation

Step 3: Create configuration for Anypoint MQ, provide the URL, and client id and client_secret to connect with Anypoint MQ

How to configure Circuit Breaker

Go to Global Elements-> Create->Component configuration->click on Circuit Breaker

Global type

Provide the below parameters

On Error Type: Error type which will decide the Circuit Breaker to trip, it can be any error you can provide multiple error type as comma-separated values.

Error Threshold: This is the threshold(no of consecutive error) after which the circuit will open

Trip timeout: This time decide for how long the circuit will keep open

Trip timeout Unit: Unit for trip timeout

Configure the connector to poll the message from the Anypoint MQ.

circuit breaker poc

Configure the Circuit Breaker created globally (you can also create a Circuit Breaker configuration inline with the MQ subscriber as shown in option 2, but it is recommended to create globally so that you can use this with other subscribers).

circuit breaker poc2

Alternate option to define the Circuit Breaker as inline

edit circuit breaker inline

Configure the circuit breaker created globally. You can also create a circuit breaker configuration inline with the MQ subscriber as shown in option-2, but it is recommended to create globally so that you can use this with other subscribers.

HTTP requester

Deploy the application on local and send the message from MQ and check the logs.

We  will see after 3 consecutive errors that the circuit is trip off (open) for 5 minutes and after 5 minutes the circuit will half close/open  to check if the API is available or not. If the API is available it will close again to consume all the message, else it will be kept open and wait for the complete recovery.

If you would like to find out more about how you can enhance API reuse and speed up operations, we can help. Give us a call or email us at marketing@whishworks.com.

Other useful links:

API Recipes with MuleSoft Anypoint Platform – Mule 4 edition

Get started with MuleSoft and API-led connectivity

Salesforce CDC integration using MuleSoft

Latest Insights

Application Integration
Blogs

What is Application Integration?

Application integration helps close the gap between existing on-site systems and the ever-evolving cloud-based enterprise applications.

Coforge Salesforce High Velocity Sales
Blogs

Enabling sales with Salesforce High Velocity Sales

What exactly High Velocity Sales is, how it can benefit your business and how to enable it.

CRISP-DM : ANALYTICAL FRAMEWORK
Blogs

Using the CRISP-DM framework for data driven projects

Learn how CRISP-DM can facilitate the planning, organising, and implementing process of data-driven projects.