- 22-12-2021
- Coforge-Salesforce BU
- Anypoint Platform Mulesoft Mule 4
-
Share
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 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
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.
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).
Alternate option to define the Circuit Breaker as 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.
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 Salesforce@coforge.com.
Other useful links:
API Recipes with MuleSoft Anypoint Platform – Mule 4 edition