Reliable Remote Event Receivers using Queues or Service Bus
Remote event receivers have no concept of reliability, or retry in case of failure. If for some reason the Provider-hosted app is unavailable, the remote event receiver will not retry the operation, and that message is lost.
Would love to see the use of a queue or service bus to retry the operation, maybe up to a certain limited number of times. Also would be great to have the failures stored somewhere and exposed so that provider-hosted apps could query for failures and make any necessary adjustments to catch up.
Thank you for your input. We have just GA’d SharePoint WebHooks for lists and libraries, which provide more reliable event mechanism for events. We will be investing on this area and will add additional WebHooks in near future. These won’t be using queues as such, but you can add the notification to queues in your custom end point.
1 commentComments are closed
Siim Aaver commented
Unfortunately WebHooks are not always the replacement for Remote event receivers. If I need to compare item's values before and after an update (for example whether the Status field of an item was changed from Active to Inactive), this cannot be done with WebHooks.
For Remote ERs I could use the ItemUpdating synchronous event to load the item's previous data using CSOM and compare it to values in Remote ER's AfterProperties. WebHooks do not give me any more information other than an item was updated in a specific list. I'm not even getting the ID of the item that was modified. I know I'm supposed to run a ChangeQuery against that list to obtain updated items. Unfortunately the ChangeQuery API does not give me any history about the item's metadata that was changed in the process. To make matters worse, CSOM or REST API do not fully support working with Item's Version history either. Currently the only way to obtain metadata from version history, is to use the old and deprecated Lists.asmx web service. Unfortunately that service only works with username/password authentication and is therefore unusable in my SP Add-In that requires OAuth.
In that scenario, WebHooks are not a replacement for Remote Event Receivers. WebHooks also lack support for synchronous events and therefore cannot be used for preventing the user from adding or updating an item in the list based on some metadata/permission/etc checks. In my opinion, raising the reliability of the RERs is still important.