Forum Discussion
SharePoint Webhooks -- now Generally Available!
We’re considering on-prem SP2016 support for webhooks, but don’t have a date for that to share at this point.
I really haven't gotten a clear picture on the Webhooks vs. Event Reciever story. At first I thought i would be that Envent revcievers are not allowed in SPOnline. But some of my searchs result a "remote reciever". Not really sure what that is ...but.....well you get the jist.
Any clarity? How about a link to an article? I'll take anything.
Event receivers have been part of SharePoint for years. They enable you to run code on the server in response to an event in a list/library. If you know how to create SharePoint farm solutions, they are easy to implement, but because they run on the server a poorly written event receiver can cause major issues, and as such are not allowed in O365.
Remote Event Receivers were the solution to the above. In this model, SharePoint calls a WFC endpoint for a specified event in a list/library. This solves the issue re running code on the server. So, create a WCF service, host it on some server, and configure sharepoint to call it for a specified event (this last step is done by deploying a SharePoint app AKA add-in)
Web hooks are the newest version of the above. Like remote event receivers, SharePoint is simply doing a call to another service for a specified event on a list/library. However, instead of a WCF service, the web hook is simply making an HTTP call (so, a POST to a URL). One option for creating a webhook is an Azure function: create a function based on an HTTP trigger, then register that function with SharePoint. Non SharePoint devs will like this, as they don't need to know as much about SharePoint to get this up and running. Again, it uses HTTP calls instead of WCF, which is another plus. Also, since other services use web hooks, it means that devs can build events for many services using one set of technologies, instead of having to learn a different system for each service. For example, wordpress supports web hooks, so a developer could support events in sharepoint and wordpress by creating azure functions, and wouldn't have to learn the esoterics of SharePoint add-ins.
Any future development should probably look at using web hooks instead of remote event receivers.
Thx for the comparison. Is there any reason to switch to using web hooks (besides being nice to future developers :) )? We are currently using remove event receivers, deployed using SP Add in. Is there for example any improvement in performance? Avoiding the use of SP Add-In is, as far as I can see, the biggest plus for using web hooks.
One detail that might be useful is that web hooks have an automatic retry mechanism. According to the docs linked to above: "If an event occurs in SharePoint and your service endpoint is not reachable (e.g., due to maintenance) SharePoint will retry sending the notification. SharePoint performs a retry of 5 times with a 5 minute wait time between the attempts". To contrast, there is no queue and no retry mechanism for remote event receivers.
