Friday 16 March 2018

Building SharePoint Webhook Services with Serverless Architecture

Before looking out at the implementation of webhook models in SharePoint, here let us look at how Serverless web hooks concept can be feasible.

What is Serverless architecture? It allows us to build the required services, without the need of servers. Some Azure services like Azure functions helps building such Serverless models.

The components like webhook service, storage queues, web jobs and SQL database are hosted on Azure. The following picture depicts the Serverless webhooks process, with the help of Serverless components. The components present on the Azure box, depicts serverless architecture model.

Serverless Architecture for SharePoint Webhook Services
Serverless Architecture for SharePoint Webhook Services


Required Components for Building Serverless SharePoint Webhooks:


To implement Serverless webhooks for SharePoint online events, the following are the required components.
  • SharePoint Online Subscription
  • Azure Subscription
    • AD tenant – For enabling permissions
    • Azure Functions – Building the system to receive the notifications
    • Azure Webjobs – To process the data stored on queues
    • Azure Storage – Queues, Databases
  • Postman client – For sending the requests (request test tool on desktops) 

In the previous post, we have seen theoretically how the events can be processed from SharePoint services.

The previous posts might help in understanding the webbook services better.



Process the Notifications sent by SharePoint service


The webhook service requires two components.
  • Create the Azure Function,
  • Create the Azure storage queue.

The Azure function acts as webhook service, which will process the notifications sent by SharePoint service. And the notifications will be pushed to the Azure storage queue.

The following code snippet depicts the above flow.


Subscribing to the Event Notifications


To access the SharePoint list item for subscription or from services related to webhooks, authentication token has to be generated from the Azure AD. 
  • Register the application on Azure AD, with the necessary reply URL and providing read/write permissions on the SharePoint lists.
  • Or you need to hardcode the credentials for accessing the SharePoint list data. 
We will go with the first option. So before hitting the subscription post query, we need to have the access token generated for oAuth authentications.

Postman tool can be used for subscribing to the events. This step will help registering the webhook service (built in the previous step) on the SharePoint list for event changes.

Paste the subscription URL of the list and select the action as POST.
https://nakkeerann.sharepoint.com/_api/web/lists('9AC9CF26-55E2-46DE-96B7-310714417132')/subscriptions

Get the access token, with the following parameters passed.


Get oAuth Token
Generate oAuth Token for Subscriptions

Once you have the oAuth token, use it for subscription. Then using the post request with the following parameters, register the webhook service.
  • Headers – Accept : application/json;odata=nometadata
  • Content-Type : application/json
  • Request Body will contain the 
    • Resource URL
    • Notification URL
    • Expiration date time and 
    • Client state (optional).
           {
  "resource": "https://nakkeerann.sharepoint.com/_api/web/lists('9AC9CF26-55E2-46DE-96B7-310714417132')",
  "notificationUrl": "https://azurefunctionurl/api/webhookservice",
  "expirationDateTime": "2018-04-27T12:11:37+00:00",
  "clientState": "GUID"
              }
Subscribe Webhook Service for Event Changes
Subscribe Webhook Service for Event Changes

Once the request is posted using postman tool, 
  • The SharePoint will send a request with the validation token to webhook service built using Azure functions. 
  • The webhook service should respond back with the valid token within 5 seconds. 
  • If that happens, SharePoint will respond back to postman tool with a success message. 

This flow ensures the registration of webhook service on SharePoint list. The response will contain
  • Subscription ID
  • Expiration date
  • Resource ID
  • Tenant ID
  • Site URL and 
  • Web ID.

Processing the notifications using WebJobs


Next, let us see how to process the notifications present on Azure storage queues and extract the change information from the respective lists. Then the changes will be saved on SharePoint lists as history or logs.

The following code snippet shows the webjob which will process the notifications present on Azure storage queue and save the changes into the logs list present in the SharePoint.


The following picture shows the webhook service notification changes being saved on SharePoint.

Processed Webhook Changes stored on SharePoint list
Processed Webhook Changes stored on SharePoint list