1. Remote Event Receivers
Name
Title
Company

2. Agenda Introducing Remote Event Receivers Simple Call Scenario
Advanced Callback Scenario
Developing Remote Event Receivers

3. Introducing Remote Event Receivers

4. Remote Event Receivers
SharePoint increasingly acting as data hub
No way to inform External Systems of events in old version
Highly-requested capability by customers
Now included in SP2013
External Lists also support events
SharePoint is increasingly used as the hub for productivity and collaborative experiences that incorporate and interact with data from a variety of external systems. Capabilities like those offered by Business Connectivity Services offer a powerful infrastructure for surfacing external data inside SharePoint, and SharePoint web services offer an increasing complete set of options for surfacing SharePoint data in outside systems.
SharePoint does not, however, currently provide a convenient mechanism for informing external system of SharePoint events. As a result it’s effectively impossible to build an efficient solution that reacts to changes in SharePoint data, except through complex, farm-deployed solutions that use custom event receivers and web service interfaces to call into external systems. Given that farm-deployed solutions are not allowed in SPO, even this solution is not available to Office 365 customers.
In addition, the current sandboxed solution infrastructure imposes quite a few restrictions on the developer. For example, solutions can’t execute for longer than 30 seconds, and they cannot exceed a certain amount of resource usage per day. Allowing a developer to execute their event receiver logic outside of the SharePoint farm makes it possible for them to overcome these restrictions and build more robust solutions.
This was one of the most highly requested features, providing support for external systems to receive events from SharePoint so they can take action based on that event. There are also enhanced capabilities in Business Connectivity Services to allow external systems to receive information. We aren’t talking about BCS in this module, we’ll talk about that in the BCS module in this course. If you’ve developed event receivers before, you’ll find this very familiar and you’ll be able to leverage your skills with this model.

5. Remote Event Receivers
Microsoft SharePoint Server 2013
Remote Event Receivers
Custom Web Service
3. Registered Event Receiver called
4. Line-of-Business System is updated
5. Event Receiver Returns
External System
1. User Updates SharePoint List
SharePoint
Users
SharePoint executes events in the following order
Synchronous “before” events in sequence order
Synchronous “after” events in sequence order
Asynchronous “after” events
Custom web services implement a required interface and register for events
The custom web service can perform any required action and then call back into SharePoint
1. When a user interacts with a supported artifact, then an event fires
2. SharePoint requests ACS to create and sign a token which contains context information about the current user along with an authorization code
3. SharePoint calls the registered event received ( a web service) and passes the context token. The web service validates the signature on the context token and extracts the authorization code
4. The event receiver can do anything it wants. In this case, updating a LOB system
5. The event receiver returns a code to SharePoint indicating the outcome of the event
ACS
2. SharePoint requests a token from ACS
© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

6. Remote Event Receivers - Callback
Microsoft SharePoint Server 2013
Remote Event Receivers - Callback
Custom Web Service
3. Registered Event Receiver called
4. Line-of-Business System is updated
6. Event Receiver calls back into SharePoint
1. User Updates SharePoint List
External System
5. Event Receiver Requests a token from ACS
SharePoint
Users
1. When a user interacts with a supported artifact, then an event fires
2. SharePoint requests ACS to create and sign a token which contains context information about the current user along with an authorization code
3. SharePoint calls the registered event received ( a web service) and passes the context token. The web service validates the signature on the context token and extracts the authorization code
4. The event receiver may perform any action it needs to such as updating a system hosted in the cloud
5. The Remote Event Receiver requests a token from ACS that it can use to call back into SharePoint
6. The Remote Event Receiver can use the token to call back into SharePoint and perform a task
ACS
2. SharePoint requests a token from ACS
© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

7. Remote Event Receivers - Architecture
Event scopes
List Item
List
Web
App
Support for the following types
Synchronous Events
Asynchronous After Events
Remote event receivers have event scopes at the list item, list, web, and app level. There is support for both synchronous and asynchronous events. The goal is to make the remote event receivers equivalent to the standard event receivers in SharePoint. If you’ve written event receivers before, you will be able to take advantage of what you know using this new model.
In cases where latency is high, remote synchronous events could cause significant delays in the operations that the event is responding to. They are implemented to provide similar support to the standard event receivers, so you’ll need to consider what is appropriate in your scenario. Synchronous events are available today, though, and they’re important, especially for complex data validation rules.

8. Remote Event Receivers - Architecture
RERs not a good choice for “mirroring” or sync solutions
Use RER to receive notification that a change has occurred
Use interface to poll SharePoint for changes
Write changes as required
No guaranteed delivery
Although custom code can help improve
RERs are not good for mirroring or sync solutions. We have seen where people have tried to use event receivers to synchronize data between farms or to update databases when data is changed. These are not good uses of event receivers in either model, but particularly with remote event receivers because there is no guaranteed delivery. You won’t have that message queued up for delivery and then wait for the remote endpoint to come back online to continue processing. The remote endpoint has to be online and listening for the delivery to occur. You can write some custom code to try to improve this, but you don’t receive that out of the box.

9. Developing Remote Event Receivers

10. Remote Event Receivers - Development Process
Developer builds a custom web service
Developer implements required interface in web service
Developer registers service with App
Web service is called when appropriate SharePoint events occur
The high-level design of the remote event receiver is to allow developers to register remote event receivers with SharePoint in a way very similar to the way that local event receivers are registered today. The only major difference is that the developer will provide a web service url rather than an assembly and class name when registering the event receiver. When the event in question occurs, a web service caller will be sent and  the event properties to the specified web service url, and it will expect information about the result of the event receiver in response.  The process involves a developer building a custom web service using the required interface, registering the service, and then the web service is called when the appropriate event occurs.

11. Remote Event Receivers - Tooling
Add a Remote Event Receiver as a New Item
Remote Event receivers can be added directly to App projects.

12. Remote Event Receivers - Interface Methods
Synchronous and asynchronous events are supported
ProcessEvent
The defined interface supports “ING” events and synchronous “ED” events. ING events occur before the actual event, such as the actual adding of an item to a list or the actual deleting of an item in a list. In this version of SharePoint, we can also specify that the ED events, meaning notification after the event has occurred, we can specify that the call is processed synchronously.
ProcessOnewayEvent
The defined interface supports asynchronous “ED”
The web service takes a single argument of type SPRemoteEventProperties and returns SPRemoteEventResults for synchronous events
The web service takes a single argument of type SPRemoteEventProperties and returns void for “ED” events
SPRemoteEventProperties will always pass an EventType property, which describes the type of event that is occurring or has occurred. In addition, one of ItemEventProperties, ListEventProperties, or WebEventProperties will be passed, depending on the EventType.
For “ING” events, the web service will respond with an object of type SPRemoteEventResult, which will specify the status of the event and, if applicable, the list of changed properties, an error message, and/or a redirect url.
The remote event receiver web service caller will only support calling SOAP-based web services
The web service caller will use XML serialization
The web service caller will depend on the outbound Oauth authentication scheme

13. Remote Event Receivers
Calling Back into SharePoint
The boilerplate code that is generated by Visual Studio looks similar to the code above. We use the CreateRemoteEventReceiverClientContext method of the TokenHelper class to obtain a client context based on the context token that is passed to the WCF service. The end result is that you will have a client context that will be used to call back into SharePoint, making advanced scenarios possible where we call back into SharePoint for further processing. The system used to call back into SharePoint, the security tokens and Oauth, are not covered in detail in this module, we have another module that covers that. In this module, we just want to focus on the fact that it’s possible to retrieve the token to be used to make a call back into SharePoint.

14. Remote Event Receivers - Registration
Remote event receivers will be registered through the existing “Receiver” child element of the “Receivers” feature element. It will ignore the “Assembly” and “Class” child elements, and it will add the “Url” child element

15. Remote Event Receivers - Registration
string url= "
using (SPSite site = new SPSite(siteUrl)) {
using (SPWeb web = site.RootWeb)
SPList list = web.Lists[listTitle];
list.EventReceivers.Add(
SPEventReceiverType.ItemAdded,
url); }
Object model associated with remote event receivers functions identically to SPEventReceiverDefinition, except that it will have an additional Url property, and the Assembly and Class properties will not be used.

16. Remote Event Receivers
demo

17. Summary Introducing Remote Event Receivers Simple Call Scenario
Advanced Callback Scenario
Developing Remote Event Receivers

18. Q&A

19. © 2012 Microsoft Corporation. All rights reserved
© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.