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>
The DMN service task resolves its decision scoped to the process's own deployment,
so a standalone .dmn deployment was invisible (FlowableObjectNotFoundException: No
decision found for key: diploma-eligibility). Bundle registratie.bpmn +
diploma-eligibility.dmn into a single registratie.bar and deploy it as one
deployment, giving the decision the process's parent deployment id. flowable-rest
does not expose the dmn-api app, so co-deployment is the way in.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
flowable-rest's businessRuleTask parse handler binds the legacy Drools/KIE
implementation (NoClassDefFoundError: org.kie.api...AgendaFilter at deploy time),
so registratie.bpmn failed to deploy and flowable-init exited 22. Flowable's
supported inline-DMN construct is a serviceTask with flowable:type="dmn" — switch
to it. The DMN cross-deploy via the process repository (previous commit) was fine;
this was the BPMN parse. Docs/comments updated to match.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
flowable/flowable-rest embeds the DMN engine but does not expose the dmn-api REST
app, so POSTing the .dmn to dmn-api/dmn-repository/deployments 404'd and
flowable-init exited 22. Deploy the .dmn through the process repository endpoint
instead; the process deployment cross-deploys the resource to the DMN engine,
where the registratie businessRuleTask resolves it by key.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Record the DMN-as-businessRuleTask decision (from proposal #100) and add the S-13
demo walkthrough showing a foreign diploma routing through CBGV-advies.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Gherkin scenarios assert the submit carries the diploma origin (domestic/foreign)
into the process. verify-domain now submits a foreign registration and asserts it
parks at CBGVAdvies before Beoordelen, completes CBGV, then advances to Beoordelen
— exercising both DMN branches through the engine (the domestic DIRECT path is the
first registration already parking straight at Beoordelen).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add workflows/diploma-eligibility.dmn (origin → route) and wire the registratie
BPMN: a businessRuleTask evaluates it inline and an exclusive gateway routes a
foreign diploma through a new CBGVAdvies user task before Beoordelen, a domestic
one straight there (ADR-0016). Deploy the DMN to Flowable's DMN engine and stage
both workflow files into the fl-bpmn volume.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The Workflow Client now posts diplomaOrigin alongside registrationId when starting
the process, and the domain submit endpoint accepts an optional diplomaOrigin
(defaulting to domestic) so a foreign submission can be driven end-to-end. Adds the
aggregate + submit-forwarding tests now that the plumbing is in place.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add DiplomaOrigin (Binnenlands/Buitenlands) to the Registration aggregate and
submit command, and thread it through the process-start port so the workflow's
DMN can route on it (ADR proposal #100). Failing Workflow Client test asserts the
diplomaOrigin start variable; the client takes the origin but does not emit it yet.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Split (issue #11 closed) into two independently-demoable slices per §13 — the original spanned six net-new surfaces including a new ZGW boundary:
**Outcome:** BPMN extended with a "wacht op documenten" user task with a 30-day boundary timer. Self-service portal supports diploma upload. On timeout the case is cancelled.
**Outcome:** BPMN gains a `WachtOpDocumenten` user task with a 30-day (P30D) interrupting boundary timer. On timeout the case is cancelled — the timer runs to a dedicated cancel end-event and the domain aggregate moves to a new terminal status via an external-worker (mirrors S-14 escalation / S-11 withdrawal). Backend only, no frontend.
**Acceptance:** BDD both branches (documents-in-time vs timeout-cancel); live timer-fire via the management-API "move" idiom.
#### S-10b · Diploma upload via ACL Documenten API + self-service portal — #103
**Outcome:** the self-service portal supports diploma upload; the document is stored in the ZGW Documenten (DRC) API and related to the zaak, with all document calls routed through the ACL (§8.1). A successful upload completes the `WachtOpDocumenten` task from S-10a. Depends on #102.
**Acceptance:** BDD scenarios for both branches; integration tests for the timer firing.
### S-11 · Withdrawal (Flow 3)
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
notandClaude Opus 4.8