Activiti integration

Deferred for full coverage — Activiti is wired into the codebase but no process is deployed in the current live DB. See Slice 7 (deferred).

This page captures what's in the codebase about Activiti so a future maintainer doesn't start from zero when the workflow story is finally exercised.

Two Activiti versions

The dependency tree carries two Activiti versions:

Module	Version	Notes
xlyPersist	org.activiti:activiti-engine:5.17.0	Older 5.x line
xlyFlow	org.activiti:activiti-spring-boot-starter-rest-api:6.0.0, activiti-json-converter:6.0.0	Newer 6.0 line

This is a real version mismatch. Activiti's 5.x and 6.x schemas overlap but diverge in some act_* tables and migration paths. Possibilities:

1. The framework runs Activiti 6.0 (xlyFlow drives the runtime) and xlyPersist's 5.17 dependency is dead weight from an earlier era.
2. Different services use different versions for legacy reasons.
3. Both are in the classpath but only one is initialised at runtime.

A future maintainer attacking this should: (a) remove the unused version to avoid confusion, (b) document which version the live schema uses, (c) verify the act_* table layout matches that version exactly.

One extra code fact matters in this branch: xlyFlow/build.gradle pulls in the Activiti 6 starter, but xlyFlow/src/main/java/com/xly/XlyFlowApplicationBoot.java is fully commented out. So workflow code is present, but this repository does not currently present xlyFlow as a clearly runnable standalone app.

The act_* schema

The live DB currently has the expected act_* tables, but the key ones checked during this pass are all empty:

• act_re_deployment = 0
• act_re_procdef = 0
• act_ru_task = 0
• act_hi_procinst = 0

xly's wrapper layer

Three xly tables wrap the Activiti integration:

• biz_flow — xly's per-document flow state.
• biz_todo_item — pending approver tasks.
• biz_todo_copyto — CC'd parties on a flow.
• gdsmoduleflow + gdsmoduleflowslave — module-flow window configuration.

The wrapper tables are empty in the live DB too: gdsmoduleflow = 0, biz_flow = 0, biz_todo_item = 0, biz_todo_copyto = 0.

The pattern when active: a document submission writes a biz_flow row + an Activiti process instance starts; pending approvers see biz_todo_item rows; on approval the proc instance advances and eventually completes.

Where Activiti is wired in code

xlyFlow/ is the dedicated module. Notable files (when this page is fleshed out):

• xlyFlow's pom-equivalent gradle build pulls in Activiti 6.0.
• The Spring Boot config for Activiti's process engine.
• CheckFlowController in xlyEntry/com/xly/web/businessweb/ is one surface the SPA hits to drive workflow (approve / reject / view).
• BPMN process definitions, when present, live in xlyFlow/src/main/resources/processes/ (or similar) — empty in this codebase.

What's needed to make Activiti work

In a deployment that uses workflow:

1. BPMN process definitions deployed (act_re_procdef populated).
2. Modules tagged bCheck = 1 and linked to the right process via gdsmoduleflow.
3. Approver users assigned via act_id_* or xly's wrapper of it.
4. The save endpoint, on bCheck = 1 modules, branches to start a process instance instead of (or alongside) the standard add/update/delete.

This page becomes a real reference once a deployment with deployed processes is available; until then, treat it as an inventory of what ought to be here.