云程智能体开发平台

摘要： 企业级工作流审批，建议把结构化审批记录存入业务数据库，并把它定义为唯一权威数据；Flowable Comment 可以同步保存一份简化文本，供引擎通用接口和流程轨迹展示。只存 ACT_HI_COMMENT 适合原型和轻量应用，却很难覆盖会签、退回、转办、委托、电子签名、人员快照、数据权限、合规留存和引擎迁移。只存业务库也能工作，但通用 Flowable 管理工具可能看不到意见。最稳妥的方案不是“两边随便存”，而是主次分明的双层模型。 阅读全文

摘要： 先给结论：待办主要查运行时任务，已办主要查历史任务，我发起主要查历史流程实例；在办必须先定义产品口径；抄送我的不是 Flowable OSS 的标准任务类型，最好使用平台扩展表，身份关联只能作为兼容方案。 很多团队一开始会设计五条 SQL，分别查询五个菜单。真正上线后才发现，同一条流程会重复出现、转 阅读全文

摘要： OA工作流系统里的驳回是当前审批人给出否定结论，退回是让已办环节重新办理，撤回是提交人及时收回，撤销是让已经推进甚至生效的结果失效，终止是强制结束流程实例。 阅读全文

摘要： OA系统里的会签、或签解决“多人怎样形成一个审批结论”，加签解决“运行中怎样增加参与人”，转办、委托解决“当前任务责任怎样转移”，传阅、抄送解决“信息怎样触达但不参与审批决策”。 阅读全文

摘要： Flowable 的公开 API 提供 RepositoryService、RuntimeService、TaskService、HistoryService 等服务；Camunda 8 提供 Zeebe 执行、Tasklist、Forms、Identity、Operate 等组件；Activiti 也将自己定位为轻量级 BPMN 2 流程平台。它们解决的是流程定义如何部署、Token 怎样执行、任务怎样创建、事件和定时器怎样触发、历史数据怎样保存。 阅读全文

摘要： 仿钉钉审批设计器是一种受约束的业务 DSL，不是换皮 BPMN；要接 BPMN 引擎，必须建立明确、可测试的语义编译规则。 阅读全文

摘要： 把 BPMN.js 嵌入 Vue 页面后，企业通常会继续增加顶部工具栏、企业节点、节点图标和右键菜单。真正的难点不是“把按钮画出来”，而是让所有入口共享同一套动作、权限、建模规则和撤销机制。 结论可以概括为四句话：顶部业务工具栏由 Vue 实现；Palette、Context Pad 和 Popup Menu 通过 Provider 扩展；节点持久图标使用 Custom Renderer，运行状态使用 Overlay；所有模型写操作进入 Modeling 或 CommandStack，并由 Rules 与后端发布校验共同约束。 阅读全文

摘要： 仿钉钉流程模型转换成 BPMN 2.0，本质上不是 JSON 换成 XML，而是把审批树编译成可执行流程图。 转换器需要先统一节点和分支语义，再生成 User Task、Gateway、Sequence Flow、Event、Extension Elements 与 BPMN DI；会签、或签、条件分支、抄送、超时和空审批人策略都必须有明确映射。最稳妥的方案是保留两层模型：简化审批 DSL 服务业务人员，BPMN 2.0 服务流程引擎和技术治理。两者之间增加“规范化中间模型 + 编译器 + 映射清单”，而不是让前端直接拼接 BPMN XML。 阅读全文

摘要： BPMN.js 属性面板可以配置审批人、按钮、表单和数据权限，但不应该把组织用户、表单结构和权限明细全部塞进 BPMN XML。更稳妥的设计是：模型保存稳定引用与策略，业务服务保存可变目录数据，运行时重新解析并执行授权，必要时保存最小证据快照。 这类扩展真正解决的不是“增加几个输入框”，而是建立一套跨设计器、流程引擎和业务系统都能长期演进的模型协议。实现时应把 Properties Provider、moddle、Vue 业务弹窗、CommandStack、后端校验和运行时解析看成一条完整链路。 阅读全文

摘要： Vue 负责页面与业务交互，BPMN.js 负责标准建模，平台后端负责模型治理，Camunda 只负责部署与执行。四层边界一旦清楚，后续增加审批人、表单、按钮、数据权限和中国特色 OA 能力时，系统才不会被某个前端组件或引擎版本绑死。 阅读全文

摘要： 基于 Flowable、Activiti 等开源内核，自己开发组织、表单、门户、审批动作和运维平台，属于“开源引擎二开”或“自研工作流平台”，不等于“从零自研工作流引擎”。这两个概念混在一起，往往是选型失误的起点。 阅读全文

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

摘要： 如果目标是建设传统中国式 OA 审批平台，并要求私有化部署、Java 深度二开、关系型数据库和可控的引擎扩展，Flowable 通常是更合适的 PoC 起点。它并不直接提供完整的会签、加签、退回和撤回产品，但部署形态与国内 Java 技术栈更贴近，状态变更 API 也较容易被封装成受控的审批操作服务。 Camunda 必须拆成 Camunda 7 和 Camunda 8。Camunda 7 技术形态同样适合传统人工作流，但社区版生命周期使其不再适合作为新项目默认底座；Camunda 8 面向分布式流程编排，适合跨服务、跨语言 Worker 和高可用场景，却通常不是传统 OA 的最短实现路径。 阅读全文

摘要： 以 Flowable 8.0.0、Camunda 7.24 和 Camunda 8.9 为主要版本基线。Flowable 8.0.0 已升级到 Spring Framework 7、Spring Boot 4 和 Jackson 3；Camunda 7 社区版已结束生命周期；Camunda 8 官方则提供了面向特定工作负载的 Benchmark 工具与容量规划方法。 阅读全文

摘要： 从 Activiti 迁移到 Flowable，不能把任务理解为“复制几张 ACT_ 表”。真正的迁移对象是一张有关联的数据图：流程定义、部署资源、执行树、任务、变量、作业、历史、身份、业务单据、表单附件和消息状态共同描述一个流程。 迁移前必须先确认 Activiti 来源版本、目标 Flowable 版本、数据库方言、历史级别、定制扩展和运行实例复杂度。不同版本的可行路线差异很大：有的可以使用官方升级脚本，有的应让旧实例自然跑完，还有的必须按平台迁移重新设计 阅读全文

摘要： Camunda 7 与 Camunda 8 的共同点是 BPMN，差异却贯穿执行内核、事务、编程、存储、查询、运维和许可。Camunda 7 到 8 是架构迁移，不是依赖升级。 存量 Camunda 7 应先治理、解耦和制定退出路线；新建跨服务编排平台可以优先评估 Camunda 8；传统人工审批和低代码 OA 则应从组织、事务、动态审批和二开成本出发，比较包括 Flowable 在内的嵌入式路线。 阅读全文

摘要： Activiti 5、6、7 不是一条“版本越高、替换依赖就越先进”的简单升级线。 Activiti 5 是经典的嵌入式 Java BPMN 引擎；Activiti 6 重写了执行核心；Activiti 7 在 6.x 内核之上增加新的 Runtime API，并把路线延伸到 Spring Boot、消息驱动和 Activiti Cloud。 阅读全文

摘要： 对中国式 OA 和低代码审批，Flowable 通常仍是更均衡的开源底座；已有 Activiti 资产应优先评估加固与渐进迁移；需要跨语言、高吞吐编排时可评估 Camunda 8、Conductor 或 Temporal；规则与流程强耦合可看 Apache KIE/jBPM；Camunda 7 存量系统可以验证 Operaton、CIB seven；LiteFlow 则更适合应用内逻辑链。 阅读全文

摘要： Activiti、Flowable、Camunda 共享 Activiti 5 时代的 Java BPMN 引擎血统，但开源项目从来不只由代码决定。维护团队、目标用户、商业模式和目标负载不同，最终让 Activiti 走向“轻量引擎与云组件探索”，Flowable 走向“面向业务自动化的多引擎开源底座”，Camunda 则从开发者友好的 BPM 平台进一步走向以 Zeebe 为核心的分布式流程编排。 阅读全文

摘要： 新建传统 Java 审批平台、强调 Apache 2.0、国产数据库适配和会签/加签/回退等深度定制，优先评估 Flowable；已有 Activiti 资产且团队能长期维护内核，可以继续演进，但不建议仅凭“历史知名度”用于全新项目；需要高吞吐分布式编排、跨语言 Worker、成熟运维界面和商业支持，并能接受生产许可证与更高运维成本，评估 Camunda 8。Camunda 7 社区版已经结束生命周期，不应再作为新项目基线。 阅读全文