User Profile
Bill_Ayers1
MVP
Joined 10 years ago
User Widgets
Recent Discussions
Microsoft Graph - Don't Get Throttled!
The Microsoft Graph endpoint is normally highly performant. The infrastructure behind Microsoft 365 will allocate computing resources based on demand to ensure that periods of high traffic levels do not result in degraded performance. In addition to dynamic scaling of resources, another mechanism that Microsoft uses is throttling. If you make too many requests then you will start to get HTTP 429 (too many requests) response codes returned. Not all resources are metered and while this initially applied just to the Outlook APIs but we can assume that more resources will be metered over time. How many requests is "too many"? So the obvious question is: what is the definition of "too many requests?". The answer to this is that you will get throttled if you make a number of requests that would be detrimental to the service as a whole, which isn't actually that helpful. A figure that has been stated publicly is 10,000 requests in a 10-minute period. This applies on a per user and per application ID basis. So you could make 10,000 requests on behalf of each user or group in your tenant in a 10-minute period before triggering the throttle, and if you exceed the threshold for a particular user then it is only that user that gets throttled. If you are using app-only permissions then that counts as a single user. This is all well and good, but for practical purposes you have to accept that these rules could change at any time, and in addition you could well find that a lower threshold kicks in if the service is becoming overloaded for whatever reason. You might also find you get throttled if you make a large number of requests across your tenant, the 'rules' above notwithstanding. The reality is that unless you are making a small number of requests, you should design your application on the assumption that you could get a 429 response at any time and build in logic to deal gracefully with that situation when it arises. If your application is throttled you will get a Retry-After response header in addition to the 429 response code, telling you the number of seconds your application needs to wait before making more requests. You also get a descriptive Rate-Limit-Reason header (I hesitate to call it an error message) which you probably will want to log rather than show to a user. Obviously you will want your app to wait for the Retry-After period before making another request, otherwise you will just get more 429s and probably extend the throttling period even further. Avoiding Throttling Clearly it is preferable not to be throttled in order to keep your application performant. There are a number of strategies you can use: Don't do automatic retries as these will accumulate requests against any throttling limit. Retrieve multiple items in one request, e.g. get a page of list items rather than retrieving individually, and use $select to avoid getting properties you don't need to keep the payload down. Increase the value of $top to get larger pages (default is 10 but maximum is 1000) Cache data locally where needed to avoid re-fetching data, while being careful not to breach data privacy, retention policies and terms of use of the Microsoft Graph Use webhook notifications rather than polling requests to detect changes (you can also use delta queries to reduce the response payload). Use JSON batching to combine multiple requests into a single batch request. You should think of the Retry-After period as a recommendation. If you re-try the request after the Retry-After time has elapsed it is still possible that you will get a 429 response. This means that throttling is still in effect. In this case you should again wait for the (possibly updated) Retry-After period and try again, repeating this process until the request succeeds. It is worth noting that not all of the Microsoft Graph APIs provide a Retry-After header. It is possible for an API to have throttling implemented but not yet support the Retry-After header. In this case a strategy would be to have an initial wait period and keep increasing it exponentially with each 429 response. More guidance is provided in the Microsoft Graph documentation. Microsoft Graph Data Connect The Microsoft Graph API is designed for transactional access to Microsoft 365 data on a user-by-user basis. Some applications really require bulk access to data, for example aggregation of data across a tenant, fraud detection, analysing resource utilization and efficiency or building organizational directories, to name a few use cases. Typically these types of processing occur on a scheduled basis, for example every night. In this case the Microsoft Graph API endpoint is a very inefficient way of doing this and the application is likely to encounter throttling limits. A better solution in this case is to use a new feature (currently in preview at the time of writing) called Microsoft Graph Data Connect. It allows you to get at the same data that's available through Microsoft Graph APIs (currently only a limited subset is available), but in a scalable way. It also allows you to build sophisticated analysis pipelines using tools like Azure Data Factory. All this processing occurs within the Azure data centre for better data protection. For more information see the Microsoft Graph Data Connect documentation. More articles on my blog.Re: Feedback & Feature Issues
Ah, yes. I'm still using wpdev.uservoice.com but they retired the non-developer windows.uservoice.com to the Windows Feedback Hub app. I agree, there should be a redirect from the first link but I think that is just link rot and probably people Bingle for it anyway. Windows Insider link seems to work: https://insider.windows.com/ Not much they can do about the windows.uservoice.com link since Microsoft don't own the site. The docs.microsoft.com page is actually hosted in GitHub. You can follow the "Edit" link to the GitHub page and raise an issue there (or even do it yourself and submit a pull request!)Re: Feedback & Feature Issues
Joe, I think you will have a better chance of getting some of these issues resolved, or at least seen by the appropriate people, if you just post them individually, i.e. one specific question to start each conversation. If you have feature requests then a good forum is UserVoice itself, rather than this forum. For advice on using this forum, see the "Info Center" link in the menu bar, or go straight to the 'Getting Started' forum for more info.Re: SPFx, Fabric, and Modern Themes
The modern themes are designed to work with the modern pages and are not relevant to classic pages. But an SPFx web part can be rendered in a 'classic' page and of course you can create a 'modern' appearance using CSS tools like Office UI Fabric. By default your SPFx web part will have a modern look and rendering it in a classic page won't change this. Having said that, there is the possibility that there will be a conflict between the very complex CSS in classic SharePoint and the Office UI Fabric, and I have heard of people finding their SPFx web parts didn't look right when rendered in a classic page as opposed to a modern page or in the workbench. You might need to do a bit of F10 browser developer tool detective work to fix these issues in practice.Re: How to simplify external acces on SharePoint Online site?
If the partner organisation is also using Office 365 you should share to their Office 365 ID rather than have them create a Microsoft Account. Yes, it is confusing and the naming doesn't help as most people think their Office 365 account is their "Microsoft" account. Microsoft 365 branding isn't going to improve this. You could consider creating a Microsoft Account for each of the external users and sending them the credentials (securely) so at least they are ready to go and they don't have to do the setting up and accepting the link. Another possible simplification is to create an Office 365 Group as the basis of sharing which would help make sure you only had to set things up the once for each user. There's a good explanation of sharing on the ShareGate site. If using federated identities for your partners is a possibility, that might be worth considering, although probably complete overkill for the scenario you are talking about.Re: Failing to Configure Workflow Manager for SharePoint 2013 On-Premise
My guess is that you don't have Workflow Manager installed properly. Please check you have done all the steps in this article: https://social.technet.microsoft.com/wiki/contents/articles/34407.sharepoint-2016-step-by-step-installation-of-workflow-manager.aspx
