© best_vector/Shutterstock.com
Kolumne: SharePoint ganz praktisch

Kolumne: SharePoint ganz praktisch


Die vorherige Ausgabe der Kolumne erläuterte die Arbeitsweise von WebHooks und zeigte die Implementierung und Funktionsweise auf. In der aktuellen Ausgabe geht es nun um die detaillierte Auswertung der WebHook-Informationen.

Wie bereits in der vorherigen Ausgabe erläutert und praktisch demonstriert wurde, stellen WebHooks einen weiteren Benachrichtigungsmechanismus dar. WebHooks sind als Alternative zu den klassischen SharePoint-Ereignisempfängern zu verstehen, wobei jedoch beachtet werden muss, dass WebHooks lediglich über Ereignisse informieren können. Eine Einflussnahme auf das Ereignis ist allerdings nicht mehr möglich. Somit kann zum Beispiel das Löschen eines SharePoint-Lis­ten­eintrags nicht verhindert werden. Dies ist nur mit einem direkten SharePoint-Ereignisempfänger möglich. Daher sollten WebHooks nur dann verwendet werden, wenn lediglich auf Listen- bzw. Bibliotheksereignisse reagiert werden muss, ohne diese abbrechen zu müssen. Weiterhin ist zu beachten, dass SharePoint Ereignisse sammelt und sie zusammengefasst über WebHooks an interessierte Abonnenten verteilt. Somit werden Ereignisse auch nicht in „Echtzeit“ übermittelt, sondern zeitversetzt. Auch dieses Verhalten ist bei der Planung eigener Lösungen zu berücksichtigen. Besteht die Notwendigkeit darin, zeitnah auf ein Ereignis zu reagieren, muss für diesen Fall eventuell wieder ein klassischer SharePoint-Ereignisempfänger realisiert werden. Der in SharePoint umgesetzte WebHook-Mechanismus basiert auf einer kooperativen Arbeitsweise. Dies bedeutet, dass der Empfänger von Ereignissen ebenfalls Zustände halten muss, damit dieser immer aktuelle Ereignisse erhält.

Arbeitsweise von WebHooks

Im einführenden Beispiel wurde bereits ein SharePoint WebHook realisiert. Hierbei wurden jedoch noch nicht alle detaillierten Informationen ausgewertet, die bei jeder WebHook-Benachrichtigung übermittelt werden. Ebenfalls wurde das Änderungstoken noch nicht berücksichtigt. Diese beiden Bestandteile werden nun im weiteren Verlauf näher betrachtet. Im ersten gezeigten Beispiel wurde das von SharePoint übermittelte WebHook-Ereignis nicht vollständig ausgewertet, es wurde lediglich protokolliert. Dies reicht meist für praktische Anwendungsfälle nicht aus. In der Praxis ist es meist relevant zu wissen, welcher Listeneintrag von der Änderung betroffen ist und welche Manipulation – Löschen, Hinzufügen oder Aktualisierung – stattgefunden hat. Diese Informationen werden bei einem WebHook-Aufruf an einen Abonnenten allerdings nicht direkt übermittelt. Stattdessen wird dem Client (Abonnenten) mitgeteilt, in welchen SharePoint-Weblisten und in welcher SharePoint-Liste bzw. -Bibliothek eine Änderung stattgefunden hat. Konkret werden dem Client die folgenden Informationen übermittelt:

  • SubscriptionId

  • ClientState

  • ExpirationDateTime

  • Resource

  • TenantId

  • SiteUrl

  • WebId

Mithilfe dieser Informationen kann ein Änderungstoken zusammengesetzt werden. Listing 1 zeigt die angepasste Version. Die Methode ist im oberen Bereich mit der im vorigen Teil der Kolumne gezeigten Version identisch [1]. Es gibt jedoch im Bereich der Auswertung der Änderungsmeldungen zwei wesentliche Modifikationen. Zum einen werden alle empfangenen Meldungen berücksichtigt und zum anderen werden die Nachrichten nicht direkt ausgewertet, sondern in eine Azure-Warteschlange geschrieben. Die dafür zuständige Methode zeigt Listing 2. Der Zwischenschritt über eine Azure-Warteschlange ist wichtig, da der WebHook Endpoint, wie in der vorherigen Ausgabe bereits erläutert, innerhalb von 5 Sekunden SharePoint über eine Webantwort (Response) wieder eine Rückmeldung geben muss. Geschieht dies nicht in der vorgegebenen Zeit, geht SharePoint davon aus, dass die Nachricht nicht erfolgreich übermittelt wurde. SharePoint wiederholt dann die Zustellung der Änderungsmeldung zu einem späteren Zeitpunkt. Daher ist in diesem Fall ein asynchrones Lösungspattern vorzuziehen. Eine synchrone Lösung wäre auch möglich, nur muss dann sichergestellt werden, dass die durchgeführten Operationen im vorgegebenen Zeitfenster ausgeführt werden können.

Listing 1: WebHook Endpoint (Client/Abonnent)

[HttpPost] public HttpResponseMessage HandleRequest() { HttpResponseMessage httpResponse = new HttpResponseMessage(HttpStatusCode.BadRequest); var t...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang