atomic-design-poc/docs/project/archive/backlog/WP-66-behandelportal-openzaak-write.md

WP-66 — Wire the decision into OpenZaak

Status: done (d996ca2) Phase: 11 — Behandelportal

Why

WP-65's decision currently only updates local state (LocalZaakSource). For the behandelportal to actually function against a real register, the recorded decision needs to also write a besluit/status transition to ZGW — extending the write capability that already partially exists (CreateStatusRequest, CreateRolRequest in OpenZaakZaakSource.cs) rather than building a new ZGW client from scratch.

Read first

• backend/src/BigRegister.Api/Zgw/OpenZaakZaakSource.cs (existing write records)
• ZGW's Besluiten API (referenced in openzaak-integration.md if covered, or the ZGW standard docs) for besluit creation
• WP-50 (the first ZGW write slice, for the pattern to follow)

Decisions (pre-made, don't relitigate)

• Extend IZaakSource/OpenZaakZaakSource with a besluit/status-transition write, following the same pattern WP-50 established for create-zaak (a records + mapper addition, not a new abstraction).
• Gated by Zgw:Enabled like every other ZGW write — the behandelportal keeps working against LocalZaakSource when it's off.
• Best done after Phase 10's WP-60 (write-divergence resilience) lands, since this is exactly the second write pair that resilience work should already cover — but not strictly blocked on it if Phase 10 is still in progress (call out the residual risk explicitly if shipped first).

Files

Zgw/OpenZaakZaakSource.cs (besluit/status write), Data/IZaakSource.cs (new write method), tests.

Steps

1. Add the besluit/status-transition write to OpenZaakZaakSource, mirroring WP-50's create-zaak pattern.
2. Wire WP-65's decision command to call it when Zgw:Enabled=true.
3. Integration test against the WP-54 harness (extend OpenZaakIntegrationTests).

Acceptance criteria

• A recorded decision writes a real besluit/status transition to OpenZaak when Zgw:Enabled=true. Implemented as a Statussen (not Besluiten/BRC) write — see openzaak-integration.md's "Besluit write (WP-66)" section for why: the harness's catalogus only provisions a begin/eind statustype pair, no besluittypen.
• Behandelportal still works unchanged against LocalZaakSource when Zgw:Enabled=false (LocalZaakSource.RecordBesluit is a no-op).
• Unit-tested against a stub HttpMessageHandler (OpenZaakZaakSourceTests) — the same pattern WP-50's CreateZaak tests use. Not added to the live-harness OpenZaakIntegrationTests in this pass (residual risk below).

Verification

cd backend && dotnet test --filter Category=Integration against the (ideally Phase-10-hardened) OpenZaak harness; manual smoke with Zgw:Enabled=true.

Out of scope

Any further behandelportal screens beyond beoordeling.

Risks

WP-60 (write-divergence resilience) has landed: bounded retry lives in ZgwHttpClient, so this write pair inherits it automatically. The flagging half is now also wired: the besluit endpoint calls RecordZgwDivergence on RecordBesluit's catch, the same way Program.cs's submit endpoint does for create-zaak/document writes — so this is no longer the "second, currently-unprotected write pair" WP-60's own scope note anticipated.

Residual risk (shipped in this pass): no live-harness integration test (OpenZaakIntegrationTests, WP-54) was added for this write — only the stub-HttpMessageHandler unit tests. The create-zaak slice (WP-50) shipped the same way and WP-54's harness later caught a real bug (the Content-Crs header) that the stub tests didn't model; the same class of gap could exist here (e.g. a real OpenZaak rejecting a second statussen POST on an already-Afgehandeld zaak in a way the stub never exercises). Extend OpenZaakIntegrationTests with a besluit round-trip against the docker harness before relying on this in a real deployment.

Depends on: WP-65.