小单的博客专栏

摘要 本文探讨了Camunda工作流开发中常见的性能优化误区，指出直接使用RuntimeService、TaskService等API进行分散调用会导致大量不必要的SQL查询。关键在于理解Camunda底层通过CommandContext实现的缓存机制：在同一CommandContext中，变量操作可共享内存缓存并批量提交。作者提出最佳实践方案：将业务逻辑封装在自定义Command中，利用高层API操作，既可保持代码可读性，又能享受引擎的缓存优化。文章详细分析了ThreadLocal与CommandCont

是否需要"驳回给发起人"？↓是 → 设计第一个节点为：发起人 UserTask启动流程后自动 complete 该任务支持驳回后重新修改表单提供完整的流程审计记录↓否 → 第一个节点应为：审批人或处理人 UserTask启动流程时直接传入表单数据无额外 complete 操作提升系统性能和吞吐量。

Camunda7 学习路线知识点思维导图 思维导图在文章中展现篇幅不够，每次更新麻烦，以下使用在线链接的方式发布（持续更新） https://www.processon.com/view/link/622da3ba1e085307a23dc108 （END）

Camunda bpm 流程引擎的数据库由多个表组成，表名都以ACT开头，第二部分是说明表用途的两字符标识。Camunda7.11 版本共47张表。 ACT_RE_*: 'RE’表示流程资源存储，这个前缀的表包含了流程定义和流程静态资源（图片，规则等），共5张表。 ACT_RU_*: 'RU’表示流程运行时。 这些运行时的表，包含流程实例，任务，变量，Job等运行中的数据。 Camunda只在流程实例执行过程中保存这些数据，在流程结束时就会删除这些记录， 这样运行时表的数据量最小，可以最快运行。共1

如下图为一个流程图，其需求过程如下： 1、某业务员发起一个登记单 2、领导审批 3、领导选择多个部门进行阅办，每个部门并行进行 4、部门内有两个审批环节（环节一：部门经理或经理助理或签，环节二：部门内的多个主管会签） 5、每个部门各自进行，互不影响，等所有部门都办理完成后进行汇总回档，登记单状态为“已归档” 6、流程结束 特殊场景：在多个部门进行并行阅办的过程中，只要登记单的状态还不是已归档状态，第二个节点的领导，还可以随时增加阅办的部门（从技术的角度来说，只要子流程节点还是活动状态，就可以随时增加子流程活

一、背景 市场上比较有名的开源流程引擎有osworkflow、jbpm、activiti、flowable、camunda。由于jbpm、activiti、flowable这几个流程引擎出现的比较早，国内人用的比较多，大家对camunda流程引擎认识的不多，实际上camunda在功能上、稳定性、性能、轻量化方面均比jbpm、activiti、flowable优秀。中国人使用业务流程，“会签”是一个最常用的流程操作，那么如何基于camunda实现会签流程，会签背后的流程引擎执行原理是什么，笔者希望通过这篇文章