工作流在我们日常的工作中用得可谓相当普及，尤其在企业内部管理系统，如考勤、财务、合同等系统中更是离不开它。在我们金融科技领域，工作流主要用于贷款审批、风控审核等环节。早期工作流在企业信息化发挥着很重要的作用，随着信息化的初步完成，工作流核心技术也为国内很多大一点的系统集成的公司所掌握。比如我们合作过的宇信、神码、浪潮、企源等传统IT公司都拥有自主产权的的工作流框架。由于工作流具有一定的门槛，国内尚没有能满足企业级应用的工作流开源框架，一些国内CMS开源项目号称支持的工作流也只是对Activiti的简单引入或者是较简单的工作流实现，还不能完整的满足一般企业应用。
Activiti是目前最热门的开源工作流框架，但是由于中西方文化差异及组织架构上的不同，拿Activiti来做中国式的企业级应用难度很高，需要做大量的改造。这里记录下常见的思考点及解决思路，实际碰到的问题会更多且更复杂。
1、待办已办在Activiti相关API中是面向任务的，需求是面向流程的
比如，如下图的需求
在Activit中一个流程是有多个Task组成，而我们中国式的审批需求是一个流程只允许出现一次，哪怕这个流程你在审批过程中参与过两次以上的审批任务，也仅需要显示一次。
这里就需要将TaskService查询出来的任务再按流程实例ID进行去重，去重后任务查询api的分页会变得不可用，对待办和已办未完结来说还好，一般来说数据量不会太大的情况下可以用假分页技术在内存中进行分页。办结因为历史数据的积累会越积越多，不适合用假分页技术了，这时该怎么办呢？我们的做法是添加PROCESS_COMPLATE事件监听，在流程结束后，将这个流程及审批参与人全部记录到某张表。分页查询时先从这张表按页查出流程，再调用Activiti的API进行字段补全查询。
2、运行时动态增加或删除节点
中国式的审批场景中经常会发生在运行过程中动态增加或删除节点的情况，比如领导一时兴起就想将这个任务给某人会签一下（虽说这完全不符合BPMN规范但确实也是广泛存在的需求），但你在设计这个用户任务时是定义成了单人任务，如果将所有任务一开始就定义成多人任务，成本又太高了。很遗憾的是这个是Activiti无法做到的，也不太建议你为此对Activiti进行hack实现，
Activiti中流程是流程定义的一个运行实例，流程一旦生成，节点是"静态地"按定义生成的并不能动态的增删，这与很多国产的工作流不同。这点上只能尽量管理好客户需求了。
3、流程标题和发起人很重要
流程标题和发起人在中国式的审批需求中极度重要，标题一般还需要做成能默认生成且能自定义的，在Activiti中，需要用变量来支持，在流程启动时增加两个变量，如applyUserId和title。
4、重要的双向映射
审批总是和业务关联的，比如一个贷款审批流程会映射一个贷款申请编号，从贷款申请能找到流程，从流程还需要能找到贷款申请。通常会在业务表里增加一个流程实例ID字段，而在启动流程时指定businessKey为businessTable+":"+businessId，这样就建立了双向的映射。
5、签收
Acviti中有个概念叫签收，签收一般用来处理团队的任务，比如财务岗有三个人，用户组任务出现在三人的待办中，任一人通过claim方法将任务签收后再进行处理，签收后任务将从其他二人的待办中删除。如果不想暴露签收的概念，也可以签收和办理同时进行，即先调claim方法，再complate，但要注意可能存在的并发审批的问题。
6、用户和用户组
Activiti中的用户和用户组需要和系统的用户和角色进行同步，用户与系统的用户使用用户名关联，用户组与角色使用角色编码关联。角色分两类：系统角色和工作流角色，系统角色是从系统使用权限的角度来分的，而工作流角色是从工作流审批的角度来看的。为了更方便区分这两类角色不发生混用的情况，工作流角色命名都以：工作流_开头。比如：工作流_公司董事长，工作流_公司财务。
7、退回
需求如下图：
中国式的审批场景中经常会要求退回到仍一节点的需求，比如你当前在第四个审批节点，需要能退回第一、二、三任一节点。相信我，如果你敢用流程设计时画多条线的方式来设计的话保证流程会设计得相当复杂。Activiti原生是不支任务这种跳转的，不过幸好有人实现了用JumpTaskCmd的方式来进行跳转。另外在查询可退回节点时，要考虑流程反反复复被退回又再审批的情况，过滤掉重复的节点。
8、必不可少的流程干预
包括按条件进行流程查询，将任务指定给任一处理人，任务节点任意跳转等，这些都是线上流程运维必备的功能点。尽量把你的用户当成傻子，我还曾多次遇到过一些粗心的用户在流程审批通过后，才发现某些业务字段填错的情况，如果没有必要的管理员干预功能，那就只能改数据库表实现了。具体需要哪些干预功能，这个和自己企业的情况相结合着来进行吧。
9、Activiti那么多版本，我该选哪个
目前用得相对比较成熟的版本是5.22，版本6.x存续期间很短很快就升级到了7.x，2018年我尝试时是6.0 alapha版本，当时还测出不少bug，现在最新版本是7.1，功能上变动不大，主要是Cloud Native，弹性微服务方向和Docker、K8S支持上做了重大的架构升级。微服务方面，可以近似认为Activiti5中的Activiti-rest是SOA化的Activiti，版本7后是微服务化后的Activiti。但是如前面所讲的，Activiti拿来国内用其实是不完整的工作流，还需要做大量的改造，所以不加包装直接用现在的原生微服务并不友好。Activiti 7除了微服务支持方面外，对FormService和TaskService相关的接口也做了改动，还有最新版本的Modeler还不如旧版本美观。
10、集成Diagram viewer
Diagram viewer是用来查看流程图的一个插件，原生的不算美观也不算很丑凑合着能用。
11、集成Modeler
如图：
线上流程设计必备
12、流程版本管理及上线
需要模型管理，集成Modeler进行模型的新增与修改，还需要进行模型的发布才可以使用新的流程设计。那线下设计好的模型怎么同步到线上环境呢？这就需要提供模型导出和导入功能。另外直接用sql导入不可取，由于流程定义是二进制数据，用sql导入会造成转码后流程数据丢失。当然，极简单点工作流场景下直接把流程和代码一起部署也是可以的。
13、审批业务数据库表设计要点
通常看流程是纯新增类还是带更新类业务，纯新增类只需要正常设计再加个流程实例ID字段与流程实例进行关联即可。如有更新类业务，最好设计一个跟业务表结构一样的草稿表，当流程审批完成后，通过监听器再将草稿更新应用回业务表。
14、扩展流程设计时的assignee
Activiti的用户任务指派相当简单，要么指定人或条件处理人，要么指定用户组，这在中国式审批中是完全不够用的，所以还需要对设计进行扩展，方法是用将assignee字段设置成json，由json扩展各实际条件，当发生TASK_CREATED事件时，动态解析json，再将此json中的配置与流程的变量运算得到实际处理人。好了，在流程设计的时候这串json的输入将是反人类的，所以你还需要提供一个UI，按条件生成这串JSON，甚至更进一步，改进Modeler。
15、完成第一个任务
发起人节点，你有两种设计，一种是直接省略，过了StartEvent后进入下一节点审批任务，但通常任务被退回后，发起人还需要进行销毁或重新申请等运作，所以你需要第二种设计：给发起人节点增加一个UserTask，那发起一个流程的时候就要记得将发起人的这个第一个用户任务自动完成。
16、通用表单设计
老实说这块工作量很大，首先需要将表单设计器生成的html存储后与设计的流程通过formKey建立映射，流程在运行时通过formKey找到对应的表单展示。难点还在后面，需要用户填写的表单数据进行保存，如果是非业务数据可以采用通用的格式进行保存，如果这些是业务数据又想做成通过的，通常是在定义表单时自动DDL生成数据库表，但这种做法又引起维护性和安全性上的问题。另一种办法将通用格式如json/xml，在流程结束后通过一定规则的映射，映射到指定的业务表中。
17、用好监听器
监听器并不是异步的，监听器并不是异步的，监听器并不是异步的，它和事件产生源在同一个线程，就是说如果你有个TASK_COMPLATE事件监听器，如果报异常了，你的taskService的complate事件是完成不了的。另外建议尽量用全局监听器，而不要用局部监听器，因为局部监听器在流程设计中才能看到，会造成业务代码散落到各处而难于维护。
18、流程热部署
热部署的第一层支持是线下设计好流程，通过文件上传功能更新到线上进行部署。再进一步是，线上使用Modeler进行模型设计，完成后进行部署生效。生效后旧流程不受影响，还按旧流程设计进行流转，新流程按最新的流程设计流转。
19、流程销毁与重新申请
这个通过排它网关拉线设计即可，不过销毁后的流程此时是出现在办结里的。如果用户彻底删除的需求，还需要deleteProcessInstance、deleteHistoricProcessInstance及删除业务草稿表相关记录（如有）
20、会签
会签涉及到表决，不过通常来说常用的就两种情况。一种是所有人通过才通过，另一种是有一个人是主审，他通过就通过，在审批过程中他会参考别人的意见。第一种Activiti原生支持，第二种在选会签人时complate自己任务并将自己加入到多人任务中。
好了，如果你对工作流或Activiti有其它疑问，可在评论区讨论。如果你有关于工作流或Activiti的开发、培训或咨询需求，也请站内信联系我。