云程智能体开发平台

摘要： EPC 转 BPMN 不能只做图形符号替换。EPC 更偏向业务分析和过程沟通，用“事件—功能—事件”表达业务状态变化；BPMN 同时面向业务沟通、技术设计和流程执行，必须明确令牌怎样流动、谁在等待什么事件、网关怎样分支与汇聚、任务由谁执行。因此，可靠的转换应分为“解析 EPC、构建中间图、识别语义、规整控制流、生成 BPMN、引擎校验、人工复核”七个步骤。 截至 2026 年 8 月，OMG 公布的 BPMN 最新正式规范仍是 BPMN 2.0.2。SAP Signavio 2026 年用户指南仍提供 EPC 到 BPMN 2.0 的自动迁移功能，但官方同时强调 EPC 与 BPMN 并不完全同构，Letter、Email、Fax、Phone、Entity、Form、Resource 等 EPC 元素不能明确映射，转换后应检查并修改。这个提醒非常重要：自动转换适合生成 BPMN 初稿，不应直接把结果发布到 Flowable 生产环境。 阅读全文

摘要： 流程中台不是把 Flowable 独立部署成一个服务，再封装几个启动流程和完成任务的接口。真正的流程中台，是以 Flowable 为执行内核，在其外部建立统一的模型治理、任务服务、组织权限、表单规则、版本发布、业务集成、运行观测和数据审计能力，让多个业务系统用同一套规范接入流程，同时又保持业务数据和流程数据各自独立。截至 2026 年 8 月，Flowable Open Source 8.0.0 已发布。其开源核心提供 BPMN、CMMN、DMN 和事件注册等引擎能力，可以嵌入 Java 应用，也可以作为服务器、集群或云环境中的独立服务运行。但这些能力解决的是“流程如何执行”，并不会自动形成企业级流程资产目录、统一待办门户、组织权限体系或中国式审批产品。 阅读全文

摘要： 在OA系统/工作流系统里，员工离职后，如何批量移交待办任务处理权限和已办任务阅读权限？员工离职交接必须分成两条链路。仍在运行的待办任务，需要把“谁可以继续办理”迁移给接收人；已经完成的任务，则应保留原办理人和原审批轨迹，只给接收人增加受控的阅读授权。前者会改变 Flowable 运行时任务，后者通常应由 OA 或业务系统的权限表承载。对于直接分配给离职员工的待办，Flowable 8 可以通过 `TaskService.setAssignee` 逐项变更办理人；候选人、候选组、委托任务和多实例任务必须按各自语义处理。对于已办任务，不要更新 `ACT_HI_TASKINST.ASSIGNEE_`，也不要把接收人伪装成历史办理人，而应建立“离职交接阅读授权”，保存授权范围、期限、来源批次和审计记录。 阅读全文

摘要： Flowable 中的“LLM 节点”不是 BPMN 2.0 标准元素，也不是 Flowable 开源引擎内置的一种原生节点。企业通常把它建模为服务任务，再通过 Java Delegate、HTTP Task、External Worker 或事件机制调用独立的 AI 网关。Flowable 负责确定性流程、状态持久化、重试与人工任务，大模型负责摘要、分类、抽取、生成和辅助判断。生产环境最推荐“External Worker + AI 网关”模式：流程到达 LLM 服务任务后形成等待状态，独立工作者拉取任务、调用模型、校验结构化结果，再通知 Flowable 继续执行。这样可以隔离模型 SDK、GPU 服务和网络抖动，避免长时间远程调用占用流程引擎事务。Flowable 最新开源版本为 8.0.0。官方文档已经提供 Java Service Task、HTTP Task、External Worker、异步执行器和 Event Registry 等基础能力；Spring AI 2.0.0 则提供统一模型 API、结构化输出、RAG、工具调用和可观测性。 阅读全文

摘要： Flowable 中的“任务到期时间”与“定时器”不是同一件事。任务 `dueDate` 适合展示截止时间、筛选即将超时和统计 SLA，但它不会因为时间到了就自动发送消息或完成任务；真正负责按时触发动作的是 BPMN 定时器事件及其运行时作业。 超时提醒通常使用非中断边界定时器，定时器触发后发送站内信、短信、邮件或企业微信，但原审批任务继续等待。超时预警是在正式截止时间之前触发，可以提醒办理人、部门负责人或流程管理员。超时自动审批则应使用中断边界定时器进入一条明确的自动处理支线，由规则判断是自动通过、自动驳回、转人工还是终止，不能把“超时”简单等同于“同意”。 阅读全文

摘要： 对大多数企业审批、OA 和中后台系统，优先选择“模块化单体 + 嵌入式 Flowable”；当业务边界、团队边界和独立扩缩容需求都已经清晰时，再把流程能力拆成独立服务。微服务不是因为流程数量多就必须采用，也不是把 Flowable REST 单独启动后就自然获得高可用和解耦。截至 2026 年 8 月，Flowable 最新开源版本为 8.0.0。官方说明表明，它既可以嵌入 Java 应用，也可以作为服务运行在服务器、集群或云环境中。Flowable 的服务 API 是无状态的，多个同构节点可以连接同一个流程数据库形成集群；但这种水平扩容仍是一个逻辑流程服务，并不等于按业务域拆分的微服务架构。 阅读全文

摘要： Flowable 连接达梦数据库并不难，难的是把“JDBC 能连通”变成“流程引擎可稳定运行、可升级、可运维”。截至 2026 年 8 月，Flowable 8.0.0 的开源文档和源码没有把达梦列为原生数据库类型，也没有随包提供 `flowable.dm.*.sql`、`dm.properties` 和达梦专用 MyBatis 映射。因此，直接更换 JDBC 驱动并不能宣称已经完成国产数据库适配。 企业通常有两条路线：利用达梦的 Oracle 兼容能力复用 Flowable Oracle 方言，快速建立可用基线；或者增加独立的 DM 数据库类型、建表升级脚本和差异 SQL，形成可长期维护的原生适配。前者改造量较小，但必须逐项验证兼容边界；后者控制力更强，却要持续跟随 Flowable 版本维护。 从私有化部署角度，推荐把适配拆成驱动、识别、方言、DDL、数据类型和验证六层，并在生产关闭自动建表，由 DBA 审核后执行版本化脚本。本文以达梦为例，也适用于人大金仓、openGauss 等国产数据库的适配评估。 阅读全文

摘要： Flowable 历史表越来越大时，真正有效的办法不是先加一条索引，也不是直接执行 `DELETE`。企业需要同时控制历史数据的生成量、修正查询方式、建立分级保留周期，并通过 Flowable 官方历史清理能力小批量回收数据；索引、统计信息和数据库维护则应以慢 SQL 与执行计划为依据。 还要先澄清一个常见误区：历史表变大，并不意味着每一次流程流转都会直接扫描历史表。Flowable 把运行时数据与历史数据分开管理，但历史写入仍会占用数据库事务、日志、缓存和 I/O；历史查询、报表统计以及大批量删除，也会与运行时审批争夺数据库资源。因此，性能治理要从“运行链路是否被历史负载拖累”入手，而不是只看表行数。 本文以 Flowable 8.0.0 为主要版本边界，结合官方历史文档、Housekeeping 文档、建表脚本和清理作业源码，给出一套适合企业私有化部署的治理方案。 阅读全文

摘要： 企业工作流系统（OA）的办理人不能只保存一个姓名或账号。更合理的设计是：流程模型保存“由谁办理”的业务规则，任务到达节点时，再结合流程发起人、当前办理人、业务数据和组织关系，解析出当时真正具备办理资格的用户。 用户、部门、角色、岗位和动态关系不是五种相互替代的选人控件，而是五个不同维度。用户回答“具体是谁”，部门回答“在哪个组织范围”，角色回答“具有什么业务资格”，岗位回答“承担什么组织职务”，动态关系回答“相对于谁、沿哪条组织路径、满足什么条件”。只有把这五个维度拆开，工作流才能适应组织调整、人员兼职和复杂审批关系。 阅读全文

摘要： 工作流系统里催办的本质是“对仍然有效的待办进行触达和升级”，不是替审批人作出结论，也不应该直接推动流程令牌。一个可靠的工作流催办系统，应把 Flowable 的任务到期时间、催办规则、收件人解析、消息模板、四类渠道适配器、重试与审计拆成独立能力，并用 Outbox 和幂等键隔离流程事务与外部消息服务。 阅读全文

摘要： 在 OA 审批和工作流平台里，抄送与传阅都不会改变审批结论，但二者的业务承诺不同。抄送是把流程信息送达相关人，核心状态是“已发送、已查看”；传阅是要求指定人员阅读，核心状态是“待阅、已阅，必要时还要确认或填写阅办意见”。 传阅是否阻塞主流程，不能只根据按钮名称决定。默认情况下，普通传阅应采用非阻塞模式，让审批主线继续运行；只有当后续业务动作必须以指定人员完成阅读确认为前置条件时，才应把它建模为阻塞式签阅任务。换句话说：需要留痕，不等于必须等待；必须等待，也意味着它已经不再是纯通知。 本文以截至 2026 年 8 月最新正式版 Flowable 8.0.0 为技术基线，说明抄送、传阅、签阅的业务语义，分析 IdentityLink、历史任务、多实例用户任务的适用边界，并给出企业级数据模型、查询、幂等和权限设计。 阅读全文

摘要： 在 OA 审批和企业工作流里，转办、委托和工作移交都可能让“另一个人接手任务”，但三者不是同一个按钮的不同叫法。转办是当前任务的责任永久转移；委托是原责任人保留责任、由受托人临时代办；工作移交是人员请假、调岗或离职时，对一批存量工作和未来工作的组织级安排。 技术实现也应分层：单条转办可以重新设置任务办理人；标准委托应使用 owner、assignee 和 delegationState 表达责任与执行的分离；工作移交必须由平台的人员代理规则、批量任务命令、审计和失败补偿共同完成。把三者都实现成 setAssignee，短期看起来简单，长期一定会在责任追溯、待办查询和权限审计上出问题。本文以截至 2026 年 8 月最新正式版 Flowable 8.0.0 为源码基线，说明这三类操作的业务边界、引擎 API、数据模型和企业级实现方式。 阅读全文

摘要： 流程图上的回退线与运行时动态回退不是两种画法，而是两种不同的执行语义。前者把“退回”建模成 BPMN 的正常业务路径：当前任务正常完成，Flowable 计算条件 Sequence Flow，执行沿连线回到目标节点。后者不依赖两节点之间存在连线，而是通过 Change Activity State API 取消当前活动、调整 Execution 树，再从指定目标节点继续执行。 阅读全文

摘要： 工作流中的子流程节点可以驳回到父流程，但必须先判断它是哪一种子流程。嵌入式 SubProcess 与父流程共享同一个流程实例，只是增加了一层 Execution 作用域，可以使用 Flowable 的普通状态变更 API，把子流程内的执行实例移动到外层节点；Call Activity 调用的是独立流程定义，会创建新的子流程实例，必须以子流程实例 ID 为入口，使用 `moveActivityIdToParentActivityId`，由引擎终止子流程实例并把父流程的 Super Execution 移到目标节点。 真正的边界不是“能不能跳”，而是子流程里是否还有并行分支、多实例、边界事件和异步作业。Flowable 8.0.0 源码会校验 Call Activity 子流程实例中的所有活动 Execution 是否都进入迁移池，只迁移一个分支而遗漏其他分支会直接抛出异常，避免删除半个子流程后留下孤儿状态。 阅读全文

摘要： 并行网关中的一个分支驳回后，其他分支没有唯一、自动且普遍正确的处理方式。系统必须先确定这次驳回属于哪一种业务语义：如果只是当前分支补正，其他分支可以继续办理或保留已完成结果；如果任何一个分支驳回都代表本轮审批整体失败，就要取消或收拢同一并行作用域内的全部执行令牌，再整体退回到 Fork 之前；如果其他分支结果仍有效但不允许继续变化，则应冻结未完成任务，让已完成分支停在 Join 等待重审。最危险的做法，是只把驳回分支移动到 Fork 之前，却保留其他分支原有令牌。流程再次经过 Fork 后会重新生成全部分支，旧令牌与新令牌并存，可能造成重复待办、Join 提前通过、流程卡死或重复执行业务动作。 阅读全文

摘要： 在 Camunda 中实现任意节点跳转，不能把运行时表里的当前节点 ID 直接改成目标节点 ID。正确做法取决于产品线：Camunda 7 使用 `RuntimeService.createProcessInstanceModification`，在同一事务中组合“启动目标活动”和“取消源活动实例”；Camunda 8.9 优先使用 `moveElement` 或 `moveElements`，由引擎把终止源元素实例与激活目标元素合并为一次原子修改。真正困难的不是调用一个 API，而是确定要移动哪个运行令牌、目标属于哪个作用域，以及移动后并行网关、多实例、子流程、变量、监听器和业务单据是否仍然一致。因此，任意节点跳转应当被设计成受权限、校验和审计约束的异常修复能力，而不是普通审批按钮。 阅读全文

摘要： 在 Flowable 中实现任意节点跳转，首选官方 `RuntimeService.createChangeActivityStateBuilder()`，而不是修改运行时表，也通常不需要自己编写底层 Command。对普通用户任务，取得当前任务的 `executionId` 后调用 `moveExecutionToActivityId(executionId, targetActivityId).changeState()`，Flowable 会在同一命令事务中取消源节点运行时数据、调整 Execution 树、重建目标作用域，并通过 Agenda 启动目标节点。 但“任意”不等于“随便”。单个任务跳转、多个并行令牌合并、一个令牌拆成多分支、多实例实例退出、嵌入式子流程跨层和 Call Activity 跨流程，必须选择不同 API。 本文以 Flowable 8.0.0 为源码基线。Flowable 8 已切换到 Spring Framework 7、Spring Boot 4 和 Jackson 3，升级旧项目时应先核对运行环境。 阅读全文

摘要： 企业审批系统里的“退回修改”“驳回到指定节点”“管理员纠偏”，最终都会落到一个技术问题：怎样让正在某个活动上的流程实例，离开当前节点并从目标节点重新执行？在 Activiti 9.0.0 中，可以通过 ManagementService.executeCommand(...) 进入引擎命令链，在同一 CommandContext 和事务中完成五件事：校验运行时结构、关闭当前任务、清理边界执行、把 ExecutionEntity.currentFlowElement 指向目标、再通过 Agenda.planContinueProcessOperation(...) 驱动目标节点。不能只改 ACT_RU_EXECUTION.ACT_ID_，也不能把“任意节点”理解为所有 BPMN 结构都能用同一段代码跳。本文以 Activiti 官方仓库 9.0.0 标签为源码基线。示例优先覆盖“同一流程定义、同一作用域、普通单实例用户任务”的生产实现；多实例、并行网关、子流程、事件子流程和调用活动另行说明边界。 阅读全文

摘要： 工作流里的“驳回到上一节点”听起来只有一个目标，真正落到 Flowable 运行时却可能对应三种完全不同的动作：移动一个 Execution、结束整个多实例活动，或者收拢并行网关产生的多条 Execution。若不先识别当前执行树结构，就把所有场景统一写成 moveActivityIdTo，普通流程可能正常，多实例会一次移动多个任务，并行网关则可能留下孤立令牌或制造重复路径。 阅读全文

摘要： Flowable 能提供运行时状态迁移能力，但不会替业务系统定义“中国式审批”的驳回语义。可靠的实现必须同时处理执行树、任务实例、历史活动、审批轮次、业务状态和幂等控制。尤其发生连续驳回时，同一个 activityId 会反复产生新的 taskId；如果仍把流程历史当作一条可以倒序查找的链表，目标节点和轨迹展示很快就会出错。 阅读全文