Inconvenient Remote Event Receivers and Apps for SharePoint

Remote Event Receiver code in Visual Studio 2013
Remote Event Receivers allow you to integrate your apps with SharePoint by handling events that occur in SharePoint. There are however a few things you should keep in mind before you start working with them.

Remote Event Receivers

Remote Event Receivers are one of the great improvements in the SharePoint platform. Basically they are WCF services that can be registered to act upon different events that occur in SharePoint. With that Remote Event Receivers align pretty well with the new philosophy of building solutions for SharePoint outside of the SharePoint platform and using remote APIs to communicate with SharePoint.

There a number of ways for registering Remote Event Receivers in SharePoint, but probably the two most relevant ones are using the Client-Side Object Model (CSOM) in and outside of Apps for SharePoint. Please note that, although the registration code is exactly the same whether your CSOM code is running in the context of an App for SharePoint or not, I explicitly name those two scenarios and it’s not without a reason.

Registering Remote Event Receivers using CSOM

Registering a Remote Event Receiver using CSOM is relatively easy and comes down to the following code:

List list = web.Lists.GetById(listId);  
list.EventReceivers.Add(new EventReceiverDefinitionCreationInformation {  
    EventType = EventReceiverType.ItemUpdated,
    ReceiverName = "MyRemoteEventReceiverItemUpdated",
    ReceiverUrl = "https://contoso.com/api/v1/MyRemoteEventReceiver.svc",
    SequenceNumber = 10000
});
list.Update();

clientContext.ExecuteQuery();  

You start with retrieving the container on which you want to register the Remote Event Receiver – a List in this example. Next you add a new EventReceiverDefinitionCreationInformation object to the EventReceivers collection. This object contains information about your Remote Event Receiver such as its URL and which SharePoint event it handles. Finally you persist the changes by updating the List and submitting the query.

Inconvenient Remote Event Receivers and Apps for SharePoint

As I mentioned before the code for registering a Remote Event Receiver is exactly the same whether you are executing it from the context of an App for SharePoint or not. What happens behind the scenes isn’t however.

Registering and unregistering Event Receivers

When registering a Remote Event Receiver from an App for SharePoint, SharePoint automatically adds the App ID to the Event Receiver’s registration information. One of the consequences of this is the fact, that you will be able to remove that particular Event Receiver only by using the same app that registered it! If you try to remove an Event Receiver that has been registered by an app with a different ID you will get a Server Unauthorized Access Exception.

ServerUnauthorizedAccessException when trying to unregister an Event Receiver registered by another app

In theory this doesn’t necessarily have to be a problem: after all if your app registers an Event Receiver it can also unregister it. Unfortunately in development, when the App ID changes regularly, if you don’t clean up the Event Receivers your app registered before changing your app, you will end up with a number of orphaned Event Receivers.

If you’re developing on-premises you can relatively easily get a hold of the App ID of the app that registered the Event Receiver from the ULS log as it’s logged as a part of the ServerUnauthorizedAccessException. The message containing the current ID of your app and the ID of the app that registered the particular Event Receiver will be logged in the Dev Events category on Medium level. With this information you could build an app with exactly that ID to remove the orphaned Event Receiver.

If you’re working with Office 365 things look a lot worse. First of all the App ID stored with the Event Receiver Definition is stored in an internal property that isn’t exposed in CSOM. Additionally, as there is no way for you to access the ULS logs, you won’t be able to get the ID of the app that registered the particular Event Receiver and the only way for you to clean things up would be to delete the List where the Event Receiver is registered.

Handling events in Event Receivers

Another thing that I’ve noticed when working with Remote Event Receivers was that orphaned Event Receivers are not triggered if the URL of the Remote Event Receiver hasn’t changed.

Imagine the following scenario: you register a Remote Event Receiver from an App for SharePoint. The App ID changes what results in an orphaned Event Receiver. You register a Remote Event Receiver from your app once again and now you have one orphaned and one Event Receiver with the current ID of your App. When the event, to which your Remote Event Receiver is subscribed, occurs your Remote Event Receiver will be called only once for the valid App ID.

Summary

Remote Event Receivers offer great flexibility for handling events that occur in SharePoint in Apps for SharePoint. When working with Remote Event Receivers however you should be thorough in registering and unregistering them particularly when working with Apps for SharePoint in Office 365. Forgetting to unregister an Event Receiver will result in an orphaned Event Receiver that is very difficult to remove.

Comments

comments powered by Disqus