RuoYi Office 工作流前端实现：BPMN 与 SIMPLE 双设计器如何落到 Flowable，业务单据怎样嵌进审批

🌐 演示地址：http://ruoyioffice.com | 📦 源码1·GitHub：ruoyi-office | 📦 源码2·GitCode：ruoyi-office | 📦 源码3·Gitee：ruoyi-office | 💬 微信：17156169080（备注「RuoYi Office」）

很多团队一提工作流就只想到「Flowable 引擎好不好用」，却忽略真正决定交付效率的是前端怎么画、怎么发、怎么嵌业务单。RuoYi Office 在 PC 管理端（Vue3 + Vben Admin）上同时提供 BPMN 标准设计器与 SIMPLE 简单流程设计器，运行时统一落到 Flowable；业务侧再用 CUSTOM 路径 + FlowBill 把用印、请假、资产领用等单据嵌进同一套待办详情。本文按「技术栈 → 双模式差异 → 编译路径 → 单据集成 → 详情运行时」拆开讲。

▲ 全景配色对齐平台架构图：蓝=BPMN、绿=SIMPLE、青=运行时 UI；底层统一 Spring Boot + Flowable

引言：工作流前端要解决三件事

RuoYi Office 的答案不是「二选一设计器」，而是 双模式共存：默认给业务同学用 SIMPLE；需要复杂网关、监听器、标准 BPMN 图元时切 BPMN。

一、技术栈与工程落点

模式切换入口在模型向导「流程设计」步：process-design.vue 按 modelData.type 挂载 BpmModelEditor 或 SimpleModelDesign。

<templatev-if="modelData.type === BpmModelType.BPMN">  <BpmModelEditor... @success="handleDesignSuccess" /></template><templatev-else>  <SimpleModelDesign...ref="simpleDesign" /></template>

保存时：BPMN 成功回调写入 bpmnXml；SIMPLE 写入 simpleModel（JSON）。

▲ 流程模型是双设计器的统一入口：创建/修改时选择类型，再进入对应画布

二、BPMN 模式：标准图元，直接出 XML

2.1 能做什么

• 标准 BPMN 2.0 元素：用户任务、网关、事件、子流程等
• Flowable 扩展：候选人、多实例、监听器、表单键等（属性面板二次封装）
• 适合：复杂分支、包容/并行精细控制、与外部 BPMN 工具互通、专家建模

2.2 编译路径

前端画布导出 BPMN XML → 后端 saveModel 写入流程模型仓库 → 部署后成为 ProcessDefinition。没有「先 JSON 再转」的中间层——所见即 XML。

2.3 代价

学习曲线陡：业务同学容易配错网关方向、漏画连线。属性面板字段多，培训成本高于 SIMPLE。

三、SIMPLE 模式：业务友好，JSON 再编译

3.1 能做什么

节点类型覆盖常见审批场景（枚举 BpmSimpleModelNodeTypeEnum），例如：

• 发起人 / 审批人 / 抄送人 / 办理人
• 条件分支 / 并行 / 包容 / 路由
• 延迟、触发器、子流程

右侧配置抽屉可配：候选人策略、多人审批（依次/会签/或签）、超时、驳回、字段权限等——用业务语言，而不是 BPMN 术语。

▲ SIMPLE 右侧面板：审批人策略与多人审批方式等，配置后编译进 Flowable 多实例/边界事件

3.2 编译路径

simpleModel (JSON)  → SimpleModelUtils.buildBpmnModel(...)    → Flowable BpmnModel      → 生成 XML + 自动布局        → 与 BPMN 模式一样部署进引擎

运行时还可基于 SIMPLE 结构做节点预测（simulateProcess 一类能力），时间轴展示更贴近「钉钉审批链」体验。

3.3 默认为什么是 SIMPLE？

模型创建默认 type = SIMPLE：大多数 OA/HRM 单据是「发起 → 若干审批 → 结束」，SIMPLE 交付更快；真要上复杂编排再改类型或重建 BPMN 模型。

四、BPMN vs SIMPLE：一张表说清差异

选型建议：

1. 80% 业务审批单 → SIMPLE
2. 需要「按金额走不同网关 + 服务任务」→ BPMN
3. 同一业务尽量固定一种类型，避免运营时两边各改一版导致认知分裂

五、表单双轨：NORMAL 与 CUSTOM

流程模型还要绑「表单从哪来」：

CUSTOM 是单据集成的关键：用印申请、资产领用等不是在流程表单里拖几百个字段，而是跳到业务 info 页发起，审批时再把同一业务组件嵌进详情。

▲ NORMAL 表单可在「流程表单」里维护；CUSTOM 则指向业务模块路由/组件

六、业务单据如何集成（三角对齐）

把一张业务单接到工作流，通常要对齐三件事：

6.1 processDefinitionKey ↔ 单据类型枚举

例如用印、补卡、资产入库各自有固定 process key（如 hr_card_replacement_bill）。前端发起与后端 FlowBillServiceFactory.getServiceByProcessKey 都靠它找实现。

6.2 FlowBillService 生命周期

业务 Service 实现统一接口，引擎回调时：

• updateProcessStatus
  ：同步审批中/通过/驳回等
• onProcessApproved
   / 拒绝 / 撤回：写业务副作用（建卡、回写打卡、改库存…）
• 删除实例时清理单据（按模块实现）

前端不直接改业务终态——按钮调的是任务 API，终态靠回调，避免双写不一致。

6.3 发起人自选审批人

当节点候选人策略为「发起人自选」时，发起页收集：

startUserSelectAssignees: Record<nodeId, userId[]>

随 createProcessInstance 变量提交，引擎按节点 id 注入候选人。SIMPLE 与 BPMN 都能配该策略；前端发起页要能按模型解析哪些节点需要自选。

▲ 发起入口：选流程定义后，NORMAL 填表单 / CUSTOM 跳业务创建页

七、审批详情：一套壳，两种图，嵌业务

processInstance/detail/index.vue 是运行时中枢：

1. 拉审批详情（任务、权限、活动节点）
2. 若 CUSTOM：用 businessKey 当单据 id，registerComponent(formCustomViewPath) 动态加载业务详情
3. 注入 isApproval、字段权限、活动节点给业务组件
4. 底部 operation-button：通过 / 拒绝 / 退回 / 加签 / 转办 / 抄送…
5. 轨迹区：按模型类型挂 simple-bpm-viewer 或 bpm-viewer

待办列表 → todo-detail?id=&taskId=  → 左/中：业务表单（NORMAL 或 CUSTOM 组件）  → 右/下：流程图 + 审批记录  → 底：操作按钮（权限由引擎与模型按钮配置决定）

▲ 待办是员工主入口；点进去才是「业务单 + 流程壳」的完整详情

字段权限（可写/只读/隐藏）在 SIMPLE 审批节点可配 businessFieldsPermission，详情渲染时落到业务表单——这是 CUSTOM 单据「同一套页面、审批态只读部分字段」的前端基础。

八、端到端推荐体验

在线演示：http://ruoyioffice.com/web/（账号 admin / admin123）

1. 流程模型
   ：打开列表，新建或编辑一个 SIMPLE 模型，看节点抽屉配置。
2. 再找一个 BPMN 类型模型（或改类型）对比画布差异。
3. 发起流程
   ：走一笔 OA/HRM 业务单（CUSTOM），观察是否跳业务页。
4. 待办
   ：另一账号审批，看详情是否嵌业务表单、轨迹图是否与类型匹配。
5. （可选）同一单据看 NORMAL 流程表单流程，对比体验。

源码仓库：GitHub | GitCode | Gitee

常见问题（FAQ）

SIMPLE 和 BPMN 能来回改类型吗？

类型切换意味着设计器数据源切换（simpleModel vs bpmnXml）。实务上视为「换一套图」，不要指望无损互转；重要流程变更应回归测试部署版本。

业务单据必须走 CUSTOM 吗？

字段少、无复杂主子表，可用 NORMAL 快速上线。主子表、附件、领域校验多，CUSTOM + FlowBill 更稳。

前端要直接调 Flowable REST 吗？

不要。统一走本系统 /admin-api/bpm/**，由服务端封装引擎，便于权限、租户、FlowBill 回调一致。

移动端设计器一样吗？

移动端侧重待办办理与轻发起；双设计器在 PC。App/H5 与 PC 共用同一 process key 与任务 API。

和「多人审批 / 超时 / 抄送」文什么关系？

那些是节点能力；本文是承载这些能力的前端骨架（画在哪、存在哪、详情怎么嵌）。

结语

工作流前端的核心不是「再包一层漂亮流程图」，而是：给业务一条低门槛的 SIMPLE 路，给专家一条标准 BPMN 路，两者编译进同一引擎；再用 CUSTOM + FlowBill 把真实单据嵌进发起与审批详情。 配色与三端架构图一致——设计器可以分蓝绿两路，底座始终是那条蓝色的 Spring Boot + Flowable。

你们团队现在是全员 BPMN，还是已经默认 SIMPLE？单据集成卡在「跳转发起」还是「详情嵌组件」？欢迎评论区交流。

💡 想要体验 RuoYi Office 的强大功能？

🌐 在线演示：http://ruoyioffice.com/web/（账号 admin / admin123）

📦 源码仓库：GitHub | GitCode | Gitee

💬 技术咨询：添加微信 17156169080，备注「RuoYi Office」

⭐ 如果觉得不错，请给个 Star 支持一下！