M365Con 2027 – gratis online conferentie · 11–22 Jan 2027 · 120 sessions→ m365con.net

Blog · Mirko Peters

Hoe je betrouwbare Microsoft Graph-webhooks bouwt voor SharePoint en M365

By ·

Bouw betrouwbare Microsoft Graph-webhooks voor SharePoint en M365 met veilige validatie, geautomatiseerde verlengingen en robuuste afleving van meldingen.

Automatically translated with AI from the original post. Read the English original

▶ BLOGHow to Build ReliableMicrosoft Graph Webhoo……M365.FM
Titelbild: How to Build Reliable Microsoft Graph Webhooks for SharePoint and M365

Betrouwbare Microsoft Graph-webhooks bouwen voor SharePoint en M365 kan ook ervaren ontwikkelaars uitdagen. Je kunt problemen tegenkomen zoals mislukte validatie als je endpoint het validatietoken niet terugstuurt of geen 200 OK-status teruggeeft. Veelvoorkomende problemen zijn endpoints die door firewalls worden geblokkeerd, netwerkmisconfiguraties of middleware die ingrijpt. Gemiste nieuwe pogingen en verlopen abonnementen komen vaak voor wanneer de service het validatieverzoek niet ontvangt of wanneer endpoints niet publiek toegankelijk zijn. Je leert hoe je deze valkuilen vermijdt en een robuuste, veilige meldingenketen bouwt, compleet met een praktische checklist en best practices.

Belangrijkste punten

Fundamenten van Microsoft Graph-webhooks

Wat zijn Microsoft Graph-webhooks

Een webhook is een HTTP-verzoek dat wordt geactiveerd door een gebeurtenis in een bronsysteem en naar een doelsysteem wordt gestuurd, vaak met een gegevenspayload. Webhooks werken automatisch: ze worden verzonden zodra hun gebeurtenis in het bronsysteem plaatsvindt.

Je gebruikt Microsoft Graph-webhooks om realtime meldingen te ontvangen over wijzigingen in je Microsoft 365-omgeving. Dat betekent dat je Microsoft Graph niet constant hoeft te bevragen op updates. In plaats daarvan krijgt je applicatie een melding zodra er iets belangrijks gebeurt. Zo blijf je up-to-date en gesynchroniseerd met gegevens die via Microsoft Graph beschikbaar zijn. Ook heb je geen pollinginfrastructuur meer nodig, waarbij je regelmatig verzoeken naar Microsoft Graph stuurt om te controleren op de nieuwste wijzigingen.

Je kunt meldingen instellen voor veel soorten gebeurtenissen, zoals:

Je wilt bijvoorbeeld automatisch een account aanmaken in een tijdregistratiesysteem van een derde partij wanneer een nieuwe gebruiker zich bij je organisatie aansluit. Ook kun je contentverwerking starten, zoals declaratieverwerking, wanneer iemand een nieuw bestand toevoegt aan een SharePoint-documentbibliotheek of OneDrive-map.

Waarom betrouwbaarheid ertoe doet

Microsoft Graph-webhooks spelen een sleutelrol om je SharePoint- en Microsoft 365-integraties responsief en actueel te houden. Wanneer je webhook-keten betrouwbaar werkt, reageren je applicaties in realtime op wijzigingen. Gebruikers zien altijd de meest actuele gegevens, wat hun ervaring verbetert en het risico op verouderde informatie verkleint.

Betrouwbaarheidsproblemen kunnen echter ernstige gevolgen hebben:

Om een robuuste oplossing te bouwen, combineer je webhooks het best met delta-queries om wijzigingen efficiënt bij te houden. Daarnaast moet je processen opzetten om abonnementen regelmatig te controleren en te verlengen. Bij bronnen die vaak wijzigen, helpt batching om de belasting te beheersen.

Webhooks instellen en valideren

Het instellen van Microsoft Graph-webhooks voor SharePoint en M365 bestaat uit verschillende belangrijke stappen. Je moet je webhook registreren, validatieaanvragen afhandelen en je eindpunt beveiligen. Elke stap speelt een cruciale rol om ervoor te zorgen dat je meldingspijplijn betrouwbaar en veilig werkt.

Microsoft Graph-webhooks registreren

Je begint met het maken van een webhookabonnement. Hiermee kan je applicatie meldingen ontvangen over wijzigingen in Microsoft 365-resources. Volg deze stappen om je webhook te registreren:

  1. Maak een openbaar toegankelijk eindpunt dat HTTPS gebruikt. Dit eindpunt ontvangt meldingen van Microsoft Graph.

  2. Stuur een POST-aanvraag naar het /subscriptions-eindpunt in Microsoft Graph.

  3. Geef in je abonnementsaanvraag het volgende op:

    • changeType: De soorten wijzigingen die je wilt volgen, zoals "created", "updated" of "deleted".

    • notificationUrl: De URL van je webhookeindpunt.

    • resource: De resource die je wilt monitoren, zoals "/users" of "/drive/root".

    • expirationDateTime: De datum en tijd waarop het abonnement moet verlopen.

    • Optionele eigenschappen, zoals clientState, helpen je de herkomst van meldingen te verifiëren.

Voorbeeld van een abonnementsaanvraag:

POST https://graph.microsoft.com/v1.0/subscriptions
Authorization: bearer eyJ0eXAiOiJ[..]
Content-Type: application/json

{
  "changeType": "updated",
  "clientState": "SecretClientState",
  "notificationUrl": "https://yourdomain.com/api/notifications",
  "resource": "/users",
  "expirationDateTime": "2024-05-01T00:00:00.0000000+00:00"
}

Zorg ervoor dat je eindpunt openbaar toegankelijk is en via HTTPS is beveiligd. Microsoft Graph valideert de meldings-URL voordat het abonnement wordt voltooid. Je moet abonnementen regelmatig verlengen om meldingen te blijven ontvangen. Je eindpunt moet tijdig en consistent HTTP-antwoorden geven, zodat je geen meldingen mist.

Hier is een overzicht van de vereiste velden voor registratie:

Veld

Beschrijving

changeType

Geeft het type wijziging aan dat de melding activeert (bijvoorbeeld 'updated').

clientState

Een aangepaste tekenreeks die helpt de herkomst van de melding te valideren.

notificationUrl

Het eindpunt waarnaar meldingen worden verzonden.

resource

De resource die wordt gemonitord (bijvoorbeeld '/users').

expirationDateTime

De datum en tijd waarop het abonnement verloopt.

validationToken

Een token dat in het antwoord moet worden teruggegeven om de abonnementsaanvraag te valideren.

Validatieaanvragen afhandelen

Nadat je je webhook hebt geregistreerd, stuurt Microsoft Graph een validatieaanvraag naar je eindpunt. Je moet correct reageren om het abonnementsproces te voltooien. Wanneer je eindpunt een GET-aanvraag ontvangt met de queryparameter validationToken, moet je dit token als platte tekst in de responsbody terugsturen en een 200 OK-status teruggeven.

Aanvraagtype

URL

Queryparameter

Verwachte responsstatus

Content-Type

Responsbody

GET

https://yourdomain.com

validationToken=1234

200 OK

text/plain

1234

💡 Tip: Snel en correct reageren op validatieaanvragen zorgt ervoor dat je webhookabonnement zonder problemen wordt geactiveerd.

HTTPS en beveiliging van het eindpunt

Het beveiligen van je webhookeindpunt is essentieel. Microsoft Graph-webhooks vereisen HTTPS-versleuteling om gevoelige gegevens tijdens de communicatie te beschermen. Je moet inkomende aanvragen verifiëren door de handtekening te controleren die is gemaakt met een gedeelde geheime sleutel. Gebruik complexe, willekeurig gegenereerde paden voor je callback-URL's, zodat ze moeilijker te raden zijn.

Elke webhook-callback gebruikt een ondertekend JSON Web Token (JWT) in de Authentication-header van de inkomende HTTPS-aanvraag. Je kunt standaard OpenID Connect-validatietechnieken voor JWT gebruiken om de integriteit van het token te waarborgen.

Je moet HTTPS gebruiken voor alle webhook-eindpunten. Deze vereiste beschermt je gegevens en zorgt voor naleving van de beveiligingsstandaarden van Microsoft. Het beveiligen van je eindpunt helpt ongeautoriseerde toegang en aanvallen te voorkomen.

Door deze stappen te volgen, zet je een betrouwbare en veilige Microsoft Graph Webhooks-pijplijn op voor SharePoint en M365. Zo zorg je ervoor dat je applicatie meldingen snel en veilig ontvangt.

Meldingen verwerken en beveiligen

Zodra je je webhook-eindpunt hebt ingesteld, moet je inkomende meldingen veilig en betrouwbaar verwerken. Deze stap zorgt ervoor dat je applicatie alleen geldige aanvragen accepteert en dat je nooit belangrijke updates van Microsoft Graph Webhooks mist.

JWT-tokens authenticeren en verifiëren

Elke melding van Microsoft Graph bevat een JSON Web Token (JWT) in de Authorization-header. Je moet dit token verifiëren voordat je een payload verwerkt. Correcte JWT-validatie beschermt je systeem tegen ongeautoriseerde of gemanipuleerde aanvragen.

Volg deze stappen om JWT-tokens te authenticeren en te verifiëren:

  1. Controleer of het token niet is verlopen. Tokens bevatten een vervaltijd en je moet elk token weigeren dat na dit tijdstip valt.

  2. Bevestig dat het token is uitgegeven door het Microsoft identity platform. Valideer de handtekening van het token om zeker te zijn dat het niet is gewijzigd.

  3. Zorg dat de claim "audience" in het token overeenkomt met de ID van je applicatie. Deze stap bevestigt dat het token bedoeld was voor jouw app.

  4. Controleer of de eigenschap azp (authorized party) overeenkomt met de verwachte waarde voor je applicatie.

Tip: Gebruik altijd betrouwbare bibliotheken voor JWT-validatie. Deze bibliotheken helpen je veelgemaakte fouten te vermijden en je applicatie veilig te houden.

Let daarnaast op veelvoorkomende beveiligingskwetsbaarheden bij het verwerken van JWT-tokens:

Door deze stappen en voorzorgsmaatregelen te volgen, zorg je ervoor dat alleen legitieme meldingen je applicatie bereiken.

Notificatiepayloads verwerken

Nadat je de melding hebt geauthenticeerd, moet je de payload veilig verwerken. Notificatiepayloads bevatten informatie over de gebeurtenis die de webhook heeft geactiveerd. Om de gegevensintegriteit te waarborgen en beveiligingsproblemen te voorkomen, moet je:

Let op: Het valideren en saneren van payloads beschermt je systeem tegen onjuist opgemaakte gegevens en beveiligingsdreigingen.

Logica voor opnieuw proberen en backoff implementeren

Netwerkproblemen of tijdelijke storingen kunnen ervoor zorgen dat het afleveren van meldingen mislukt. Om gegevensverlies te voorkomen, heb je een robuuste strategie voor opnieuw proberen en backoff nodig. Microsoft raadt aan exponentiële backoff en gestructureerde wachtrijen te gebruiken om nieuwe pogingen te beheren.

Hier is een tabel met een samenvatting van veelgebruikte mechanismen voor opnieuw proberen en backoff:

Mechanismetype

Beschrijving

Exponentiële backoff

Verhoogt de wachttijd tussen pogingen na elke mislukte poging exponentieel.

Hoofdwachtrij

De initiële wachtrij waarin webhookgebeurtenissen worden gepubliceerd, zoals main.webhook.queue.

Retry-wachtrijen

Wachtrijen voor het afhandelen van nieuwe pogingen, met de naam retry.webhook.queue-M, waarbij M het nummer van de poging is.

Abandon-wachtrij

Een laatste wachtrij voor berichten die na alle nieuwe pogingen zijn mislukt, zoals abandon.webhook.queue.

TTL-berekening

De time-to-live (TTL) voor elke retry-wachtrij gebruikt de formule: {interval} + {current_retry_attempt} ^ 4.

x-retry-header

Een header die het aantal nieuwe pogingen per bericht bijhoudt.

Dead letter-exchange

Een exchange die berichten ontvangt die niet meer opnieuw kunnen worden verwerkt en ze doorstuurt naar de abandon-wachtrij.

Als je geen goede logica voor nieuwe pogingen en backoff implementeert, loop je het risico dat je meldingen verliest of dat er inconsistenties in je gegevens ontstaan. Mislukte aanvragen of rate limiting kunnen ervoor zorgen dat je belangrijke updates niet ontvangt. Exponential backoff helpt je om aanvragen die worden gethrottled te beheren en verkleint de kans dat je systeem of Microsoft Graph Webhooks overbelast raken.

🛡️ Best practice: Houd altijd bij hoeveel nieuwe pogingen er zijn gedaan en verplaats mislukte berichten na enkele pogingen naar een abandon-wachtrij. Zo kun je aanhoudende problemen onderzoeken en oplossen zonder gegevens te verliezen.

Door JWT-tokens te authenticeren, payloads te valideren en betrouwbare logica voor nieuwe pogingen te implementeren, bouw je een veilige en robuuste meldingenpijplijn. Met deze stappen verwerk je elke melding van Microsoft Graph Webhooks veilig en efficiënt.

Abonnementen beheren en wijzigingen bijhouden

Automatisch vernieuwen van abonnementen

Je moet je webhookabonnementen actief houden om te voorkomen dat je meldingen mist. Microsoft Graph-abonnementen verlopen na een vastgestelde periode. Als je ze niet vernieuwt, ontvangt je applicatie geen updates meer. Je kunt het vernieuwen op verschillende manieren automatiseren:

Tip: Door vernieuwingen te automatiseren, bespaar je handmatig werk en blijft je systeem verbonden met Microsoft Graph.

Monitoring en waarschuwingen

Je moet de gezondheid van je webhookpijplijn bewaken. Stel waarschuwingen in die je informeren als een abonnement niet kan worden vernieuwd of als je endpoint niet meer reageert. Gebruik logging om binnenkomende meldingen en vernieuwingspogingen bij te houden. Zo zie je problemen al voordat ze gebruikers raken.

🛎️ Proactieve monitoring helpt je problemen snel op te lossen en houdt je integratie betrouwbaar.

Delta-query's gebruiken voor het bijhouden van wijzigingen

Met delta-query's houd je wijzigingen bij in SharePoint- en M365-resources, en dat op een efficiënte manier. Je kunt ze gebruiken om alleen nieuwe of bijgewerkte gegevens te ontvangen. Dat vermindert de noodzaak voor frequent pollen en verkleint het risico op throttling.

Delta-query's hebben echter enkele beperkingen:

Beperking/uitdaging

Beschrijving

OData-context

Wordt onjuist geretourneerd bij het bijhouden van wijzigingen in relaties.

Schema-extensies

Wordt niet geretourneerd met een $select-statement, maar wel zonder dit statement.

Open extensies

Clients kunnen geen wijzigingen bijhouden in open extensies of geregistreerde schema-extensies.

Let op: Test je delta-queryimplementatie altijd grondig om met deze beperkingen om te gaan en nauwkeurige wijzigingsregistratie te garanderen.

Door vernieuwingen te automatiseren, je pijplijn te bewaken en delta-query's te gebruiken, bouw je een betrouwbaar en efficiënt webhooksysteem voor SharePoint en M365.

Je bouwt betrouwbare Microsoft Graph-webhooks door een duidelijk proces te volgen. Begin met het aanmaken van abonnementen en het gebruik van delta-queries om wijzigingen bij te houden. Automatiseer de verlengingen en monitor je pipeline op problemen. Geef bij elke stap prioriteit aan validatie, beveiliging en veerkracht. Gebruik voor de productiegereedheid deze checklist:

Meettype

Beschrijving

Beveiligingsscans in de CI-pipeline

Scan op kwetsbaarheden vóór de implementatie.

Geautomatiseerd auditlogboek

Registreer elke build en implementatie voor naleving en audits.

Pas deze best practices toe zodat je SharePoint- en M365-integraties betrouwbaarblijven.

Veelgestelde vragen

Hoe verläng je een verlopen Microsoft Graph-webhookabonnement?

Je stuurt een PATCH-aanvraag naar het eindpunt /subscriptions/{id} van Microsoft Graph. Werk het veld expirationDateTime bij. Plan dit proces dagelijks in. Zo blijven je abonnementen actief en mis je geen meldingen.

Wat moet je doen als je webhookeindpunt de validatie niet doorstaat?

Controleer of je eindpunt de validationToken als platte tekst teruggeeft in de responsbody. Reageer met de statuscode 200 OK. Zorg dat je eindpunt publiek toegankelijk is en HTTPS gebruikt.

Hoe beveilig je je webhookeindpunt?

Gebruik HTTPS voor alle eindpunten. Valideer JWT-tokens in elke aanvraag. Beperk de toegang met authenticatie en een IP-whitelist. Houd het systeem in de gaten op ongebruikelijke activiteit. Controleer je beveiligingsinstellingen regelmatig.

Waarom moet je delta-queries gebruiken met webhooks?

Delta-queries helpen je om alleen nieuwe of gewijzigde gegevens bij te houden. Dit beperkt het gebruik van bandbreedte en verbetert de prestaties. Je hoeft niet elke keer alle gegevens te downloaden, waardoor je integratie sneller en efficiënter werkt.

Wat is de beste manier om mislukte webhookmeldingen af te handelen?

Implementeer retry-logica met exponentiële backoff. Houd het aantal pogingen bij via headers of wachtrijen. Verplaats berichten die na meerdere pogingen nog steeds mislukken naar een abandon-wachtrij. Onderzoek deze fouten om gegevensverlies te voorkomen.

Microsoft Graph Change notifications and webhooks SharePoint OneDrive Microsoft 365

Related articles

RSS