Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
SPSNL15 - Remote Event Receivers
- 1. Introductie in het ontwikkelen van Remote Event Receivers
- 2. E: vincent@point42.nl T: @vverbeek87 B: sharepointgotchas.wordpress.com Vincent Verbeek
- 3. Handling events in a SharePoint Online environment Agenda
- 4. 1. Out with the old…
- 5. 1. Out with the old…
- 6. Users External System SharePoint 1. User updates SharePoint list 2. Registered event receiver called 3a. Line of business system is updated 1. SharePoint 2010 ERs GAC 3b. SharePoint is updated 4. Event receiver returns
- 7. 2. In with the new!
- 8. 2. In with the new! Remote · [ri mōt′] adjective 1.The definition of remote is something that is far away in place or time or a place that is located away from the populated areas. noun 1.Remote is a device used to control the TV or other electronic equipment. An example of remote is the controller that comes with your cable box.
- 9. 2. SaaD (SharePoint as a Datahub) SharePoint External System External System External System External System
- 10. ACS Users External System Custom Web Service SharePoint 1. User updates SharePoint list 3. Registered event receiver called 2. SharePoint requests token from ACS 4. Line of business system is updated 5. Event receiver returns 2. RERs
- 11. ACS Users External System Custom Web Service SharePoint 1. User updates SharePoint list 3. Registered event receiver called 2. SharePoint requests a token from ACS 4. Line of business system is updated 5. Event receiver requests a token from ACS 2. RERs - callback 6. Event receiver calls back into SharePoint
- 12. 2. Tooling
- 14. 5. Limitations • No guaranteed delivery • Timeout • No Web and Site Collection events • Provider Hosted Add-ins only • Hosting restrictions • Inconvenient removal
- 15. 6. Patterns & Practices (PnP) http://dev.office.com https://github.com/OfficeDev/PnP
- 16. 7. Q & A Feel free to contact me! vincent@point42.nl @vverbeek87
- 17. THANK YOU
Editor's Notes
- Hier de laatste ontwikkelingen rondom terminologie aankaarten. Waarom we Add-in vorm aankaarten De wisseling van App naar Add-ins De presentatie gaat over een Cloud scenario => Cloud First approach Host web / App web is minder relevant. Als je het gaande weg tegenkomt, dan uitleggen.
- SharePoint executes events in the following order: 1. Synchronous “before” events in sequence order 2. Synchronous “after” events in sequence order 3. Asynchronous “after” events Custom code in GAC implement a required interface and register for events. The custom codecan 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 calls the registered event receivers, this event receivers lives in de GAC as an dll . 3. The event receiver can do anything it wants. 3a. update an Line of business system. 3b. update SharePoint data. 4. The event receiver returns a code to SharePoint indicating the outcome of the event.
- Rust moment!
- CvI: Kan je hier wat mee? Een RER is in beide vormen “remote” namelijk het draait ver weg van SharePoint (Populated area) en het is een controller voor SharePoint. Als je hier geen aansluiting bij hebt even overleg. Onderstaande kwam uit je sheet en kan je uiteraard bij deze sheet gewoon vertellen! What Process events from SharePoint using custom code Why To react on user or customization actions done in the host web Old pattern was created by event receivers with server-side code How Create remote event receivers Registration can be done either using server-side (on-prem) or client-side (Office 365) code External web service is called when events in host web occur
- 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 systems of SharePoint events. As a result it is 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 Microsoft SharePoint Online, 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 cannot 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. If you have developed event receivers before, you will find this very familiar and you will be able to take advantage of your skills with this model.
- SharePoint executes events in the following order: 1. Synchronous “before” events in sequence order 2. Synchronous “after” events in sequence order 3. 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 (Azure Access Control Service) 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 line of business (LOB) system. 5. The event receiver returns a code to SharePoint indicating the outcome of the event.
- Het is ook mogelijk om vanuit de RER data in SharePoint te manipuleren. De flow voor de RER veranderd dan een klein beetje ten opzichte van de vorige sheet. In plaats van rechtstreeks het resultaat terug te geven aan SP, vraagt de RER ook een token aan van de ACS. Deze token bevat informatie over de context en de gebruiker en die informatie kan gebruikt worden om gegevens in SharePoint weer aan te passen. 6. The remote event receiver can use the token to call back into SharePoint and perform a task.
- Drie manieren om een RER toe te voegen aan lijsten. Via een wizard in Visual Studio. Dit werkt alleen voor lijsten in het app-web. Via CSOM code, eventueel tijdens installatie van de app, maar ook mogelijk om hiervoor aparte functionaliteit in een Provider Hosted app te bouwen; Via SSOM code, maar dat is dus alleen voor on-premises Demo volgt op volgende pagina
- Demo the creation of remote event receivers Create sample for Server Side creation Create sample for CSOM creation (in code) Create sample for Visual Studio wizard
- Er is geen mechanisme die ervoor zorgt dat je RER altijd afgetrapt wordt. De webservice moet actief zijn en in staat zijn om berichten te ontvangen. Als om wat voor reden dan ook je server even down is op het moment dat de RER afgetrapt wordt, zal deze niet bereikt worden. Er is niets OOTB ingebouwd om te zorgen dat er over een x aantal minuten opnieuw wordt gepollt om te kijken of de RER dan wel actief is. Voor synchrone events geldt dat er een timeout is van 30 seconde waarbinnen SharePoint weer verder moet gaan met de executie van zijn code. Dat betekent dat je in ‘ING’ events binnen 30 seconde klaar moet zijn met de executie van je RER code. Alleen list en list item events zijn beschikbaar voor remote event receivers. In tegenstelling tot de ‘ouderwetse’ receivers is het dus niet mogelijk om in te haken op web of site-collectie events. RERs kunnen alleen gemaakt worden in een Provider Hosted app en werken niet in een SP Hosted App. Dat is ook wel logisch, als je nagaat dat er een webservice gebruikt wordt. Om toch een soort van RER te maken in een SP hosted app kan je een workflow gebruiken en die laten afvuren bij een event. Je kunt een RER hosten in de cloud (azure) of een on-premises server die niet als SP server gebruikt wordt. Je kunt geen poortnummer opgeven, dus je bent gebonden aan poort 443 of poort 80. Als je HTTPS gebruikt en de RER op een on-premises server host, maar de app staat op SP Online, dan moet de hosting server een vertrouwt certificaat hebben. Een self-signed certificaat werkt alleen als de app ook op een on-premises omgeving geïnstalleerd staat. Tijdens de development wil het regelmatig gebeuren dat de client ID wordt aangepast aan de hand van wijzingen die je in het project maakt. Event receivers die gekoppeld zijn met een add-in die een bepaalde clientID heeft, kunnen ook alleen verwijderd worden door diezelfde add-in met hetzelfde clientID. Is het clientID anders, dan krijg je een access denied error, ook al ben je tenant administrator. Voor meer informatie zie de blogpost van Waldek. http://blog.mastykarz.nl/inconvenient-remote-event-receivers-apps-sharepoint/
- Open source library GitHub Samples Remote site provisioning Branding