eho/register-referentie
1
0
Fork 0
Code Issues 10 Pull Requests 1 Actions Packages Projects Releases 1 Wiki Activity

fix(infra): deploy diploma-eligibility DMN via dmn-api, not a process .bar (refs #14)
CI / lint (pull_request) Successful in 1m18s
Details
CI / build (pull_request) Successful in 1m3s
Details
CI / unit (pull_request) Successful in 1m9s
Details
CI / frontend (pull_request) Successful in 2m37s
Details
CI / mutation (pull_request) Successful in 5m27s
Details
CI / verify-stack (pull_request) Successful in 7m39s
Details

Browse Source 
flowable-rest does not cascade a .dmn bundled inside a process .bar into the
DMN engine: the resource is stored but no decision is created, so the DMN
service task fails at runtime with FlowableObjectNotFoundException. Deploy the
DMN to the DMN engine via /dmn-api/dmn-repository/deployments and the BPMN to
the process engine separately; the service task resolves the decision across
deployments by key (verified live: Buitenlands->CBGV_ADVIES, Binnenlands->DIRECT).

Also move the DMN's doc comment inside <definitions>: Flowable's DMN XML
converter rejects a comment between the <?xml?> declaration and the root element
(XMLStreamReader not in START_DOCUMENT/START_ELEMENT state), unlike its BPMN one.

seed-config.sh now seeds both raw workflow files instead of building a .bar.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
not
2026-07-20 09:05:41 +02:00
co-authored by Claude Opus 4.8
parent d5100d9d41
commit dc4822e53d
5 changed files with 64 additions and 46 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/architecture/adr-0016-diploma-eligibility-dmn.md
+12 -6
View File
@@ -36,12 +36,18 @@ only new job is to carry the diploma origin and pass it into the process as a st
`DiplomaOrigin` (Binnenlands/Buitenlands); `SubmitRegistration` passes it to
`StartRegistrationProcessAsync`, which sets it as the `diplomaOrigin` start variable. The domain
never evaluates the DMN and never learns the route — that is the process's concern.
- **Deployed in one `.bar` with the BPMN.** The DMN is version-controlled in `workflows/` and bundled
with `registratie.bpmn` into a single `registratie.bar` (by `seed-config.sh`) that `flowable-init`
deploys as one deployment. This is required, not cosmetic: `flowable-rest` does not expose the
`dmn-api` app, and Flowable resolves an inline DMN scoped to the process's own deployment — so a
standalone `.dmn` deployment is invisible to the process (`FlowableObjectNotFoundException: No
decision found for key`). Co-deploying gives the decision the process's parent deployment id.
- **Deployed as its own DMN-engine deployment, separate from the BPMN.** The DMN is version-controlled
in `workflows/` and `flowable-init` deploys it to the DMN engine via the `dmn-api`
(`/dmn-api/dmn-repository/deployments`), while `registratie.bpmn` goes to the process engine via
`/service/repository/deployments`. Two things were learned the hard way here (both cost a CI cycle):
(1) `flowable-rest` does **not** cascade a `.dmn` bundled inside a process `.bar` into the DMN engine
— the resource is stored but no decision is created, so the service task fails at runtime with
`FlowableObjectNotFoundException: No decision found for key`; the DMN must go through `dmn-api`.
(2) Flowable's DMN XML converter rejects an XML comment placed between the `<?xml?>` declaration and
the root `<definitions>` element (`XMLStreamReader not in START_DOCUMENT or START_ELEMENT state`),
unlike its BPMN converter — so the DMN's documentation comment lives *inside* `<definitions>`.
With the decision present in the DMN repository, the process's DMN service task resolves it across
deployments by key (verified live), so no shared parent deployment id is needed.
## Consequences