web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

Season of Giving Solutions is Here!
News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Blogs / Jesús Almaraz blog / Microservices patterns: Ret...

Microservices patterns: Retry and Circuit breaker (Webhooks part 2).

Views (962)
Jalmaraz Profile Picture Jalmaraz 669

Recap

This post is the follow-up to earlier post https://community.dynamics.com/nav/b/conceptsindailynavisionwork/archive/2018/06/24/webhooks. In this previous post we have seen how to create a homemade webhook system based in existing Navision webhooks code. We have cloned and modified “PostHttpRequest” function from 1545 “Workflow Webhook Notification” Codeunit.
A little reminder, Webhook is the conjunction of:
  • Raise an event.
  • Call to an API service when event happens.
  • Let users customize the API URL of the callback.

Why NAV uses Retry and Circuit breaker patterns?

My cloned code was very basic for didactical purposes. But this is not real: is more much complex to do a callback system. Connections and APIs could be down, and many other things could be wrong. If we haven´t a good error management, could be very hard to support these systems.

There are a lot of features in the original 1545 Codeunit:
  • Retry.
  • Circuit breaker.
  • Webhook call result log.
These practices should be adopted as patterns every time we call to third-party APIs. In fact, NAV in this Codeunit implements two existing patterns: Retry and Circuit breaker.

Retry and circuit breaker.

We must be fault resilient, enabling to do several retries. The call must be executed by a recurring function that call itself if something is wrong.
But only a limited number of attempts. This number of attempts is stored in “RetryCounter” variable.
Webhook6A.png
If Function “OnPostNotificationRequest” call is not OK, this code retry again with a recursive call to itself at the end of the function:
Webhook6.png

This code is very interesting, because here NAV apply two very important Micro-services patterns: Retry and Circuit Breaker.

Implement of retry pattern is as we have seen, if call fail, invoke itself in recursive way a limited number of retries

Circuit break means examining the error in a retry system: if error is critical, break the retry circuit, save an error log and exit with no more retries.

This happens in function “ShouldRetry”:

Webhook7.png
In errors 404 (“Not found”) or 400 (”Bad request”), we stop doing retries, because keep on calling is a waste of time and machine, because we know the server will not respond for a while.

Call API with “Try” functions.

When we call external APIs, some things can be wrong and we always must have a plan B. Using “Try” functions, error could be cough this way and don´t stop execution:
Webhook8.png

Call result log.

A very important concept in systems integration: make a call log. You must save the result in a table with the last status call. No matter call works fine or not, always is good to save API call result.
Webhook9.png
You can see all code above (without comment lines), in standard Codeunit 1545 “Workflow Webhook Notification”.

Conclusions.

In real Codeunit 1545 we see many patterns NAV uses to make calls safer:
  • Retry.
  • Circuit break.
These are existing Micro-services patterns as we can see here: https://en.wikipedia.org/wiki/Circuit_breaker_design_pattern.
 

Comments

*This post is locked for comments