In Blogs, Mavention Make, Techblog


In the new History overview in Mavention Make an overview of all Sites is presented. It is possible to navigate to the desired sites by clicking on the URL. By clicking on the title more information about the provisioning of the site is presented. This overview is kept up-to-date with the use of a webhook subscription. In this blog an overview of implementation of the webhook is presented. The reference implementation from Microsoft (figure 1.) has been used as a blueprint for our implementation.

Diagram describing the complete end-to-end webhook flow, including The database, the application, the SharePoint Service, the web job, the notification endpoint and the strorage queue.
Figure 1: end-to-end webhook flow.

The Webhook

Webhooks can be used to subscribe on SharePoint online lists. In our case a subscription is made (request: “_api/web/lists(‘{listId}’)/subscriptions”) on the hidden SharePoint list “DO_NOT_DELETE_SPLIST_TENANTADMIN_AGGREGATED_SITECOLLECTIONS”, which contains all SharePoint sites. When a site is altered, for instance the Hubsite association has changed or the site is deleted, an event is triggered, and SharePoint sends an HTTP POST payload to our API. Once the payload is received the API adds an item to the Azure Queue storage. To protect the webhook endpoint a custom ClientState property can be used in the body of the subscription Post request.

The web job

To sync the SharePoint list with our own overview a web job is added. The web job is scheduled to check if notifications are present in the queue and processes these notifications. Once notifications are found in the queue, the worker checks the changes made to the list since the last time the web job has been active (request: “_api/web/lists(‘{listId}’)/getchanges”), this results in a list with list ids that are changed. With this list of list ids we can retrieve these corresponding list items (request: “_api/web/lists(‘{listId}’)/items(‘{itemId}’)”), in our case representations of SharePoint sites, from the list and update our own sites list, which is present in Table storage, accordingly.

The changeToken

To make sure the web job is not processing all notifications since the subscription has been made to the SharePoint list a changetoken has been used. Once a webhook subscription is active on a SharePoint list each retrieved item from that list contains a change token property, this change token is saved in azure table storage. The next time the web job is running it collects the last change token and retrieves changes since, the changetoken in table storage is updated afterwards.

Creating your own webhook subscription

From version 5.5 onwards, webhook subscriptions are supported with Mavention Make (figure 2.). This way webhook subscriptions can be created on SharePoint lists during site provisioning. The webhook can only be placed on a list when an API with a webhook endpoint is running. Click here for more information about SharePoint webhooks. If you want to put several webhooks on a single list, each webhook must have a unique NotificationUrl. The subscription is valid for a maximum of 6 months. An update is required to extend the subscription.

    <List Description="Description of the list" Title="Title of the list" TemplateType="100" GetObjectBy="Default" Url="Lists/WebhookList">
            <Webhook NotificationUrl="" ExpirationDateTime="2019-06-27T16:17:57+00:00" ClientState="TestWebhook"></Webhook>
            <Webhook NotificationUrl="" ExpirationDateTime="2019-07-27T16:17:57+00:00" ClientState="TestWebhookTwo"></Webhook>

Figure 2: example snippit from template.

Vul je zoekopdracht in.