Ga naar inhoud

Een formulier/proces live brengen

Een developer levert een feature-bundle (en evt. een zaaktype-script) aan via een gemergede PR — developers hebben geen terminaltoegang. Als serverbeheerder rol je de wijziging uit. De keten loopt over twee stacks; volgorde: eerst zgw, dan portal.

Wat de developer aanlevert

  • portal: een map laravel/resources/features/<naam>/ met manifest.json, objecttype.json, formulier.py, <naam>.bpmn (+ evt. handlers in app/ExternalTasks/).
  • development: zaaktypen/bootstrap-<naam>-zaaktype.sh (alleen bij een nieuw zaaktype).

1. zgw-stack (objecttype → zaaktype → formulier)

Bij voorkeur via de GitHub Actions-knop (zero-downtime, geen server-login) — zie Deploy via GitHub: workflow "Formulieren deployen". Die draait op de server:

Stap Script Wat
Objecttype scripts/bootstrap-objecttype.sh scant FEATURES_DIR/*/objecttype.json, maakt het objecttype, publiceert een versie, schrijft OBJECTTYPE_<NAAM>_UUID naar .env
Zaaktype development/zaaktypen/*.sh (via bootstrap.sh) status-/rol-/resultaattypen + IOT-relatie (eenmalig per nieuw type; wire in bootstrap.sh)
Formulier scripts/deploy-feature-forms.sh loopt alle bundles, resolvet UUID + hoogste versie, draait formulier.py in de OF-container

Handmatig op de server (indien nodig):

cd /root/zgw
bash scripts/bootstrap-objecttype.sh
bash scripts/bootstrap-<naam>-zaaktype.sh   # alleen bij een nieuw zaaktype
bash scripts/deploy-feature-forms.sh

De zgw-deploy leest de bundles uit de portal-repo via FEATURES_DIR (default: portal naast zgw; instelbaar in zgw/.env).

2. portal-stack (proces → dossierdefinitie → workers)

Eerst de development-submodule bijwerken

De developer-content (features, subprocessen, handlers, workers) komt uit de development-repo, ingehangen als submodule laravel/development. Werk die vóór de portal-build bij, anders mist de content: 

cd /root/portal && git checkout main && git pull
git submodule update --init --recursive          # of: --remote voor de laatste main
docker compose build portal && docker compose up -d portal

Gebeurt verder automatisch bij het (her)deployen van de portal (entrypoint draait migraties/seeds/BPMN-deploy + de worker-seed). Zie Deploy & updaten. Handmatig:

docker exec portal-portal-1 php artisan operaton:deploy-system-processes   # bpmn uit bundles + gedeelde processen
docker exec portal-portal-1 php artisan db:seed --class=DossierdefinitieSeeder
  • operaton:deploy-system-processes deployt resources/processes/*.bpmn én resources/features/*/*.bpmn.
  • DossierdefinitieSeeder leest elke resources/features/*/manifest.json (idempotent; objecttype nog niet aangemaakt → overgeslagen en hersteld bij een volgende run).

Wat gebeurt er bij een inzending?

inzending → OF schrijft object (objecttype-versie) → Objects-API-notificatie
         → portal-webhook → dossierdefinitie gevonden → proces gestart → zaak + workers

Verificatie-checklist

  • [ ] zgw-deploy gedraaid: OBJECTTYPE_<NAAM>_UUID in zgw/.env, formulier opent op https://<openforms-host>/<ofSlug>, testinzending slaagt.
  • [ ] portal-deploy gedraaid: proces zichtbaar in de cockpit, dossierdefinitie aanwezig.
  • [ ] docker exec portal-portal-1 supervisorctl status → external-task-worker RUNNING; alle topics uit de BPMN hebben een handler.
  • [ ] Testinzending doorloopt de hele keten (object → proces → zaak → status/resultaat → evt. taak → afgerond).