戏(细)说工作流——activiti

序

最近在用activiti实现一个比较复杂的工作流的功能。写完后思绪万千，对工作流的理解仿佛打开了新的窗户。由于每天上下班的主要交通工具是地铁，突发奇想将工作流中的概念与交通中的概念出现联系了起来。本文不对工作流的基础概念进行阐述，而是记录工作流业务应用的一些思考，以及对我理想的工作流的描述。

狂想篇

我理想中的工作流应该像公交站牌，或者地铁车厢内运行站点提示图一样直观。清晰直观地定义列车运行的线路及经过的站点信息，事实上目前的工作流框架已经做到了这一点。除此之外，如果工作流有一个画面能像地铁车厢车次运行线路状态图一样，动态的显示地铁运行当前所在的站点，这将会极大的提高了对工作流实例运行状态的便利性。在这样的画面中，不仅可以得到全局流程定义的审批任务线路信息，还可以监控到流程实例运行到哪个任务节点，就像乘坐在地铁车厢中，抬头看一下车厢上面地铁的运行站点栏就可以知道，这条地铁运行的线路，经过哪些站点，当前的行驶位置，点击某个任务节点就可以获取到参与此任务节点的人员信息，可以直接在这张图上查看到任务的历史审批信息。决定流程是否继续前进、还是终止、或者拨回后退到某个节点都可以直接在这一站途中操作。不需要像目前业界实现的流程那样，查看流程图、领取任务、审批任务、查看历史任务都分散在不同的地方，需要同时完成这些操作是需要频繁地切换，要熟练地掌握这个流程的使用必需清楚记得这些该死的繁琐的操作页面的入口。。。。。。可惜目前的工作流框架还没有做到这个程度。查看流程定义信息和查看流程实例运行情况是分散的，没有联系的，对参与流程的用户来说实际上很不友好，非常不人性化。

回到现实

梦想是要有的，万一有人实现了呢？回到现实吧，留点篇幅总结我自己对工作流的特性的理解
（1）审批模式
审批模式概括性地可分为主动模式和被动模式两种。被动模式指的是处理当前任务时，明确的指定下一个节点的审批人，下一个审批其实是被动的接受任务。主动模式指的是流程引擎创建了流程实例的审批任务后，这个任务所属组的所有成员是可见的，由这些成员主动地领取任务去处理。其实变换一下描述的角度，这个主被动模式的概念也可以调换的。
（2）任务的流转模式
任务的流转模式可分为单线路模式、单线路条件模式、多线路并行模式、多线路条件并行模式。activiti中提供了排他网关来支持实现单线路条件模式、提供了并行网关来支持实现多线路并行模式、提供了包容网关来实现多线路条件并行模式。
（3）关于子流程业务场景的使用
需要用子流程来实现的业务场景，其实大多数都可以通过并行网关来实现。如果可以用并行网关来实现就不要用子流程实现，子流程实现复杂，增加了流程的复杂度，和对流程运行异常的处理。
（4）会签任务与并行任务的区别
会签任务的技术实现原理是任务的多实例，并行任务的实现原理是任务的fork与join，可见原理大同小异。指定比例或者数量的审批人同意会签任务就可以通过，而并行任务则是并行的任务都要通过方可到达并行后的任节点。
（5）针对任务的操作中同意、拒绝、驳回、释放、指定代理操作的区别。
这些操作中最常用的应该就是同意、拒绝操作了，即便是个流程这两个任务操作是必需的。那么，就来说说驳回、释放、指定代理这几种任务操作的差别吧！任务的处理人发现任务的历史处理结果不符合预期，想打回去给指定某个历史节点让其重新处理——驳回；任务处理人领取了或者被指派了某任务，发现处理不了此任务，将分派到的任务退回到待分派状态重新分派——释放；任务处理人发现他没时间处理分配到的任务，将分派到的任务又指派给其他人处理——代理。
（6）流程实例与程序、与任务处理人的互动
流程实例与程序的互动典型的应用场景就是，通过在用户任节点中配置业务逻辑处理组件来实现动态指定对应任务节点的审批岗位或者审批人，另外，是一个流程可少的，就是流程审批结束后调用的流程业务执行逻辑；参与任务审批的业务人员对任务进行的操作，包括指定下一审批人、跟新流程关联的业务信息啊。。。等等。。。
（7）流程实例相关的数据展示要有层次
关于层次这个概念经常会在架构中看到，业务处理服务分参差，可以提高业务系统服务的复用率，可以减低业务功能的耦合性，可以提高业务应用的扩展性。要达到这个目标，首先要做的是要对数据进行分层，分层设计、分层展示，不同层面的数据决不能耦合的设计在一起，也不应该耦合的展示在同一维度。比如流程待审批任务页面展示的任务列表，应该只展示审批任务的信息，如任务的名称、所属流程实例id、下一审批人，任务创建时间、流程的发起人、可链接查看历史任务节点的审批信息。除此之外，是万万不能包含流程任务所处理的业务数据信息，如果包含了，开发的流程少则可以，如果数量多，那么这个页面最终将失控。因为不同的流程所处理的业务数据五花八门，可能是完全没有共性的，完全不在一个业务维度的，所以在任务列表里出现业务信息字段，绝对是设计上的大坑。业务数据应该展示在任务明细的表单里，任务明细表单是各个流程私有的信息展示窗口。这个地*要做的通用可动态实现，也可以连接到一个任务明细页面，这做会大大提高不同流程个性化拓展的空间。

就写这么多吧，要下班了，关于工作流本文肯定无法像activiti实践那样系统全面，旨在从实际业务开发经验的角度记录下所思所想。。。。。。。。。。。。。。。
END。。。。

本文地址：https://blog.csdn.net/feifeixiongxiong/article/details/111036356