Behandlung des Throttlings der Office 365 REST API

08. Januar 2016
Die Office 365 REST API funktioniert im Kern genau wie das äquivalente Gegenstück von SharePoint On-Premise. Es gibt allerdings einige Tücken, die die Entwicklung komplizierter machen und es müssen entsprechende Workarounds geschaffen werden, um ein gleichwertiges Ergebnis zu schaffen. Dieser Blogbeitrag behandelt das Throttling von Office 365, welches bei zu vielen Requests die Verbindung blockiert.

Das Problem des Throttlings von Office 365

Eines der größten Probleme beim Verwenden der REST API von Office 365 stellen wohl die Begrenzten Zugriffe auf die API dar. Die Anzahl an Requests pro Zeiteinheit ist nicht öffentlich bekannt, tritt aber schnell auf wenn beispielsweise viele List Items einzeln abgefragt werden müssen - etwa bei einem Crawler. Läuft man in dieses Throttling, wird nicht der Traffic verlangsamt, wie man vielleicht denken mag - sondern jeder folgende Request mit dem HTTP Statuscode 429 ("Too many requests") für 120 Sekunden abgelehnt. Diese Zeit ist die aktuell im Test festgestellte Sperrdauer. Es kann natürlich sein, dass die Timeout-Zeit herauf- oder herabgesetzt wird. Die Timeout-Zeit steht allerdings mit im Response-Objekt, welches als Fehler zurückgegeben wird.

Welche Lösungsansätze gibt es?

Künstliches verlangsamen der Requests

Das Throttling tritt nur auf, wenn über einen bestimmten Zeitraum mehr Request pro Sekunde ausgeführt werden als erlaubt. Demnach kann man das Throttling umgehen, wenn man Requests künstlich verlangsamt. Da die exakten Limits des Throttlings nicht bekannt sind, lässt sich hierbei nicht sagen, wie viele Requests pro Sekunde erlaubt sind ohne das Throttling auszulösen. Microsoft selbst gibt an, dass die Einstellungen immer wieder angepasst werden, um die Performance für die Nutzer zu verbessern[1].

Lösen des Throttling-Problems mit OData

Office 365 erlaubt die Erweiterung von Requests mithilfe von OData. Ein Request kann somit also durch einen Parameter in der URL erweitert werden, um die Menge der Aufrufe zu reduzieren und Bulk-Requests abzusetzen. Das kann je nach Anwendung die Anzahl der Requests enorm verringern, wenn mehrere Endpunkte eines Requests benötigt werden. 
 
Beispiel-Aufruf ohne OData:
http://site url/_api/web/lists(guid'd4a0dabc-f7c8-4d5b-a132-f7a172e83a44')
http://site url/_api/web/lists(guid'd4a0dabc-f7c8-4d5b-a132-f7a172e83a44')/DefaultView
http://site url/_api/web/lists(guid'd4a0dabc-f7c8-4d5b-a132-f7a172e83a44')/HasUniqueRoleAssignments
 
Beispiel-Aufruf mit OData:
http://site url/_api/web/lists(guid'd4a0dabc-f7c8-4d5b-a132-f7a172e83a44')?$expand=DefaultView,HasUniqueRoleAssignments
 
Als Response kommt eine Liste zurück. Zusätzlich sind die Referenzen DefaultView und HasUniqueRoleAssignments mit im Response-Objekt angegeben. Somit würden zwei Requests eingespart, welche ansonsten daraufhin ausgeführt werden müssten.
 
Weitere Hinweise und Beschreibungen zu Batchanforderungen können Sie hier finden:
 
Sollten Batchanforderungen dennoch nicht ausreichen und die Anwendung läuft ins Throttling, muss diese pausiert werden bis Office 365 weitere Requests freigibt. Dieses Timeout dauert derzeit immer 120 Sekunden. Erst mit Ablauf der Zeit sind wieder Requests möglich. Während dieser Zeitspanne dürfen keine weiteren Requests gegen Office 365 von der Anwendung ausgehen, ansonsten wird die Timeout-Zeit wieder auf 120 Sekunden zurückgesetzt.

Fazit

Das Throttling von Office 365 stellt einen erhöhten Aufwand in der Programmierung dar, doch mithilfe der OData Erweiterung lassen sich dieser schon erheblich einschränken. Falls dies doch nicht ausreichen sollte, bleibt bloß noch die Möglichkeit, die Requests manuell zu verlangsamen oder das Timeout zu beachtet, wenn die Anwendung vom Throttling betroffen ist.
 
 
Referenzen
 

Neuen Kommentar schreiben