As most of you know, yesterday the Microsoft Azure platform and several of its services/resource types like VSTS and Dynamics 365 were affected by outages and connectivity issues.
I have been affected by this since I was performing regression and penetation tests on a Azure-hosted integration system to a Dynamics 365 system which had its go-live last week. The aforementioned outages manifested as miscellanous network connectivity issues/timeouts and several CRM organization services not responding.
However, one effect caught my attention:
In our custom developed CRM/ERP integration system we make heavy use of ExecuteMultipleRequests and thus, of course, know all restrictions, particularities and limitations inside out. Especially regarding the maximum batch size (ImportSetting.BatchSize), I thought to be aware of. To be more precise, CRM Online by default has a fixed limit of 1000 Organization Requests that may be — simply said — “bundled” into a single ExecuteMultipleRequest and then are executed together in a single physical request to the CRM organization.
Yesterday however, I noticed that many ExecuteMultipleRequests suddenly began to raise service faults saying that the maximum batch size is exceeded which turned on the alert lamps in my mind. Since I conducted the tests and the used fixtures/data by myself and thus know them, and the fact that we used a maximum of 999 requests per ExecuteMultipleRequest, I could surely exclude the reason for these faults to be on our side.
This leads me to the conclusion, the Microsoft could automatically decrease the maximum batch size limit in Dynamics 365 Online organizations in situations where they need to reduce pressure/resource consumption in their cloud landscape. I did not find similar reports on the interweb yet, but will keep this in my backhead for clarification at given time.
Did you encounter a similar behaviour?
Solution
As a solution I wrote a simple proof-of-concept for a mechanism that “intelligently” lowers the number of organization requests put into a single ExecuteMultipleRequest when it attempts a service fault related to MatchBatchSize transgressions. Funny detail: It needs no privileged user account for retrieving a deployment setting but instead uses the “MaxBatchSize” value contained in the service fault detail data object.