42-流程配置五张表

42-WorkflowConfigService：五类流程配置

流程怎么流转是BPMN的事——但“节点绑什么表单、哪些字段只读、几天时限、谁来处理”全是配置。224行WorkflowConfigService管五张配置表的CRUD：BindingForm表单绑定、FormReadonly只读字段、ActPrcday时限、TaskInterceptor拦截器、RoleSet处理人角色集。配置与流程定义分离的最后一环。

文章目录

• 42-WorkflowConfigService：五类流程配置
• • 一、五类配置一张图
  • 二、BindingForm：节点与表单的绑定
  • 三、FormReadonly：审批人不能改申请内容
  • 四、RoleSet：处理人的四种来源
  • 五、ActPrcday：时限的两种值
  • 六、getInterceptor的复用
  • 七、配置的入口：ProcessConfig.vue

源码：browise-workflow/src/main/java/com/browise/workflow/service/WorkflowConfigService.java（224行） 配置五表：ACT_RE_BINDINGFORM / T_FORM_READONLY / ACT_PRCDAY / TASK_INTERCEPTOR_CONFIG / ROLE_SET(+DETAIL)

一、五类配置一张图

流程定义（BPMN）—— 管流转结构
│
└─ 每个节点（taskDefKey）的外挂配置：
├── BindingForm 这个节点打开什么表单（sqlId指向EA元数据）
├── FormReadonly 表单里哪些字段只读（审批人不能改申请内容）
├── ActPrcday 这个节点几天办结（超时预警）
├── TaskInterceptor 这个节点前后挂什么拦截器（第39篇）
└── RoleSet 这个节点谁有权处理（人员/角色/机构/角色集）

配置的锚点都是“流程key+节点key”——selectByProcessKeyAndTaskDefKey模式贯穿五张表。ProcessController审批时按这个二元组查配置——引擎管流转、配置表管一切业务语义（第35篇分层的展开）。

二、BindingForm：节点与表单的绑定

public List<BindingForm> getBindingForms(String processKey) {
return bindingFormMapper.selectByProcessKey(processKey);
}

BindingForm的核心字段：processKey + taskDefKey + formId（→T_FORM表单定义）+ sqlId（→EA元数据）。

审批界面的组装链——ProcessController.complete的GET侧：

待办列表点开一条任务
→ taskDefKey = "review"
→ getBindingForms(processKey) 过滤 taskDefKey="review"
→ 拿到 formId → FormController 加载 T_FORM 表单定义
→ 拿到 sqlId → EA引擎 describe(sqlId) 字段元数据
→ FormRuntime.vue 渲染表单 + getFormReadonly叠加只读

同一个流程的不同节点绑不同表单——申请节点绑完整编辑表单、复核节点绑简表（关键字段+意见框）、审批节点绑只读详情+意见。一套流程三种视图——视图差异全在配置。

三、FormReadonly：审批人不能改申请内容

public void saveFormReadonly(FormReadonly fr) { ... insert; }
public void deleteFormReadonly(String pid, String taskdefid) {
// 删旧的全部，逐条delete
List<FormReadonly> list = ...selectByPidAndTaskdefid(pid, taskdefid);
for (FormReadonly fr : list) { formReadonlyMapper.deleteById(fr.getId()); }
}

deleteFormReadonly的“先查后逐条删”——不是一条DELETE WHERE的批量SQL——MyBatis-Plus的deleteById单条循环。数据量极小（一个节点几个只读字段）——性能无所谓，写法直白优先。

只读的业务语义——政务审批的铁律：审批人看申请内容但不能改（改了就不是“申请人申报的原件”）。FormReadonly按节点配置粒度——同一个字段申请节点可编辑、复核节点只读、审批节点隐藏——字段权限随流程节点流动。

四、RoleSet：处理人的四种来源

@Transactional
public void saveRoleSet(RoleSet rs, List<String> refIds) {
// 存在则更新主表+删旧明细，不存在则插入
// 明细逐条insert——type="1001"
for (String refId : refIds) {
RoleSetDetail detail = new RoleSetDetail();
detail.setRolesetId(rs.getId());
detail.setRefId(refId);
detail.setType("1001");
roleSetDetailMapper.insert(detail);
}
}

主表+明细的两层结构——RoleSet（流程+节点+code）+ RoleSetDetail（refId列表）。code区分用途，type区分来源——第36篇的OpPerson/OpRole/OpUnit/RoleSet四张表对应四种处理人指定方式：

save的整体重建——更新时删全部旧明细再插新明细（deleteAll+insert）——不做diff合并。配置是低频操作、明细量小——整体重建最简单且不会出现“删漏/插重”的中间态。FormElementService保存表单元素同款策略（第47篇）。

五、ActPrcday：时限的两种值

public List<ActPrcday> getDeadlineConfig(String processKey) {
return actPrcdayMapper.selectByProcessKey(processKey);
}

ActPrcday的语义——某流程某节点的办理天数。两种存法：

• 固定天数——prcday=5（5个工作日）
• 表达式——预留（按业务类型动态）

超时怎么办——第35篇讲过AsyncExecutor关闭（不用引擎定时器）——时限检查是主动轮询：定时任务扫ACT_RU_TASK的创建时间+ActPrcday配置算逾期清单→预警通知（notify模块）。引擎不管时限、配置表+定时任务管——引擎配置为零。

六、getInterceptor的复用

public TaskInterceptorConfig getInterceptor(String key, String taskDefKey) {
return taskInterceptorMapper.selectByKeyAndTaskDefKey(key, taskDefKey);
}

这个查询与InterceptorChainService.executeBefore里的查询完全相同——两处各自调mapper（没有service层互调）。第39篇说过“before/after各查一次”容忍了重复——这里是第三处。小规模下的重复查询不是问题——但说明config查询该有个统一的缓存入口（如果做，三处一起收编）。

七、配置的入口：ProcessConfig.vue

16KB的前端配置页（browise-vue/src/components/workflow/ProcessConfig.vue）——左侧流程树（getProcessTree）+右侧五个Tab（表单绑定/只读/时限/拦截器/处理人）。管理员配置完即生效——没有“发布配置”动作——配置表直接被运行时读取。简单系统的简单哲学：配置即生效，靠操作日志（SYS_OP_LOG）追溯变更。

✅ 亮点：五类配置以“流程key+节点key”为锚的统一模式、BindingForm到EA元数据的表单组装链、字段权限随节点流动的政务语义、RoleSet主表+明细的整体重建策略、时限不走引擎定时器而走配置+轮询。适合做可配置工作流的人。扩展方向：第35篇配置分层、第39篇拦截器、第43篇Spring事件推送。