首页 > 应用开发 > IT综合 > 工作流引擎-节点执行类型-五种执行者-节点的执行方式

节点的执行方式 是驰骋 BPM(CCBPM / CCFlow)节点上的核心属性。它不是简单的「自动 / 人工」开关,而是把 人、机器、混合、流水线、过程五种执行模型,收敛到同一个枚举字段里:设计期配置一次,运行期由引擎自动调度,界面上还能看见过程。
本文依据引擎实现(
BP.WF)、实体映射框架(
BP.En30)以及过程执行页(
ProNodes.vue)整理,说明这项能力为何构成 CCBPM 的差异化特色。
企业流程很少是「人填表、人点发送」的直线。真实场景里,同一次流转往往要同时面对:
| 环节 | 典型诉求 |
|---|---|
| 审批、会签、退回 | 必须由指定人处理,进待办、发消息 |
| 校验、归档、写回业务系统 | 到点就跑,不要占人待办 |
| 打开表单就能过、过不了再给人 | 能自动则自动,不能则人工兜底 |
| 产线扫码、工位流转 | 不走传统待办,按工位批量处理 |
| 连续调用外部 API(许可、Kafka、FTP…) | 到达即连发,人要看见进度与返回 |
多数 BPM 产品会拆成「用户任务 / 服务任务 / 脚本任务 / 定时器」多类节点。CCBPM 的做法不同: 节点形态不变,只改「节点的执行方式」。设计器上仍是同一个节点图形,属性面板上仍是同一个下拉框。低代码人员改枚举,高代码人员改事件,两者共享同一套发送引擎。
这就是面向模式开发的典型切口:能力写在实体属性上,而不是写在另一套节点类型体系里。
属性挂在节点表上,字段即「节点的执行方式」。设计器与节点属性页使用同一套系统枚举:
@0=操作员执行 @1=机器执行 @2=混合执行 @3=流水线执行 @4=过程执行
发送时,引擎把节点上的值抄到当前待办行:
生成接收人待办时:待办.节点的执行方式 = 到达节点.节点的执行方式
因此「节点的执行方式」不是设计期的装饰字段,而是 运行时调度依据。待办查询、定时任务、消息推送、流水线列表、过程连发,读的都是这一列。
flowchart TD
A[节点发送 / 工作到达] --> B{节点的执行方式}
B -->|0 操作员| C[进入人工待办<br/>发到达消息]
B -->|1 机器| D[不进普通待办<br/>不推送到达消息]
D --> E[后台定时任务<br/>按执行方式自动发送]
B -->|2 混合| F[打开表单时尝试自动发送]
F -->|成功| G[直接走到下一节点]
F -->|失败| C
B -->|3 流水线| H[独立工位待办<br/>扫码发送]
B -->|4 过程| I[发送循环内同步连发<br/>系统身份执行发送]
I --> J[过程执行页:时间轴 / 流程图<br/>展示过程返回]
五种模式共用发送主通道,差异只在 何时发、谁来发、给人看什么。
人处理、人发送。工作进入待办,到达可推送消息,轨迹按人工处理记录。这是 BPM 的基本盘,也是另外四种模式的对照基准。
时间轴上标记为
[人工执行]。
节点到达后 不进入操作员待办(待办查询显式排除「机器执行」),也 不推送到达 / 发送成功消息,避免把系统节点误报成「有人等你批」。
后台服务周期扫描执行方式为「机器执行」或「混合执行」、且尚未通过的待办。到期后以该待办人身份登录并自动发送。同一机制还承载 延期发送:人工点「延期发送」时,把当前待办临时改成机器执行并写入延期时间,到点自动发出;取消或立即发送则原子清回人工态。
特色: 自动发送与延期发送共用机器通道,不必再发明一套队列。
打开工作页面时,引擎先尝试发送一次。发送成功则用户已经站在下一节点;发送被业务规则挡住(方向条件、接收人、阻塞模式等),则静默失败、保留当前表单,改由人继续处理。
特色: 能自动则自动,不能自动则人工,同一节点无需拆成「自动节点 + 人工节点」两条线。
面向工位、扫码、批量过站。待办不混入普通审批箱,而走独立的流水线接口:按节点汇总待办数、按工位列出任务、按当日已处理清单对账,发送可带二维码 / 单据号。开始节点还可按草稿规则先落草稿再进入流水。
特色:流程引擎直接服务产线节拍,而不是把车间操作硬塞进「我的待办」。
连续的系统节点在 同一次发送请求内同步连发,不进定时任务(定时扫描明确排除流水线与过程:过程节点由发送时连发)。
引擎逻辑可以概括为:
发送完成后 while 下一节点的执行方式 == 过程执行 且流程未结束 且存在待办: 切换到该待办处理人 以系统身份执行发送 把本次发送前事件 / 过程返回叠加进总消息 切回原操作员
人只点一次「发送」,后面许可申请、并行分发、Kafka、FTP、回写可以一串跑完。某步失败则抛出「系统执行发送」前缀异常,前端过程页展示失败节点与返回。
时间轴上标记为
[过程执行]。
过程节点如果仍弹一句「发送成功」,集成场景几乎不可用——外部系统可能跑几十秒,人不知道卡在哪一步、返回了什么。
CCBPM 用节点属性 发送后转向 接上过程可视化:
| 发送后转向 | 行为 |
|---|---|
| 6 | 发送后弹出过程执行大窗,默认 时间轴 |
| 7 | 同一大窗,默认 流程图 |
交互节奏与引擎连发对齐:
人看到的不再是黑盒自动任务,而是 人机混合轨迹:人工节点显示处理人头像,过程节点显示系统返回与等待时长。这是 CCBPM 把「工作流」做成「可观测过程」的关键一步。
流程设计器把「节点的执行方式」做成一等公民:
低代码侧:改枚举、配接收人、配发送后转向 6/7。 高代码侧:在节点 发送前事件 或 过程 里调外部系统。 两边对接的契约就是节点的执行方式,而不是再发明一种节点类型。
「节点的执行方式」能从「一个整数」长成整套产品能力,靠的是 CCBPM 的实体映射框架,而不是散落的 if-else 配置文件。
实体映射把该字段登记为:
前后端实体镜像:同一张节点表。属性面板、设计器右键、运行时读取的是同一元数据。
定时自动执行则复用可管理的自动任务,与逾期、消息、同步等任务并列。 配置、存储、调度、界面同源——这是面向模式开发相对「表单 + 脚本」通用低代码的门槛所在。
同一属性在多个子系统上保持语义一致,避免「自动节点还在待办里催办」这类产品级漏洞。
| 子系统 | 对节点的执行方式的处理 |
|---|---|
| 待办列表 | 排除机器执行,人不被系统节点打扰 |
| 消息推送 | 到达节点为机器执行时,跳过工作到达 / 发送成功推送 |
| 轨迹 / 时间轴 | 过程节点标
[过程执行],人工节点标
[人工执行] |
| 节点事件 | 过程连发仍走完整发送,发送前事件、方向条件、接收人规则全部生效 |
| 延期发送 | 复用机器通道 + 延期时间,到点由同一定时任务发出 |
| 身份切换 | 过程连发按待办人登录,结束后切回原操作员,审计主体清晰 |
过程节点不是「跳过引擎」的脚本钩子,而是 仍受接收人、方向条件、阻塞、事件约束的系统执行者。外部 API 失败可以按节点停下,而不是整条流程无声丢失。
跨系统编排(过程执行) 一次人工发送后,连续节点分别申请许可、向并行系统分发、写 Kafka、回写 FTP。过程执行页时间轴按节点展示耗时与 JSON 返回,失败停在具体过程节点。
夜间批量过账(机器执行) 归档、生成凭证、同步主数据放在机器节点,由服务扫描发送,白天待办箱保持干净。
能过则过(混合执行) 表单完整且规则满足时打开即走;缺附件或条件不成立时停留给操作员。一个节点覆盖两种命运。
工位扫码(流水线执行) 同一工位处理同一节点的多件任务,按二维码发送,按日统计已过站数量。
定时再发(延期发送) 人先填完,约定小时后再发。待办临时变为机器态,到期自动进入后续人工或过程节点。
这些场景不需要五套引擎,只需要五种节点的执行方式。
节点属性 → 待办行 → 定时任务 / 发送循环 / 流水线接口 / 前端标签,语义不漂移。
操作员、机器、混合、流水线、过程并列,而不是在用户任务旁边外挂「自动步骤」。
连发不是后台黑盒。发送后转向 6/7 + 过程执行页把执行中、停留、失败、耗时、API 返回摊在时间轴和流程图上。
机器执行同时服务「节点自动发送」和「延期发送」,调度、身份、原子清标记都在同一条链上。
枚举属性 + 同一套发送。扩展新执行者主要是加枚举值与一条调度策略,而不是复制一套节点运行时。
设计器右键改节点的执行方式;事件与过程承接外部系统。集成复杂度留在过程节点里,主流程图形仍然可读。
节点的执行方式,表面是节点上的一个下拉框,背后是 CCBPM 对「工作到底由谁做完」这个问题的产品化回答:
人可以批,机器可以跑,打开可以试,工位可以扫,过程可以连发——并且人能看见。
把五种执行者收进同一属性、同一发送引擎、同一套实体映射,再配上过程时间轴,这是驰骋 BPM 区别于「只会画人工审批链」的工作流工具的关键能力。实施时改的是枚举,运行时调度的是引擎,用户看到的是过程。属性即能力,模式即产品。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/70051390/viewspace-3183901/ ,如需转载,请注明出处,否则将追究法律责任。