Dynamische workers (config-gestuurd)

Een external-task worker (de code achter een BPMN-service-task) kun je config-gestuurd maken: je definieert 'm als JSON, geen PHP. Een generieke dispatcher voert de geconfigureerde action uit.

development/workers/<topic>.json  →  seeder  →  worker_definitions (DB)  →  ConfiguredWorkerHandler  →  Action (http/set-vars/mail)
BPMN service-task camunda:topic="<topic>" ───────────────────────────────────────────────┘

Een worker toevoegen (geen PHP)

development/workers/<topic>.json:

{
  "topic": "haal-bag-adres",
  "name": "BAG-adres ophalen",
  "type": "http",
  "config": {
    "method": "GET",
    "url": "https://api.bag.example/adres?pc=${postcode}&nr=${huisnummer}",
    "headers": { "Authorization": "Bearer ${secret:BAG_TOKEN}" },
    "resultMapping": { "straat": "$.results[0].straat", "woonplaats": "$.results[0].woonplaats" }
  }
}

In de BPMN: een service-task met camunda:topic="haal-bag-adres". Commit + PR — klaar.

Action-types (startset)

type	doet	config
http	REST-call	method, url, headers{}, body, timeout, resultMapping{ var: "$.json.path" }
set-vars	variabelen zetten/berekenen	set{ var: "template" }
mail	e-mail sturen	to, subject, body (templates)

Templating

• ${var} → procesvariabele.
• ${secret:NAAM} → een toegestane secret. Een secret moet eerst (door een platform-beheerder) in config/workers.php worden gezet — nooit secrets in de worker-JSON of de repo.
• resultMapping mapt (delen van) een JSON-respons via $.pad.naar.veld terug naar procesvariabelen.

Beheer / hotfix

Beheer → Workers toont alle workers; via Bewerken pas je type + config aan (JSON, met type-hints). Opslaan zet overridden = true → een volgende deploy overschrijft die hotfix niet (de development-repo blijft de bron).

Wijziging live

Een config-wijziging aan een bestaand topic geldt direct (de handler leest de definitie per taak vers uit de DB). Een nieuw topic vereist een herstart van de worker (gebeurt bij een deploy).

Een worker intrekken

Zet "status": "ingetrokken" in workers/<topic>.json (niet verwijderen). De worker wordt dan actief=false en de dispatcher abonneert er niet meer op — het topic wordt dus niet meer verwerkt. Terugzetten = status weer actief.

Wanneer tóch PHP?

Alleen als geen enkel bestaand action-type volstaat: dan voegt een platform-beheerder eenmalig een nieuw action-type toe (een Action-class + 1 regel in ActionRegistry). Voor de developer blijft het: een worker = een JSON-bestand. Een volwaardige eigen handler (zeldzaam) kan nog steeds in development/handlers/.

Veiligheid

• Secrets alleen via ${secret:NAAM} + allowlist in config/workers.php.
• http-action: optionele host-allowlist (WORKER_HOST_ALLOWLIST).
• De beheer-editor zit achter de admin-rol.