Instructie
Moeilijkheidsgraad:
Google Calendar-koppeling implementeren: checklist test en productie
Dit artikel is de praktische implementatiegids voor de Google Calendar-koppeling, met een checklist voor zowel een testomgeving als productie. Hetzelfde Google Cloud-project, dezelfde OAuth-client en infrastructuur gelden in beide; in test wil je een wegwerp-omgeving waarin je vrij afspraken kunt aanmaken, wijzigen en verwijderen. De genummerde stappen hieronder beschrijven de volgorde; gebruik daarna de checklists per omgeving.
Infrastructuur-eisen (push + polling)
- Publiek webhook-endpoint: Google watch-channels posten naar
{base_url}/api/rest/integrationcalendarwebhook/google. Dit endpoint moet publiek bereikbaar zijn vanaf Google. Op een lokale dev-box betekent dit een tunnel (ngrok / Cloudflare tunnel) of een publiek bereikbare testhost; zonder bereikbaar endpoint kan Google geen channel registreren. - Channel-lifecycle: een watch-channel verloopt; de cron vernieuwt het automatisch zodra het binnen 2 dagen verloopt.
- Cron + worker: de cron
ExecuteIntegrationsmoet draaien voor channel-renewal en polling-fallback (> 30 min geen sync). Bij gequeuede verwerking moet een worker (RabbitMQ) draaien voor de inbound-/renew-jobs. Herstart workers + leeg OPcache na een deploy van worker-/config-wijzigingen.
Checklist — testomgeving
- ☐ Google Cloud-project aangemaakt/gekozen.
- ☐ Google Calendar API ingeschakeld.
- ☐ OAuth consent screen geconfigureerd met scopes
calendar.readonly+calendar.events. - ☐ Bij External-app: de in te loggen gebruiker als test user toegevoegd.
- ☐ OAuth-client (Web application) aangemaakt; Client ID + secret genoteerd.
- ☐ Redirect URI
{base_url}/integrations/redirect/{int_id}geregistreerd in de OAuth-client. - ☐ Dedicated Google-account beschikbaar om mee in te loggen (geen persoonlijk account).
- ☐ Publieke webhook-URL bereikbaar door Google.
- ☐
ExecuteIntegrations-cron draait (renewal + polling-fallback). - ☐ Worker (RabbitMQ) draait als gequeuede verwerking wordt gebruikt.
- ☐ Auth-scherm gevuld + Stap 1 consent + Stap 2 verbinden uitgevoerd.
- ☐ Object → agenda-mapping ingevuld (incl. eventuele
*-standaard). - ☐ Outbound- en inbound-velden ingesteld; koppeling actief; watch-channel aangemaakt.
- ☐ End-to-end getest: boeking-statuswijziging → afspraak in Google; en afspraak in Google → boeking in i-Reserve.
Checklist — productieomgeving
- ☐ Productie-OAuth-client met productie-redirect-URI op het productie-base-url; secret apart beheerd.
- ☐ OAuth consent screen indien nodig gepubliceerd (niet in testmodus) zodat het refresh-token niet vroegtijdig verloopt.
- ☐ Webhook-endpoint op productie publiek bereikbaar (echte host/SSL, geen tunnel).
- ☐
ExecuteIntegrations-cron en worker(s) draaien op productie; OPcache geleegd na deploy. - ☐ Echte object → agenda-mapping (geen testagenda's/-objecten).
- ☐ Eerste live sync geverifieerd + watch-channel-status gecontroleerd op het diagnosescherm.
- ☐ Rollback bekend: koppeling op inactief zetten stopt sync zonder data te verliezen.
Maak of kies een project in de Google Cloud Console en schakel de Google Calendar API in.
Configureer het OAuth consent screen (Internal of External), voeg de scopes calendar.readonly en calendar.events toe en bij External de in te loggen gebruiker als test user.
Maak een OAuth client ID (Web application) aan, registreer de redirect-URI die i-Reserve toont en noteer Client ID en secret.
Zorg dat het webhook-endpoint (.../integrationcalendarwebhook/google) publiek bereikbaar is en dat de ExecuteIntegrations-cron en (indien gebruikt) de RabbitMQ-worker draaien.
Vul in i-Reserve het authenticatie-scherm (client/secret/return url), doorloop consent + verbinden, vul de object-agenda-mapping en de outbound-/inbound-velden in.
Zet de koppeling actief, verifieer op het diagnosescherm dat het watch-channel is aangemaakt, test end-to-end inbound en outbound en loop de checklist per omgeving af.
