Does Integration Hub Integratiuons support Retry and Circuit Breaker functions?

[ArturoLeyva]

A customer of us is asking this very detailed question where they are willing to know if an integration using a custom-made spoke (REST API) supports the following integration Patterns:

Circuit Breaker Pattern Context:

Services sometimes collaborate when handling requests. When one service synchronously invokes another, there is always the possibility that the other service will be unavailable or exhibit such high latency that it is essentially unusable. The calling Client can consume valuable resources, such as many threads, while waiting for the other Service to respond. This could lead to resource exhaustion, rendering the called Service unable to handle other requests. Failure of one service can affect other services throughout the application.

Problem

How to prevent cascading failures due to failures of the NETWORK or the called Service?

Solution

The Client Service must invoke a remote Service through a proxy that works in a manner similar to an electrical circuit. When a consecutive number of failures crosses the established limit, the Circuit Breaker is triggered, and while the timeout established in the mechanism is in effect, all calls to this Service will fail or will be answered with an error immediately. After the established timeout concludes, the Circuit Breaker allows a limited number of calls that serve to perform tests with the target Service. If these requests work correctly, the Circuit Breaker returns to its initial state and the operation returns to its initial state (correct operation). Otherwise, the timeout in which the response with a failure is immediately restarted. Value obtained with the use of the Pattern Services has the ability to handle the failures of other services that they invoke and avoid a chain reaction that may affect several services in the chain or others indirectly in the event of a server crash due to insufficient resources.

Retry Pattern Context:

Services collaborate when handling a Client's request. When a service invokes another, a failure may occur, which may be transient. Transient failures may be due to a momentary loss of network connectivity to components or other services, timeouts with third-party services when a service is busy, etc... These failures are typically self-correcting or disappear in a moment. If the action or request that generated the failure is resent after waiting a moment, it will be processed successfully.

Problem

How do we tolerate the transient failure of an invoked service?

Solution

If the client of a service detects a failure when trying to send a request to the remote service, it must handle the failure using the following strategies:

• Cancel: If the failure indicates that it is not transient or that success cannot be achieved if it is repeated, the client must cancel the sending and report an exception.
• Retry: If the specific failure reported is unusual or strange, such as due to unusual circumstances such as network interruptions, the application may immediately retry, and it will probably be attended to.
• Retry after a wait: If the failure is caused by connection problems or failures because the service is busy (timeout), the client must wait a moment and try again until a certain number of attempts are met or the request is processed; otherwise, it must be canceled.

Is this supported?

[Shreya Shah]

Have you tried looking at creating custom retry policy using Retry Policy framework? It can be plugged into any action by enabling the retry policy checkbox and selecting the required retry policy for the action.

Each retry policy has a set of conditions on which they are triggered and retry strategy is selectable, to retry after fixed internal, exponential back-off, or retry-headers. 

[BillMartin]

Hi @ArturoLeyva ,

I have created this article that shows how to implement circuit breaker pattern in ServiceNow.

Why Your ServiceNow REST API Integration Will Fail Without a Circuit Breaker Pattern

[BillMartin]

another approach @ArturoLeyva  is to use Event Driven Architecture utilizing ServiceNow out of the box Queueing Servers.

Mastering Queueing Techniques for Architects that Support Asynchronous Calls in ServiceNow