Activiti使用小技巧

见贤思齐

经验 | Activiti使用小技巧 经验 | Activiti使用小技巧 何莉莉 贝壳产品技术 贝壳产品技术 “贝壳产品技术公众号”作为贝壳官方产品技术号，致力打造贝壳产品、技术干货分享平台，面向互联网/O2O开发/产品从业者，每周推送优质产品技术文章、技术沙龙活动及招聘信息等。欢迎大家关注我们。 242篇内容 2017年08月09日 14:23 作者｜何莉莉编辑｜冯钰网址｜tech.lianjia.com微信公众号｜链家产品技术团队前言三方合同系统自从签前审核项目开始，一直有跟工作流打交道，最近合同变更项目也开始对接工作流。在这个过程中，面对复杂多变的业务场景，为了解决各种出其不意的业务需求，我对activiti进行了更多的探索和发现，本文的初衷是将我发现的一些小技巧分享给大家，希望能给大家以后使用activiti、对接工作流平台一些参考。技巧一：排他网可以省略排他网关，也叫异或（XOR）网关，用来在流程中实现决策。当流程执行到这个网关，所有外出顺序流都会被处理一遍，其中条件为true的顺序流会被选中，让流程经由这个顺序流继续执行。我们来看一下面这个流程：商圈经理审核，排他网关决策，通过的话就走顺序流4（flow4），否则走顺序流3（flow3）；法务后面也有一个排他网关，通过走flow6,驳回走flow7。这个流程定义没问题，但是当我们遇到比较多判断的时候，流程中如果加入很多排他网关，那么流程图会比较长，例如会出现在页面上展示不全的问题。有没有办法简化一下？我们回顾一下排他网关的决策原理：一个排他网关会对应着一个以上的顺序流，每个顺序流都有个conditionExpression条件，返回boolean类型的决策结果（直白地说，就是会走条件为true的那条线），排他网关会从上而下选择第一个条件为true的顺序流。所以，本质上排它网关的决策是顺序流的决策。如果没有配conditionExpression，顺序流默认是true。这就是为什么，上图中，流程开始不需要条件就到达商圈经理任务，商圈经理任务不需要任何条件就能走到第一个排他网关。既然顺序流可以起决策作用，我们是不是可以考虑，给用户任务后面跟着的那些顺序流加上conditionExpression，以达到控制流程走向的目的？答案是肯定的！这就是我们探索的结轮：排他网关其实可以省略掉，直接在用户任务后面接决策条件，同样可以达到决策流程走向的效果。但是要说明的一点，排他网关的作用是可以使流程更清晰，能够具体、直观地看出流程走到这个节点，有一个路径的判断、选择过程，它的直观是无可替代的。所以，我们并不是推荐大家一定要把排他网关省略掉，而是仅供一个参考，到底要不要省掉，请具体问题具体分析。我们一般是在流程中排他网关比较多导致流程图很长、影响了页面展示并且决策条件单一的情况下会考虑省略它。上面的流程图可以简化如下，此时flow3、flow4都是带条件的（conditionExpression）：该流程定义xml如下： 技巧二：跳过用户任务的简单实现跳过用户任务，意思是比如上面的流程，如果流程发起人没有商圈经理，那要跳过商圈经理这个审核节点，直接到法务审核。针对这个业务需求，我们可以再流程图上加一个”排他网关”（自从知道排他网关可以省略之后，我再也不画排他网关了），如下图：这个流程看起来也没什么问题，是能满足需求的，不足之处就是丑了的。要是法务那个任务也“没有法务可以跳过”，那就又要多两条线了。实际业务里面，我们就遇到了一个流程三个用户任务，其中两个可以跳过的，幸好掌握了技巧一省略了排他网关，否则这个流程也会相当长。问题来了，这个流程还能不能再简化，有没有办法把这些线也去掉呢？笔者发现，用户任务的配置里面有一个叫“skip expression”的配置项，“跳过表达式”，听起来正是我们想要的。跳过表达式，当表达式条件为true，就跳过当前任务，进入该任务之后的流程。在activiti实现里面，就不会创建该用户任务了。有了这个跳过表达式，上面的流程图就可以简化成这样：流程图跟上面第二个图一样，唯一不同的是，商圈经理这个任务加了跳过表达式。流程定义上的区别是，商圈经理任务多了配置：activiti:skipExpression="${execution.getVariable('hasManager')==false}"流程定义如下： 技巧三：A或B岗位的用户都可以处理的用户任务首先，说明一下三方合同对接工作流平台，关于用户身份的处理机制。目前对接工作流平台，我们没有使用activiti用户组（group）的概念，原因是，第一目前工作流平台暂不支持用户组，没有存UC的用户数据；其次，是业务中用户身份是多样的，很多时候判断一个用户到底有没有审核某任务的权限，我们有可能是根据用户权限点来控制、也有可能是根据用户角色来控制、还有可能是二者的结合，不确定activiti的group能不能满足多样化的业务需求。所以，权衡了工作流平台的现状以及业务的复杂性，我们没有使用activiti的group机制来控制用户任务，而是采用的是折衷的、较为简单的方式，将用户任务的审核人信息作为该任务的一个属性，如IDENTITY_FLAG，用户的待办、已办任务就通过该值进行查询。基于以上的背景，我们在业务中遇到了一个问题。业务需求是这样的，一个任务，商圈经理或者总监都可以审，只要有一个人审核通过，流程就可以继续往下走了，大概是下面这样：这个需求可以用“一个任务，多种身份”的方式来处理，但是这不是我们想要的。我们始终希望一个用户任务，只对应一类身份的审核人，这样对我们的待办、已办数据的处理更方便。经过一番探究，后来我们采用了并行网关加监听的方案解决了这个问题。并行网关的作用是，将单条线路任务拆分成多个路径，等到多条路径都平行完成之后，再合并起来。那么我们就可能利用并行网关，将任务拆分成并行的路径，只要流程经过第一个并行网关之后，就会同时出现两组用户待办任务，满足了需求：商圈经理和总监都可能审核。流程定义如下：但是，有一个问题，当一个任务通过，该路径会到达后面那个并行网关，然而另一个任务还没有处理，流程会卡住。为了满足需求，我们要想办法把另一个任务处理掉，让其中一个任务通过，流程就能继续往下走。在此，我们采用了监听机制，两个任务互相监听对方是否完成，有的话，就把当前任务complete掉。如上流程，如果商圈经理通过了该任务，监听方法就把大区总监的任务也通过，然后流程就可以顺利到达下一个节点。下面是商圈经理任务的listener的配置：监听directorTask（大区总监任务），在监听方法里面判断，审核结果（AUDIT_FLAG）为通过时，完成本任务；驳回就不用了，因为整个流程已结束。该流程定义xml如下： 预览时标签不可点 关闭更多小程序广告搜索「undefined」网络结果