★ FEATURED ARTICLE 驰骋 BPM 节点执行方式的实现与 Flowable / Camunda 对比对照范围工作到达节点后由谁做完、何时继续、失败停在哪、人能不能看见。一侧是驰骋 BPMCCFlow / JFlow的「节点的执行方式」另一侧是 Flowable、Camunda 7、Camunda 8Zeebe的 BPMN 任务和作业模型。实现看CCFlow/Components/BP.WF发送、待办、定时任务和 Vue3 过程执行页BPMN 一侧按公开文档里的 User Task、Service Task、Job Executor、External Task / Job Worker 来写不按营销口径对齐。0. 差异在哪三家都在解决同一件事人工等待与系统继续如何在一条流程里共存。分歧不在「有没有自动节点」而在建模单元和调度哲学。维度驰骋 BPMFlowable / Camunda建模单元同一类节点 「节点的执行方式」枚举不同 BPMN 元素User Task、Service Task、Script Task、External Worker…驱动方式以发送Send为步进执行方式决定下一次发送由谁触发以令牌token到达活动为步进活动类型决定等待还是继续人工隔离机器执行不进普通待办、默认不推到达消息User Task 进 TasklistService Task 本来就不会进人工任务列表系统调度机器扫描待办定时发送过程当次请求内同步连发作业执行器 / Job Worker加锁、重试、事故incidentExternal Task 由外部工人拉取人机兜底混合执行为一等能力打开表单先试发失败留给人无同名一等元素通常拆成网关 自动活动 用户任务或监听器里 Complete工位场景流水线执行独立待办通道无标准元素需自研任务列表与完成 API过程可见业务人员看过程执行页时间轴 / 流程图运维人员看 Cockpit / Operate / 历史活动业务页需自建标准与生态产品内约定学习成本低互换性弱BPMN 2.0 可互换、生态大学习与建模成本高Flowable / Camunda 这边作业可靠性、多语言工人、标准互操作更完整。驰骋这边执行策略挂在同一类节点上过程观测是给业务人员看的不是给运维控制台看的。选型看场景不要按「谁更 BPMN」打分。1. 问题本身执行者是节点类型还是节点属性企业流程里常见五类诉求三家都能做只是落点不同必须由指定人批进待办、可催办、可退回。到点由系统跑不要占人的待办箱。能自动就自动规则挡住再给人。产线工位扫码过站不走审批箱。连续调外部系统人要看见卡在哪一步、返回了什么。Flowable / Camunda 的答案来自 BPMN换一种图元。用户任务是等待态服务任务是自动态同步委托或异步作业定时用中间事件外部系统用 External Task / Job Worker。图上信息量大语义精确实施人员要熟悉规范。驰骋的答案来自属性不换图元改执行方式。设计器仍是同一个节点下拉五种方式。发送引擎、待办表、消息、定时任务、过程页读的是同一列。实施人员改枚举开发人员改事件。两种设计都自洽。前者优化规范表达与引擎内核后者优化中国审批 集成 低代码配置的同一套节点生命周期接收人、方向条件、退回、轨迹仍然在。flowchart LR subgraph BPMN[Flowable / Camunda] U[User Task] S[Service Task] E[External Worker] T[Timer Event] end subgraph CC[驰骋 BPM] N[同一节点] N -- M{节点的执行方式} M -- A0[操作员] M -- A1[机器] M -- A2[混合] M -- A3[流水线] M -- A4[过程] end2. 驰骋五种执行方式如何真正跑起来属性定义在节点上发送生成待办时抄到待办行。运行时调度读待办行而不是每次再解析流程图。这是设计上的关键执行方式是运行时状态延期发送才能把一条人工待办临时改成机器通道到期再发。2.1 操作员执行默认人处理、人发送。进待办可达消息轨迹按人工记录。对照 BPMN 的 User Task语义最接近。差异在产品层驰骋的待办与表单、工具栏、审核组件是一体的Flowable / Camunda 的 TaskService 是引擎 API页面多由业务或 Tasklist 组装。2.2 机器执行待办查询排除机器执行避免系统节点出现在「我的待办」。到达 / 发送成功默认不推消息避免误报「有人等你批」。后台服务扫描「机器 / 混合、未通过、已启用」的待办模拟处理人登录后调用与人工相同的发送。与 Job Executor 的相似处都是把继续流转从用户线程里拿出去。不同处Camunda / Flowable 的作业有锁、排他、重试次数、到期时间、失败事故驰骋这条通道更粗——扫待办、发一次、失败记日志。可靠性模型更简单也更容易和「延期发送」共用人工把待办改成机器执行并写入延期时间到点同一扫描任务发出取消则原子清回人工态。设计合理性复用待办行当作业记录不必再维护一张独立 job 表。代价是作业语义重试退避、事故工作台、优先级队列不如 BPMN 引擎成熟。2.3 混合执行打开工作页时先尝试发送。成功则人已经站在下一节点被方向条件、接收人、阻塞等挡住则静默失败表单留给人。BPMN 里要对等通常是排他网关条件满足走 Service Task否则 User Task或User Task 上监听器自动 Complete或跳过表达式部分产品。图上会变成两个活动。驰骋坚持一个节点两种命运接收人、表单、退回规则不用配两遍。设计合理性贴近「填完就能过、过不了再改」的办公习惯。边界也清楚——试发发生在打开页面不是到达瞬间不适合代替真正的异步作业。2.4 流水线执行待办不进普通审批箱走独立工位接口按节点汇总、按工位列出、按日对账发送可带二维码 / 单据号。BPMN 没有工位图元。落地一般是 User Task 自研扫码页 taskService.complete。引擎不管「这个任务该出现在工位屏还是审批箱」。设计合理性执行方式直接决定任务出现在哪条交互通道而不仅是「谁 complete」。这是产品化不是规范新增。MES / 车间过站值得用普通审批不要滥用。2.5 过程执行连续系统节点在同一次发送请求内同步连发明确不进定时扫描发送完成后 while 下一节点的执行方式 过程执行 且流程未结束 且存在待办: 切换到该待办处理人 以系统身份走完整发送方向条件、接收人、发送前事件仍生效 叠加本次过程返回 切回原操作员上一人工节点若配置「发送后转向」为过程执行页则先打开大窗再并发发送。页面每秒拉轨迹过程 / 人工标签、耗时、外部返回、并行分支超过约一分钟提示外部系统仍在处理。对照 BPMN一串 Service Task 令牌也会自动往前走。差别在事务与观测若 Camunda 7 用同步 JavaDelegate同样可能在一次事务里跑完一串自动活动——官方反而建议asyncBefore/asyncAfter避免长事务与锁。若用异步作业或 Camunda 8 Job Worker每步独立提交崩溃可从作业恢复事故在 Operate 里可见。驰骋过程执行选择同步连发 业务时间轴优化的是「人点一次发送、盯着集成跑完」HTTP 超时、中途宕机、逐步重试不是这条路径的强项。长耗时、需重试的外部调用更适合机器执行定时再发或自建工人而不是无限拉长当次请求。设计合理性过程节点仍是节点——有接收人、有事件、失败停在具体节点——不是跳过引擎的脚本钩子。身份切到待办人再切回审计主体仍是人。这与 BPMN 服务任务「引擎账号执行、活动上常无办理人」不同更符合国内审批留痕习惯。3. Flowable / Camunda任务类型与作业模型对等叙述3.1 元素分工BPMN / 产品扩展职责与驰骋大致对等User Task人工等待TaskService 查询、签收、完成操作员执行Service Task 类 / 表达式引擎内同步调用过程执行中的发送前事件 / 过程同请求Service Task async写入作业Job Executor 续跑机器执行都是异步继续实现粒度不同External TaskCamunda 7/ External WorkerFlowable/ Job WorkerCamunda 8外部进程按主题拉取、加锁、完成或失败无直接一等对等集成多写在事件里由引擎线程或定时发送触发Timer Intermediate Event到点继续延期发送待办改机器通道图上可见性不如定时事件Script / Business Rule Task脚本或决策表无独立图元规则在事件、条件、表单Camunda 8 把「引擎内 JavaDelegate」基本拿掉自动步骤默认是工人模型扩展性、隔离性更好运维模型也更重。驰骋仍把自动步骤留在同一套发送里部署形态更接近传统单体 BPM。3.2 作业执行器在解决什么Flowable / Camunda 7 的异步延续核心不是「自动」而是把一次令牌推进切成可恢复的作业获取作业并加锁防止多节点重复执行。失败写重试与事故人工在 Cockpit 处理。exclusive 避免同一实例并发把数据写乱。驰骋机器执行用待办扫描近似「有活就发」没有同等的作业锁协议。集群下要靠服务部署约定而不是引擎级 job lock。这一点对比必须写明在高并发自动节点与失败恢复上BPMN 作业模型更完整。3.3 外部工人在解决什么External Task 的类比是服务任务也是一种「待办」领取者不是人而是程序。fetchAndLock→ 做事 →complete/failure。工人可多语言、可水平扩展引擎不持有长调用。驰骋过程执行是引擎或应用进程在发送循环里直接调外部 API。耦合高、配置简单、过程页容易把返回贴回节点。工人模式要运维一套消费者事件模式要守住超时与重试。跨语言、长耗时、要独立扩缩的集成用工人模型更合适。配置人员改节点就能串内部系统调用时用驰骋过程执行更合适。两条路的运维成本和失败恢复不一样不要混着用同一套预期去验收。4. 技术细节对照4.1 运行时数据落在哪驰骋Flowable / Camunda 7实例流程实例表ACT_RU_EXECUTION等人工任务待办行含执行方式副本ACT_RU_TASK自动继续仍是待办行机器 / 过程或发送循环栈ACT_RU_JOB/ 外部任务表历史轨迹表历史活动 / 历史作业驰骋让待办表身兼「人工任务」与「自动作业」靠执行方式区分。表更少语义要靠枚举约束。BPMN 把任务与作业分表查询清晰模型更重。延期发送能成立正因为待办行可变执行方式从操作员改为机器参数里带延期时间。BPMN 更标准的做法是图上放 Timer或把作业 due date 设到未来——图与作业表都看得见待办不一定还在。4.2 消息与待办为什么要跟着执行方式走自动步骤若仍发「请审批」类到达消息产品就是错的。驰骋在消息模块对机器执行短路。Flowable / Camunda 通常根本不会给 Service Task 建 Task自然也不会进 Tasklist若在监听器里发业务消息要实施自己区分。两边都合理。驰骋必须显式短路因为机器节点仍然生成待办行只是查询排除BPMN 服务任务往往不生成 User Task。这是「同一套节点生命周期」带来的额外正确性义务不是缺陷但实现上必须守住。4.3 失败停在哪里驰骋过程执行Camunda 同步委托Camunda / Flowable 异步作业 / Worker失败位置当前过程节点返回带「系统执行发送」当前活动事务回滚范围取决于实现作业 / 工人失败实例停在该活动重试需再次发送或人工处理同请求内难自动重试引擎重试 事故人怎么看过程执行页失败态 返回原文异常栈 / 业务自绘Operate / Cockpit过程页把集成报文展示给业务人员这是驰骋有意做的产品层。Cockpit 面向运维。两者不互相替代。4.4 并行驰骋时间轴能解析「并行执行」类节点名过程页展示并行分支。引擎并行仍靠分流 / 合流运行模式与执行方式正交。BPMN 用并行网关 多令牌服务任务可在分支上各自异步。并行作业调度、合流同步是 BPMN 引擎的传统强项。不要把「过程连发」理解成分流连发是同一路径上的同步序列并行是多令牌。配置错了会把长耗时外部调用塞进一次 HTTP。5. 设计合理性各自优化什么各自付出什么5.1 为何驰骋坚持「改属性、不改图元」生命周期复用接收人、方向条件、退回、撤销、轨迹、表单权限都挂在节点上。自动步骤若换成另一种活动类型这些能力要再实现一遍或承认自动步骤是「瘦活动」。驰骋选择自动步骤仍是「胖节点」。低代码配置面一个下拉框比在工具箱里认七八种 BPMN 任务更适合业务实施。通道产品化待办箱、流水线箱、过程大窗是交互通道执行方式是通道开关。BPMN 把通道留给应用。代价不是国际标准工具链、人才、流程文件互换弱作业协议简单过程同步连发有超时上限。5.2 为何 Flowable / Camunda 坚持「换图元、作业可恢复」规范BPMN 2.0 令牌语义、导入导出、培训材料统一。失败域异步作业把外部 IO 移出引擎事务这是十年踩坑后的默认建议。工人模型自动步骤与引擎进程解耦适合微服务与多语言。代价中国式审批退回、加签、抄送、审核意见要在 User Task 上大量扩展「能过则过」要拆图工位、过程时间轴要自建对实施人员的规范门槛高。5.3 不宜互相抄的部分不要要求驰骋用 BPMN 任务类型重做一遍节点工具箱那会拆掉「胖节点」生命周期。不要要求 Camunda 用一个枚举取代 User / Service Task那会拆掉标准与作业模型。过程执行不要当成 Camunda 8 Worker 的替代Worker 不要当成过程页的替代。前者是同步编排 UX后者是异步可靠性。6. 场景怎么选可执行的对照场景更贴驰骋的用法更贴 Flowable / Camunda 的用法部门审批、退回、会签操作员执行User Task 自研审批扩展夜间过账、不占待办机器执行async Service Task 或 Worker打开即过、过不了再填混合执行网关拆分或监听器 Complete图更碎工位扫码流水线执行User Task 自研工位端人点发送后连续调内部 API要盯进度过程执行 过程执行页一串 Service Task 自建进度页要可靠则每步 async跨语言、长耗时、需重试扩缩不宜单靠过程同步连发External Task / Job Worker到点再发已填好的单延期发送改执行方式Timer 事件图上可见混合使用也常见核心审批用驰骋超长集成用独立工人回写后「发送」推进。那是架构组合不是某引擎的失败。7. 容易说满的三处「五种策略共享发送、待办、事件与轨迹」是对的但共享生命周期就要自己处理待办过滤和消息短路。作业锁、重试次数、事故台BPMN 那边更完整这点不要略过。过程执行页让业务人员能看见人机混合轨迹。看见的是当次请求里的同步连发不是分布式工人编排。Flowable / Camunda 的图元和作业模型自动步骤可恢复。跟驰骋比的是引擎内核待办箱、退回加签、工位通道在他们那边多半要产品层自己补。8. 收束节点执行方式不是 BPMN 任务类型的对照表问题切法就不一样Flowable / Camunda 问的是活动是什么类型令牌和作业怎么往前走。驰骋问的是这个节点由谁、按什么节奏执行同一节点进哪条通道。复杂性放的位置不同。前者在规范和作业协议上恢复力和生态更好后者在一个枚举和发送循环上配置面和过程页更直接。实现上可以记成同一节点、五种执行方式、同一套发送。机器靠待办扫描过程靠当次连发混合靠打开试发流水线走工位接口。执行方式同时管待办过滤、消息和轨迹标签。三家都会自动。差别是自动步骤还算不算原来那个节点以及失败之后谁看见、谁重试。
阅读完成 · 觉得有帮助？
