We’re finally getting a throttling functionality for OData integrations!
It’s one of the most common requirements from a customer: the need to integrate Dynamics 365 with other systems. With the (back in the day) new AX7 we got a new way of integrating using the OData REST endpoint and the exposed Data Entities.
But integrations using the OData endpoints have low performance and for high-volume integrations, it’s better to use the Data management package REST API. A (not so) high volume usage of the OData REST API will translate into performance issues.
The throttling functionality is in preview starting version 10.0.13 which is currently in PEAP. It will be enforced starting April 2021. You can join the Data Management, Data Entities, OData, and Integrations Yammer group for more info. Remember you need to join the Insider Program for Dynamics 365 first to be able to access the Yammer group.
If you want to learn more about OData and throttling you can check these resources:
- Priority-based throttling.
- Tech talk: Throttling Overview for Fin/Ops Integrations. You can skip reading this post and watch this session that has all the details and even more.
- Consume REST Services and OData in #MSDyn365FO from Postman (in Spanish) & Part 2 at jatomas.com.
Throttling
Why are we getting this functionality? Throttling is a well-known way of controlling the execution of some processes, and it’s present in almost all of the REST API out there. But it wasn’t for us.
The problem with OData is that when you make more calls than the endpoints can process, the system performance will be impacted because the resources that run the OData endpoints and the rest of the system are shared. And this is true for interactive sessions (real people using MSDyn365FO) and non-interactive sessions.
And here’s where throttling will help! With throttling, we’ll be able to set priorities for different integrations to keep the responsiveness of the system.
Configure priorities
To configure the priorities we need to go to System administration – Setup – Throttling priority mapping where we’ll see this:
If we open the Authentication type field we see there are 2 different types: AAD application and User. The AAD type will apply to integrations that access FnO using the AAD client Id + secret (OData, custom web services), and the User type applies only to specific users. For example, if some user needs to periodically import data using the Excel add-in we can set a high priority for that single user. For example:
In the image above we can see there’s an AAD integration with Low priority and two Users with Medium and High priority. If the system gets to the limit where it needs to throttle integrations the user JULIA will have the highest priority to keep using OData, then the user JOHN and finally the AAD integration.
This means that the AAD integration will be throttled first, then JOHN, and finally JULIA because she’s responsible for some business-critical processes.
Throttled requests
Until now we had no way of notifying the integration that the request was being throttled. I don’t remember but you’d get a timeout or an error 503, no more details. With this new feature we can answer a throttled request with an error code 429 Too Many Requests:
if (!response.IsSuccessStatusCode)
{
if ((int)response.StatusCode == 429)
{
int seconds = 30;
//Try to use the Retry-After header value if it is returned.
if (response.Headers.Contains("Retry-After"))
{
seconds = int.Parse(response.Headers.GetValues("Retry-After").FirstOrDefault());
}
Thread.Sleep(TimeSpan.FromSeconds(seconds));
// Retry sending the request.
}
}This will finally shed some light on the errors and we’ll be able to tell the other side to try again after some time. And instead of just trying again, and again, and again, because we got no specific error, and make the problem a bigger one by sending more requests, we can change the logic of the integration and retry in X seconds/minutes.
Monitoring throttling in LCS
Remember you can monitor throttling from the LCS environment page:
What is throttling not?
Please, let me steal one of the slides of the tech talk because we need to remember something:
I want to stress the second point: Throttling is not a solution to bad entity design, code… Throttling is a tool to prevent an issue and notify integrations that the requests are being throttled, but it won’t fix performance issues born in the design or code phases.
As I said at the beginning of the post if you still haven’t go and watch the Throttling Overview for Fin/Ops Integrations.
