为什么开源流程引擎能跑 BPMN，却不能直接成为一套 OA？

Activiti、Flowable、Camunda 等开源流程引擎可以解析 BPMN、推进流程实例、创建任务并记录历史，但这些能力仍然只是 OA 的“执行内核”。用户真正使用的 OA，还要解决组织找人、电子表单、统一待办、移动审批、会签加签、消息触达、数据权限、审计归档和流程运营。

因此，“引擎能够运行请假流程”与“企业拥有一套可上线的 OA”之间，并不是几个页面的距离，而是一整个平台能力层。本文用最短路径讲清二者的边界，以及企业从开源引擎建设 OA 时应该复用什么、自研什么。

一、先给结论：流程引擎是内核，不是完整产品

BPMN 解决的是流程的标准表达和执行问题。它可以描述开始事件、用户任务、网关、定时器和结束事件，却不会替企业决定：

• 谁是“申请人所在部门的分管领导”；
• 会签达到什么比例才算通过；
• 退回后回到哪一节点，已经审批的人是否重审；
• 表单哪些字段可见、可编辑或必填；
• 待办如何同时出现在 PC、移动端和企业工作台；
• 撤回、加签、转办后如何留痕并通知相关人员；
• 业务数据与流程状态不一致时如何补偿和对账。

开源引擎提供的是编程构件。OA 则必须把这些构件组织成普通员工能够理解、管理员能够配置、审计人员能够追溯的产品。

二、引擎与 OA 的能力边界

图 1　引擎负责流程执行原语，OA 平台负责组织、表单、协同和治理。

流程引擎通常提供以下能力：

• 流程定义部署、版本和挂起；
• 流程实例、变量、任务和执行路径；
• User Task、Service Task、Gateway、Event、Timer、Job；
• 候选人、候选组、领取、完成和委托等基础操作；
• 运行时、历史、管理 API，以及失败任务重试。

这些能力已经足够强大，但仍然是技术原语。例如 TaskService.complete() 只表示完成任务，无法决定页面按钮应该叫“同意”“确认归档”还是“退回修改”；候选组也只是标识，不能自动理解企业实时变化的部门、岗位、兼岗和汇报关系。

问题	流程引擎通常回答	OA 必须继续回答
谁来处理	assignee、candidate user/group	按组织规则动态找人、去重、兜底、代理
处理什么	task、variables	表单版本、字段权限、附件、意见、业务主键
如何处理	claim、complete、delegate	同意、驳回、回退、加签、转办、撤回
去哪里处理	Task API	统一待办、门户、移动端、第三方工作台
如何追溯	引擎历史表	业务审计、签名、意见、消息和跨系统链路

三、一个 User Task 距离“审批待办”还有多远

图 2　用户看到的一条待办，是多项平台服务围绕引擎任务协作的结果。

一个用户任务真正出现在审批人的手机上，至少要经过六步：

1. 组织服务根据发起人、部门、岗位和规则解析候选人；
2. 引擎创建 User Task，平台写入业务主键和摘要；
3. 待办服务把任务投递到门户、移动端或第三方工作台；
4. 表单服务加载正确版本，并计算字段与按钮权限；
5. 用户提交意见、附件和签名，平台校验后调用引擎命令；
6. 引擎推进流程，平台同步消息、审计、业务状态与后续待办。

引擎主要负责第二步和第五步中的流程状态变化。其他步骤共同决定了用户体验、组织制度和生产可靠性，这也是 OA 平台的主要工程量。

四、OA 必须补齐的四类能力

原文列出的十条鸿沟，可以压缩为四个建设域。

1. 组织身份与数据权限

真实组织不是简单的用户表和部门表。企业存在多级组织、虚拟团队、兼岗、代理、上下级汇报、分管领导、区域负责人和人员调动。流程找人规则必须支持：

• 发起人本人、直属领导、逐级领导；
• 本部门或上级部门的指定岗位；
• 角色、岗位、人员、表达式和业务数据组合；
• 候选人为空时的兜底与异常处理；
• 同一人多身份命中时去重；
• 运行中的人员离职、调岗和委托。

任务权限只说明“谁能完成当前任务”，OA 还要控制谁能查看单据、附件、审批意见和流程轨迹，以及管理员能否代办、撤销或迁移实例。

2. 电子表单与业务事务

流程变量不是电子表单。表单还涉及布局、控件、校验、明细表、公式、附件、签名、打印、版本和字段权限。平台至少要区分：

• 业务数据库中的权威单据；
• 流程引擎中的路由变量；
• 表单定义与表单版本；
• 每个节点的可见、可编辑、必填和脱敏规则。

不要把整张业务表单无差别塞进引擎变量。更稳妥的方式是以业务主键贯穿流程，在引擎中只保留路由所需变量和快照字段。

3. 中国式审批操作

会签、或签、加签、减签、回退、跳转、撤回、转办、委托、传阅和催办并非一个通用 API 能解决。每个操作都必须定义允许条件、目标范围、任务变化、流程状态、业务状态、消息和审计。

4. 协同入口与治理运营

任务查询接口不等于统一待办。OA 还要聚合不同应用和引擎的任务，支持 PC、App、H5、企业微信或钉钉工作台，并处理未读数、角标、深链、消息去重和超时提醒。

同时还要补齐模型评审、分环境发布、版本回滚、实例迁移、归档、灾备、流程耗时、节点瓶颈、超时率和人员负载等治理能力。

五、中国式审批操作为什么不能只改引擎状态

常见误区是直接删除任务、修改执行表或调用跳转命令，却没有同步业务和审计。可靠的审批操作应由统一领域服务封装。

操作	必须明确的核心语义	主要风险
会签	参与人集合、完成条件、动态增减人	重复计票、比例变化、并发提交
加签	前加签/后加签、串行/并行、原任务是否保留	任务孤儿、路径不可解释
回退	退回目标、已办节点是否重审、变量如何恢复	历史与当前状态不一致
跳转	允许源和目标、补偿动作、后续路径	绕过必要审批和业务校验
撤回	发起人权限、目标状态、下游任务如何处理	已产生外部副作用无法回滚
转办/委托	责任人变化、原处理人权限、何时归还	责任归属与审计不清

一次审批操作至少应经过“权限判断、业务校验、引擎命令、领域事件、消息投递、审计落库”六个环节。对外只暴露稳定的业务动作接口，业务页面不要直接操作引擎运行表。

submitAction(
  businessKey,
  taskId,
  actionCode,
  targetUsers,
  comment,
  idempotencyKey
)

服务端根据 actionCode 决定引擎命令和业务副作用，并把最终结果转换成用户能理解的状态。

六、一套完整 OA 的参考架构

图 3　OA 是从多端入口到执行内核、数据和运维的一整套平台。

完整 OA 可以分为五层：

1. 多端入口：PC 门户、App/H5、企业工作台和开放 API；
2. 协同产品：流程中心、统一待办、表单、消息、附件和流程分析；
3. 平台服务：组织身份、权限租户、审批操作、审计与集成；
4. 执行内核：BPMN、规则、作业、定时器、事件和引擎适配层；
5. 数据与基础设施：数据库、缓存、消息队列、对象存储、搜索和可观测性。

架构中的每一层都有独立产品责任。流程引擎应该被包在稳定的领域 API 后面，业务应用通过业务主键、审批动作和领域事件与它协作，而不是直接查询引擎内部表。

七、业务事务与流程事务怎样保持一致

OA 常见故障不是流程跑不动，而是“单据显示已提交，流程却没有启动”或“流程已通过，业务状态仍是审批中”。本地业务事务与远程引擎调用不一定处于同一个数据库事务中，因此要设计明确的一致性策略。

推荐做法是：

1. 业务库先保存单据和待执行命令；
2. 通过本地消息表或事务消息异步调用流程服务；
3. 流程服务使用业务键和幂等键避免重复启动或重复完成；
4. 成功后发布领域事件，业务侧更新最终状态；
5. 超时进入未知状态，通过业务键、实例 ID 和操作日志对账；
6. 对外部系统副作用设计补偿，而不是假设能够数据库回滚。

同时建立三本账：业务单据、流程实例、审批操作日志。三者都保存稳定业务主键，才能进行故障恢复、审计和数据修复。

八、应该复用哪些能力，自研哪些能力

企业既不应重写成熟的 BPMN 执行器，也不应误以为接入开源引擎后只剩页面开发。

能力	推荐策略	原因
BPMN 解析、执行、作业和定时器	复用成熟引擎	标准复杂，涉及并发、事务、重试和持久化
组织找人与企业身份	平台自建或集成 IAM	高度依赖本地组织制度
会签、加签、回退等审批操作	平台领域化封装	语义、权限、审计和体验差异大
表单与业务数据	低代码平台复用或自建	决定应用交付效率
门户、移动端和消息	平台化建设	需要统一入口与跨应用聚合
审计、归档和流程分析	按行业要求建设	合规周期和运营指标不同
引擎适配层	建议自建	隔离版本、API 与表结构变化

引擎适配层应提供“启动业务流程、查询业务待办、提交审批动作、计算允许操作、获取流程轨迹、管理模型版本、发布流程事件”等领域接口。它不是为了隐藏所有引擎差异，而是把差异集中在可测试、可替换的位置。

九、从当前项目看“引擎之上”的真实建设量

当前项目已经包含大量引擎之外的 OA 能力：

• 加签并完成、传阅、退回、跳转、委托、转办、催办和撤销等流程操作；
• 待办、待阅、已办、委托任务和任务权限校验；
• 独立组织接口提供人员与组织关系；
• PC 与移动端电子表单加载和数据处理；
• 门户配置、个人门户、我的待办控件和移动门户设计；
• 移动端待办数量与审批入口；
• 流程定义、实例、任务、耗时、积压和超时分析；
• 通过消息队列发布流程与任务数据。

这些模块不是重复制造流程引擎，而是在建设引擎与 OA 产品之间的平台层。云程低代码开发平台进一步把流程、表单、门户、移动端和组织能力组合起来，使 BPMN 模型能够成为可配置业务应用的一部分。

从现有代码继续演进时，关键不是增加更多引擎原生 API，而是统一业务主键、审批动作、权限判定、事件模型和审计格式，逐步消除业务页面对引擎内部表和私有命令的直接依赖。

十、从开源引擎到可用 OA 的建设路线

图 4　先保证执行可靠，再建设审批域和多端协同，最后完善治理运营。

1. 第一阶段：把引擎变成可靠服务

完成流程部署、业务主键、任务 API、作业重试、幂等、监控和自动化测试。此阶段的目标不是丰富页面，而是让流程服务可恢复、可对账。

2. 第二阶段：建立 OA 核心域

建设组织找人、表单数据、按钮与字段权限、意见附件、审批操作和操作审计。所有动态操作必须有权限规则和可回归测试。

3. 第三阶段：完善多端协同

建立统一待办、PC 与移动端入口、消息中心、第三方工作台和深链。不同入口看到的任务状态、可用按钮和未读数必须一致。

4. 第四阶段：企业治理与运营

补齐模型评审、版本发布、迁移、归档、数据权限、灾备、安全、流程分析和生态集成。流程平台开始从“功能可用”走向“长期可运营”。

十一、选型和验收应该看什么

选引擎时，应关注 BPMN 覆盖、事务模型、作业机制、历史数据、扩展方式、升级路线、可观测性和私有化部署边界；选平台时，则要检查组织、表单、审批动作、统一待办、权限、审计和运维。

上线前至少确认：

• 组织变化、代理和候选人为空都有处理策略；
• 表单版本与流程版本可以追溯；
• 会签、加签、回退、跳转和撤回语义明确；
• 所有审批动作都有权限、幂等和审计；
• 业务主键贯穿业务、流程和操作日志；
• PC、移动端和第三方工作台状态一致；
• 消息可去重、可重试、可补发；
• 引擎故障后能够恢复、对账和补偿；
• 模型发布、回滚和实例迁移是受控操作；
• 不直接修改引擎运行表，不让业务模块散落原生 API；
• 流程耗时、积压、超时和失败作业可观测；
• 权限、安全、归档和灾备满足行业要求。

不要再问“这个引擎有没有 OA 功能”，而应该分别验证引擎层、平台层和产品层。一个带任务列表的引擎仍可能不是 OA；一套体验完整的 OA 也可能通过适配层更换底层引擎。

十二、最终结论：引擎决定下限，平台决定上限

流程引擎决定 BPMN 是否能正确执行、任务能否可靠推进、定时器和作业能否恢复，这是 OA 的技术下限。

平台层决定组织制度如何落地、审批动作是否可控、业务和流程是否一致、权限与审计是否完整；产品层决定员工是否愿意用、管理员能否配置、运维人员能否治理。这些能力共同决定 OA 的上限。

最合理的建设方式不是从零自研流程内核，也不是把开源引擎包装几个页面就宣布完成，而是：复用成熟引擎，建立稳定适配层，自建企业审批域，再用表单、门户、移动端、消息和治理能力组成完整 OA。