Met de komst van SharePoint Apps zien we dat er steeds meer kan met bedrijfsprocessen buiten de SharePoint-omgeving. SharePoint Apps bieden ons namelijk de mogelijkheid om de rekenkracht van cloud servers te benutten voor complexe operaties die in het verleden alleen binnen SharePoint plaatvonden. Hierdoor kan SharePoint gebruikt worden als een data-hub. Maar deze verschuiving heeft wel als gevolg dat er een mechanisme nodig is om externe processen op de hoogte te stellen van de acties die binnen SharePoint plaatsvinden. De remote event receivers zijn uitermate geschikt om deze rol te vervullen. In dit artikel zal ik uitgebreid ingaan op het gebruik van dit mechanisme.
Remote event receivers zijn bijna hetzelfde als de traditionele event receivers die we kennen van voorgaande SharePoint-platformen. Een verschil tussen deze twee is dat de remote event receivers buiten de SharePoint-farm werken. In principe zijn remote event receivers web services die op een externe service (buiten SharePoint) gehost kunnen worden. Deze web services luisteren constant naar meldingen die van SharePoint afkomstig zijn.
De remote event receivers luisteren naar meldingen die kunnen binnenkomen op het moment dat gebeurtenissen plaatsvinden in de volgende SharePoint-componenten:
- Lijsten (creëren, verwijderen, aanpassen)
- Lijstelementen (creëren, verwijderen, aanpassen)
- Web (creëren, verwijderen, aanpassen)
- App (installatie, deïnstallatie, upgraden)
Synchroon en asynchroon
We onderscheiden twee soorten remote event receivers. De synchrone events gebeuren op het moment dat een actie al gaande is,dus alle acties die nog niet definitief hebben plaatsgevonden. De asynchrone gebeurtenissen ontstaan op het moment dat een bepaalde handeling al heeft plaatsgevonden, bijvoorbeeld wanneer een lijstelement al opgeslagen is.
De remote event receivers kunnen gebruikt worden in provider-hosted apps en de beta autohosted apps. Voor SharePoint-hosted apps is het helaas niet mogelijk om gebruik te maken van dit mechanisme. De werking van remote event receivers ziet er als volgt uit:
Wanneer een gebruiker een actie uitvoert die betrekking heeft op het geregistreerde event wordt eerst door Azure Access token service een access token gegenereerd (2) indien de remote event receiver gebruikt wordt binnen Office 365. Voor de on-premises-omgevingen zal deze stap niet gebeuren, omdat de SharePoint-omgeving aan de hand van het certificaat de access token genereert. Vervolgens wordt de melding gestuurd naar het remote event receiver luisterpunt (3). Dit luisterpunt initieert een actie waarbij handelingen verricht kunnen worden in externe systemen (4). Afhankelijk van het type actie kan dan vervolgens door het remote event point een bericht teruggestuurd worden naar SharePoint.
Remote event receivers kunnen zowel gebruikt worden binnen Office 365 als bij een on-premises-omgeving. Voor een Office 365-omgeving wordt er voor het genereren van de access token ACS gebruikt, maar voor de on-premises-omgeving is dit niet altijd het geval, afhankelijk van hoe het landschap is ingericht. Om remote event receivers te gebruiken binnen de on-premises-omgeving die geen gebruik maaakt van ACS dient in het manifest het toestaan van alleen de app-permissies ingeschakeld te worden.
Event receivers aanmaken
Visual Studio 2012 geeft ons de mogelijkheid om eenvoudig de event receivers aan te maken. De remote event receivers kunnen aangemaakt worden door binnen het app-project een nieuw element toe te voegen. Daar kan vervolgens gekozen worden om een event receiver aan te maken.
Bij het kiezen van de remote event receiver worden er twee componenten aangemaakt. De registratie file (element.xml) en een Web service endpoint. Binnen element.xml kan men het type event registeren met de juiste eindpoint.
Zoals aangegeven is in het bovenstaande voorbeeld, wordt een ItemUpdated event geregistreerd op een specifieke lijst die zich binnen onze app-web bevindt. De URL geeft aan welk endpoint naar dit event luistert. Indien de remote event receiver gehost zal worden in Azure of een andere cloudomgeving, dient de URL vervangen te worden door de directe URL van de endpoint, dat is dus inclusief de domain URL.
Naast de element.xml wordt ook een webservice aangemaakt. Binnen deze webservice bevinden zich de volgende twee methoden.
- ProcessEvent
- ProcessOnwayEvent
Binnen de ProcessEvent kan alle logica geïmplementeerd worden die betrekking heeft op de synchrone acties. De ProcesOneWayEevent wordt aangeroepen bij asynchrone acties.
Remote event receivers kunnen ook geregistreerd worden op lijsten of lijstelementen die zich bevinden in de host-web. De registratie hiervan moet echter wel in de code gebeuren. Hiervoor dient een app install event gecreëerd te worden. Binnen dit event kan de onderstaande methode gebruikt worden voor het koppelen van een remote event op een specifieke lijst.
Remote event receivers zijn krachtig, maar helaas niet betrouwbaar. De betrouwbaarheid hangt af van verschillende factoren. Dit mechanisme onthoudt helaas geen berichten en maakt ook geen gebruik van een servicebus. De berichten worden afzonderlijk van elkaar verstuurd naar een luisterpunt. De bereikbaarheid van dit luisterpunt is daarom erg essentieel. Ook is de reactietijd van deze web services belangrijk. Voor asynchrone operaties die veel tijd kosten, wordt er afgeraden om remote event receivers te gebruiken.
Conclusie
In dit artikel heb ik een globale schets gegeven van remote event receivers en de toepasbaarheid van dit mechanisme. Het is een krachtig mechanisme dat ons veel mogelijkheden biedt om externe systemen te kunnen synchroniseren met SharePoint. Helaas vind ik dit mechanisme niet betrouwbaar genoeg om voor bedrijfskritische processen toe te passen. Het is echter wel een mooi begin om oplossingen, die in de traditionele event receivers zijn gebouwd, om te zetten naar cloudoplossingen.
