Geejing WebBuilder 与「工作流引擎 + 自研表单」——审批系统为什么总是越做越难改

做审批系统的主流技术方案有两种：一种是引一个成熟的工作流引擎（Activiti、Flowable、Camunda 之类），再自己写业务表单；另一种直接用 geejing WebBuilder 快速开发平台内置的工作流。前者看起来"专业、生态好"，后者看起来"够用"。本篇把两者放在一起对比，重点看开发时与运行一年后这两种视角下的差异——很多决策的代价，只有在二期、三期才浮出水面。

一、组合方案的真实工作流

选"引擎 + 自研表单"路线，项目通常会形成这样的结构：

1. 流程定义：用 BPMN 建模工具画流程图，产出 .bpmn20.xml，部署到引擎；
2. 表单开发：手写每个节点的表单页面（前端组件 + 后端接口 + 数据表）；
3. 业务表：每个审批单据类型一张业务表，外加引擎自带的一大堆 ACT_* 表；
4. 桥接层：写 Java 代码实现 JavaDelegate / TaskListener，把引擎的流程变量与业务数据互相同步；
5. 待办与已办：自己开发待办列表、已办列表、流程追踪页面，对接引擎 API 查询；
6. 权限与用户：把企业组织架构同步进引擎的用户组，或实现引擎的用户查询接口。

这套结构技术上完全可行，很多企业的核心审批系统就这么跑着。它的问题不在"跑不动"，而在每一层都在维护两份真相。

二、两份真相带来的持续成本

成本一：流程变量与业务字段的双写。 引擎需要知道"金额是多少"来做条件路由，业务表里也要存金额。于是每次发起、每次审批后都要同步一遍：引擎侧 runtimeService.setVariable(...)，业务侧 mapper.update(...)。两个地方写错一处，就会出现"流转按 A 金额走了、单据显示 B 金额"这类极难排查的问题。

成本二：表单与流程的错位。 业务流程一变（多一个审批节点、加一个抄送、从串行改并行），表单往往要跟着改——因为新节点可能需要看新字段。但表单是独立工程，改完要重新发版、重新测试。结果是：流程设计师在建模器里画五分钟，研发排期要两周。

成本三：待办与追踪页面的重复实现。 引擎提供了 API，但"我该看到什么"是业务问题：待办要显示单据标题、金额、发起人、停留时长；追踪要画出流转路径与每个节点的处理意见。这些页面每个系统都要重做一遍，且极易与引擎版本升级冲突。

成本四：引擎的表结构侵入。 ACT_RE_*、ACT_RU_*、ACT_HI_* 加起来几十张表进入你自己的库，备份策略、查询性能、版本升级都要一并考虑。想换引擎？成本约等于重写。

三、WebBuilder 的做法：流程与业务"分离但同屋"

WebBuilder 的工作流不是外挂引擎，而是平台的一部分。它的设计取舍非常明确——约定优于配置，把桥接层消灭掉。

一个流程 = 一个目录。 请假流程的文件结构是这样的：

workflow/leave/
├── start-form.xwl      发起表单
├── handle-form.xwl     审批表单
├── before-action.xwl   动作前钩子
├── after-action.xwl    动作后钩子
└── actions.xwl         业务数据服务端

流程定义是 example/leave.flw，业务表只有 wb_leave 一张，靠一个 flow_id 字段与流程实例关联。

表单与流程通过约定接口对接。 表单模块实现 init(flowId, type, record)，引擎按三种形态调用它：

init(flowId, type, record) {
  if (flowId) {
    Wb.ajax({
      url: xpath + '/../actions&xaction=selectLeave',
      params: { flowId }, json: true,
      success(resp) { Wb.setValue(app.main, resp); app.main.show(); }
    });
  } else {
    app.main.show();   // 新建：显示空表单
  }
}

type 为 start 是发起、handle 是审批、view 是查阅——同一个表单模块服务三种视角，不需要写三个页面，也不需要为"审批时要看到什么"另开工程。

动作是方法名，不是 API 调用。 审批表单里的操作直接调用引擎注入的方法：doPass() 通过、doBack(节点) 退回、doTransfer(用户) 转办、doReject() 驳回、doSignBefore(用户) 前加签。业务代码不需要 import 任何引擎包，也不需要处理流程变量同步——引擎自己的表管流程状态，你的表管业务数据，flow_id 是唯一的接口。

业务数据落库挂在钩子里。

afterAction(action, flow) {
  if (flow.restarting) {
    Params.$flow_id = flow.flowId;
    Wb.sync({ tableName: 'wb_leave', update: Params, whereFields: 'flow_id' });
  } else {
    Wb.apply(Params, { sid: Wb.getId(), flow_id: flow.flowId, user_id: flow.handleUser });
    Wb.sync({ tableName: 'wb_leave', insert: Params });
  }
}

restarting 判断处理了"驳回后修改重提"这个实际场景，handleUser 由引擎提供——这些细节如果自研，都是要单独写代码、单独测的。

待办、已办、追踪是平台页面。 平台自带 my/my-flow.xwl 等流程相关页面，不需要每个项目重做一遍。

四、逐项对比

五、辨析：什么时候该用专业引擎

要客观：Activiti/Flowable 这类专业引擎在以下场景仍不可替代——

• 需要复杂网关与子流程编排：并行网关、排他网关、事件子流程、补偿事务等高级建模能力；
• 需要与既有 BPM 平台对接：企业已建统一流程中台，要求所有系统接入同一引擎；
• 需要完整的流程治理能力：流程版本迁移策略、运行时实例的批量管理、审计级的历史追溯。

但如果你的需求是"表单 + 串行/并行审批 + 退回转办加签 + 待办已办"这个国内企业系统里最常见的组合——WebBuilder 的内置工作流覆盖度足够，而且不需要桥接层这一点带来的维护收益是长期的。

一个更实在的判别方法：算一算项目的"审批流种类数"和"表单变更多少次"。种类少、变更少、以表单与数据为主 → 内置工作流更划算；种类多（几十条）、层级深、网关复杂、且企业有流程中台 → 专业引擎更合适。

六、一年后回看：两种方案的分野

把时间轴拉长到上线一年后，两种方案的差异会集中体现在四个问题上：

1. 业务流程调整要找谁？ 专业引擎方案要找流程开发者改 BPMN + 可能改表单 + 走发布流程；WebBuilder 方案通常改 .flw 加表单上的字段，改动范围小、可当天上线。
2. 新来的人多久能看懂？ 专业引擎方案要看 Java 桥接代码 + BPMN 图 + 独立前端工程三处；WebBuilder 方案一个目录五个文件，文件名的语义就是职责分工。
3. 出了流转异常怎么排查？ 专业引擎要在引擎日志、业务日志、数据库 ACT 表之间对照；WebBuilder 的 before-action / after-action 钩子本身就适合挂日志与通知，观察点位置一目了然。
4. 换人维护成本？ 这是最贵的隐性成本。约定清晰的技术栈，交接靠读代码就能完成；而"引擎 API + 桥接层 + 自研表单"的三层结构，交接往往要消耗一两个月的熟悉期。

对比小结

选工作流方案的本质是选一条你愿意长期支付的维护账单。专业引擎买的是"能力的上限"，WebBuilder 买的是"常见场景下的维护下限"。对绝大多数企业内部审批系统而言，后者才是决定项目能不能长期活下去的那个变量。