Outlook-koppeling implementeren: checklist test en productie

Dit artikel is de praktische implementatiegids voor de Outlook-koppeling, met een checklist voor zowel een testomgeving als productie. Dezelfde app-registratie, permissies en infrastructuur gelden in beide; in test wil je een wegwerp-tenant waarin je vrij agenda-items kunt aanmaken, wijzigen en verwijderen op gebruikers- en zaal-mailboxen. De genummerde stappen hieronder beschrijven de volgorde; gebruik daarna de checklists per omgeving.

Infrastructuur-eisen (push + polling)

De koppeling gebruikt zowel Graph change-notification subscriptions (push) als een cron-polling-fallback. Voor een realistische test moeten beide werken.

• Publiek webhook-endpoint: Graph-subscriptions posten naar {base_url}/api/rest/integrationcalendarwebhook/outlook. Dit endpoint moet publiek bereikbaar zijn vanaf Microsoft en de validationToken-handshake echoën (anoniem/publiek by design). Op een lokale dev-box betekent dit een tunnel (ngrok / Cloudflare tunnel) of een publiek bereikbare testhost; zonder validatie kan Graph geen subscription aanmaken.
• Subscription-lifecycle: één subscription per gesynchroniseerde agenda (gedelegeerd: één op me; applicatie: één per zaal). Subscriptions verlopen na 3 dagen en worden door de cron vernieuwd binnen 2 dagen voor verloop.
• Cron + worker: de cron ExecuteIntegrations moet draaien voor renewal en polling-fallback (> 30 min geen sync). Bij gequeuede verwerking moet een worker (RabbitMQ) draaien voor de jobs integration_calendar_inbound en integration_calendar_renew_webhook. Herstart workers + leeg OPcache na een deploy van worker-/config-wijzigingen.

Checklist — testomgeving

• ☐ Single-tenant Entra ID app-registratie aangemaakt in de test-tenant.
• ☐ Client secret gegenereerd (geen certificaat).
• ☐ Redirect URI ingesteld op {base_url}/integrations/redirect/{int_id}.
• ☐ Tenant ID, Client ID en Client secret genoteerd.
• ☐ Delegated Calendars.ReadWrite toegevoegd (voor modus A).
• ☐ Application Calendars.ReadWrite toegevoegd + admin consent (voor modus B).
• ☐ ApplicationAccessPolicy beperkt de app tot een security-group met zaal-mailboxen.
• ☐ Dedicated M365-serviceaccount voor gedelegeerde auth (geen persoonlijk account).
• ☐ Gebruikersmailbox beschikbaar (modus A) / zaal-mailboxen + UPN's beschikbaar (modus B).
• ☐ Publieke webhook-URL bereikbaar door Graph en echoot validationToken.
• ☐ ExecuteIntegrations-cron draait (renewal + polling-fallback).
• ☐ Worker (RabbitMQ) draait als gequeuede verwerking wordt gebruikt.
• ☐ Auth-scherm gevuld + Stap 1 consent + Stap 2 verbinden uitgevoerd.
• ☐ Config-scherm gevuld, modus gekozen, object/zalen gekoppeld, koppeling actief.
• ☐ End-to-end getest: item in Outlook aangemaakt → boeking in i-Reserve; en (gedelegeerd) boeking-statuswijziging → item in Outlook.

Checklist — productieomgeving

• ☐ Aparte (of dezelfde, bewust gekozen) app-registratie in de productie-tenant van de klant; productie-secret apart beheerd.
• ☐ Permissies en (voor app-only) admin consent in de productie-tenant verleend.
• ☐ ApplicationAccessPolicy ook in productie ingesteld (geen tenant-brede toegang).
• ☐ Productie-redirect-URI geregistreerd op het productie-base-url.
• ☐ Webhook-endpoint op productie publiek bereikbaar (geen tunnel; echte host/SSL).
• ☐ ExecuteIntegrations-cron en worker(s) draaien op productie; OPcache geleegd na deploy.
• ☐ Echte zaal-mailboxen ↔ juiste i-Reserve-objecten gekoppeld (geen testobjecten).
• ☐ “E-mail bij problemen” ingesteld op een bewaakt adres.
• ☐ Eerste live sync geverifieerd + webhook-status gecontroleerd op het diagnosescherm.
• ☐ Rollback/uit-knop bekend: koppeling op inactief zetten stopt sync zonder data te verliezen.