activiti工作流引擎(5)多版本

原创
2014/03/01 21:45
阅读数 1.1K

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的代码包。
展开阅读全文
打赏
0
1 收藏
分享
加载中
更多评论
打赏
0 评论
1 收藏
0
分享
返回顶部
顶部