activiti工作流引擎多版本方案

activiti流程多版本共存问题

过去使用jbpm4，有一个非常大的问题：

就是当流程发生变化需要部署新版本的时候，由于旧版本有实例在运行中，不能直接覆盖旧版本的流程，必需新旧（两个甚至多个版本）共存。而jbpm4本身没有处理多版本共存过渡到机制，而需要通过自行封装添加属性值来描述版本号，这导致封装没有完善的情况下，多版本并行机制几乎不可用。

activit5 已经考虑到多版本问题，即同一个流程，多次部署后会自动产生新的流程标识号并带上版本ID，如

原版本流程标识号为 testExample:1:201，
修改流程配置并部署后，即会自动变更为 testExample:2:301

由此，通过

runtimeService.startProcessInstanceByKey("testExample").getProcessDefinitionId();

可以获取到testExample:2:301这个ID，即可分离出2这个版本号
而通过自定代码组织的协议约束，如规定testExample.java打包位置

package com.yudean.timss.flows.testExample.rX

其中rX的X为版本号，即testExample目录有r1和r2两个子目录，里面都分别有testExample.java这个处理类
而其他调用程序根据获取到的版本id，可同IoC在运行时才实例化对于版本下的处理类（r1.testExample或r2.testExample)

---

这样还有一个问题：

如何区分upgrade流程和update流程

• 所谓upgrade，即业务逻辑已经发生变化，譬如从3个处理节点，变化成4个，譬如节点的逻辑已经不一样；
• 所谓update，即流程只是略有变化，譬如字面的变化（“总经理审批”变更为“总经理审核”），流程逻辑没有发生变化。

upgrade流程通过正常的部署流程方式，会自动增长一个版本，然后通过之前说的方式，有对应的新版本的处理代码，这是我们想要的效果；
但是如果是update流程，通过正常部署增长了一个版本，但实际上业务处理的逻辑代码是完全不需要变更的，那我们为了迁就版本+1的情况而需要复制一份完全一样的代码对于新版本，这样不单造成代码冗余，还造成简单修改流程需要变更代码重新编译部署，增加了维护成本。

再考虑这样一个场景：

业务需求有变更，流程A要从r1升级到r2，部署到测试环境，变成r2，测试后发现bug要修改，并重新部署，版本自动变为r3，最终测试通过部署到生产环境，但生产环境版本号为r2了，两个环境的版本不对应，而为了两个环境都能正常跑，则需要有r2,r3两套完全一样的代码。

这也可以归纳为update和upgrade的问题。

网上有这样一种方法：

there is a SetProcessDefinitionVersionCmd class you can use to change
the process version on a process instance. It's not “smart”, though;
it simply changes the version number, and doesn't change any other
runtime data

即可封装一个update的操作，通过调用SetProcessDefinitionVersionCmd 来强制不升级流程版本号，此方法尚未证实可行性，但也不失为一个参考。

另一种解决办法：
建立版本对应表，即我们自定义一个流程版本号，并且与activiti的原生版本号作映射，场景如下

1. 设定activiti的原生版本号为r，我们自定义的版本号为v；
2. 初始化一条流程的时候，它是r1版本，映射表中r1->v1，即对应使用代码中v1标识的包来处理业务逻辑；
3. 开发测试过程有变更（属于update），部署后变成r2，映射表中增加r2->v1，因此对应的处理代码还是v1标识的包，代码当然有对应更新了。
4. 部署到生产后，实际版本是r1，映射表r1->v1；
5. 使用过程中，业务人员提出变更某个环节名称，但处理逻辑不变更（属于update），则部署更新流程版本去到r2，映射表增加r2->v1，则依然使用v1包来处理。
6. 随着推广使用，管理层提出优化流程，整个审批流作了精简（属于upgrade），此时部署更新了流程版本去到r3，并且需要不同的代码处理，因此映射表增加r3->v2，并部署v2的代码包。