There was a sudden announcement last week from Microsoft Dynamics 365 Customer Engagement team about an upcoming API Limits. Further details about the changes are available on the Microsoft doc site. Based on the document, the limits will become effective on March 19, 2018. This blog post discusses what the impact might be for you as a customer of the Dynamics 365 platform, and the strategies and options available for you if you are potentially impacted.
To understand what this change means to you, here is my quick summary after reading the document (no warranty whatsoever on the accuracy of interpretation - Microsoft has actually changed the number more than a couple of times after this writing, the numbers below have not been updated, but the math should still work with the latest number, however the new numbers are no longer as generous as they were initially).
- The limit is only about API service calls, typical application usage is not counted towards the limit (however it is worth noting that service calls made in CRM form's JavaScript code are subject to limit).
- The limit is 60,000 service calls within 5 minutes, that basically translates to 200 service calls per second.
- An ExecuteMultiple request is considered one service call. If you use a Batch Size of 200 in our CRM destination component, at the rate of 200 service calls per second, you would be looking at processing 40,000 records per second, that renders to a total of 144,000,000 records per hour which is a lot in my opinion.
- The limit is per connection user.
- This is a very generous limit based on the above math calculation, you will have to be very smart and super creative to actually reach and exceed the limit.
- The only scenario that I can think you might reach the limit is, your business relies on some heavy integration to push a significant number of records using a software like our SSIS Integration Toolkit product.
- If the above applies to you, your integration job might be impacted unless you have a way to throttle the service calls.
- The key is the timing if this could potentially affect you as there is only roughly 3 weeks for you to react (as of today, unless Microsoft later decides to change the date). For enterprise clients, you typically have a change management process in place, which you may not have enough time to push through the changes to your production environment before the effective date (March 19, 2018).
My assessment is, for the majority of Dynamics 365 CE clients, this will not be much of an issue as we do not often see many of our clients processing 200 service calls per second for Dynamics 365 online due to the typical network latency constraints. The clients who might be impacted are those who run their integration on the Azure cloud in which case they might have a very low network latency, and they could push more than 40,000 records per second.
Now let's have a quick look of the options that you might have should you be concerned that you might be impacted, particularly for the users of our integration software or anything in the same nature.
- We are working on a new build which will handle the situation when the limit is reached. This build should be ready in a week or two (most likely in a pre-release format first), and we will try to handle the situation gracefully so you don't need to do anything with your ETL process (Update Oct 3, 2019, please make sure that you are using our latest release, or at least v11.1 or above in which we handle the situation gracefully - there were actually a couple of server-side behavior changes made by Microsoft between this writing and Oct 3, 2019, for this reason, we ask our clients to stay current in order to work with the situation in a robust way).
- If you can't wait for the new build, you may consider the following strategies which you can implement right away
- Consider reducing the number of concurrent threads in CRM destination component.
- To compensate the performance loss of action #1, you can increase your batch size in the destination component. However we don't typically recommend using an aggressive Batch Size, as doing so can easily cause service timeout errors (you may consider increasing your connection manager's Timeout setting to accommodate the extra time needed for the service calls though).
- If you are still concerned that you may not get the optimal performance due to the limitation, you may consider creating additional connection managers that use different connection user accounts, as the limit is per connection user. Doing so, you will have to use multiple destination components in combination with SSIS BDD component to distribute the load evenly. It is a bit overkill in my opinion though.
In addition to my above assessment, I also recommend you check out the blog post written by a fellow MVP Gustaf Westerlund, he has done a great job in highlighting some of the potential impacts, and his discussion around marketing automation is actually very interesting.
I hope this is helpful.