应用jBPM4解决中国特色的流程需求_SOA_辛鹏



 写点什么

1. jBPM4 的特点

jBPM 是 JBoss 众多开源项目中的一个工作流开源项目，也是目前应用最广泛的工作流项目。在今年的 7 月 10 号，JBoss jBPM 团队正式发布了 jBPM4 的正式版。jBPM4 完全基于流程虚拟机（PVM）的机制，对核心引擎进行了重新设计，而 PVM 的引入也使得 jBPM4 可以支持多流程语言了。除此之外还有很多其它的特点：

流程定义对象的变化在流程定义的对象上，节点类型划分更清晰，详细的对象解析，可参见我曾经写过的文章：《 jBPM3 与 jBPM4 实现对比》。
基于观察者模式的 Event-Listener 机制在 jBPM4 中活动节点对象ActivityImpl、转移对象TransitionImpl、流程定义对象ProcessDefinitionImpl，全部继承了ObservableElementImpl对象，因此组成流程定义的三个主要元素都可作为观察者模式中的被观察者来观察，而这些对象本身就直接支持注册各种 Event，然后由 Listener 来监听这些 Event。
基于 ExecutionImpl、Command 模式和 AtomicOperation 实现的引擎调度在 jBPM4 中用 ExcutionImpl 替掉了 jBPM3 中 Token 机制，流程的流转，依赖于 ExcutionImpl 调用各个 AtomicOperation 原子操作（ExecuteActivity、MoveToParentActivity、TransitionTake、TransitionStartActivity、ExecuteEventListener、TransitionEndActivity）进行推进，而 ExecutionImpl 在各个实例对象之间进行转移，详细情况同样参见《 jBPM3 与 jBPM4 实现对比》中的”流程启动序列图”和”流程推进序列图”。(注：当时的那篇文章是基于 jBPM4 alpha 版本写的，在正式版中有一些变化。)
历史库的加入作为任何一个正式运行的大数据量的软件系统来讲，没有历史库的切分肯定只能当作玩具，而 jBPM3 没有任何的处理，必须由开发人员自己来解决。在 jBPM4 中终于加入了这个功能，不过我认为目前 Jbpm4 的历史库设计还是存在一些问题的，例如，它是在活动（或任务）结束时，直接将数据归入历史库，实际上我认为这是没有必要的，我认为在整个流程实例结束时去做这个事情反而更好一些。其次，在将运行期的实例归入历史库时，并不是将所有数据都进行了 copy，这就造成了在历史库中丢掉了一些运行期的数据属性。还有任务历史库中没有针对 task candidates 参与模式的任务拾取时间的记录导致无法做绩效统计等。

2. 国内人工任务密集型流程的典型特点

中国目前在工作流领域主要的应用是人工工作流，也就是以人工任务密集型的工作流为主。当然随着中国企业和公共组织的信息化发展越来越快，IT 系统的积累和建设经验也越来越丰富，因此以自动任务密集型为主的应用正在逐渐增多。但本文主要的还是讲述人工任务密集型工作流的特色、需求、场景及实现。这种类型的流程应用，主要集中在以下领域如：电子政务，行政审批，企业协同办公，电信、电力之工单，企业采购、合同、销售等。

从功能需求上来说，这些人工任务密集型流程的典型特点主要有以下几个方面：

1）用户友好的流程定义工具，就是说由业务用户自己对流程进行定义。其实这是一个伪命题，因为此处讲的流程是可以 run 的，与业务系统有紧密的关系，完全地让最终用户来设计一个这样的流程是不现实的（即使是不可以 run 的 BPMN 同样也很困难，需要进行大量的培训）。但是业务用户是可以对已经建立好的流程进行改进的（呵呵，此处就是 BPI 的一个体现），因此提供一个基于 WEB 的，简单易用的、用户友好的流程设计器是非常有必要的。

2）表单自定义，就是说能有一个可高度定制的表单设计器，用户可以随时根据业务需求进行调整，或者新建表单，这个需求对于有“语义层”的 form engine 来讲是可以实现的。那么除了表单自定义以外，当然还要能实现表单与流程任务的轻松绑定及表单权限的设定，使得不同环节的处理人能够对表单的不同域有不同的读写权限。

3）灵活的临时动态性需求，例如：任意回退、会签（包括加、减签，补签）、撤销（又叫回退）、自由流（又叫动态路由）。此处之所以叫做灵活的临时动态性需求，就是因为这些需求，存在着很强的人为性因素（呵呵，此处才是真正的中国特色）。

3. 应用 jBPM4 解决国内的典型流程需求

3.1 用户友好的流程定义工具

关于流程自定义，jBPM4 本身提供了基于 eclipse 的 plugin，可以让开发人员来进行流程的建模，但是我们不可能让一个业务流程管理员去下载使用 Eclipse，因此我发起了一个基于 jBPM4 的开源工作流项目 jBPM-side ，上边我已经提到了国内流程的典型需求，而这些需求直接用 jBPM4 来实现，需要很高的成本，因此将 jBPM4 进行本土化的改造封装以满足国内流程应用的需求，就是发起 jBPM-side 项目的目的。而上边提到的所有典型需求，就是 jBPM-side 项目的特点。

目前 jBPM-side 正在全力开发基于 flex 的流程设计器，本项目的代码在 google 托管地址如下： http://code.google.com/p/jbpmside/ ，此设计器是真正意义上的一个用户友好的流程定义工具。我们初步的界面原型设计如下：

图 0 jBPM-side designer 界面原型示意图

另：jBPM4 本身也已经开始 BPMN 的相关代码开发了，建议也密切关注。

3.2 表单自定义

表单自定义的需求，应该来说在国内、国外都存在这种需求，我记得在 jBPM 的官方论坛里，Tom baeyens 和其它人讨论过电子表单的问题，但是现在在论坛中已经找不到了，在 wiki 上还可以看到 Tom 写的文章： jBPM4andXForms ，在这个文档中，Tom baeyens 认为可以用 xform 来作为 Task form 的一个实现，并给出了 Orbeon 和 Chiba 的链接，但同时也提到了他们会继续调查 freemarker 和 velocity 这两个模板引擎，并且说这件事情仍需要继续讨论，所以目前 jBPM 的团队并没有在表单自定义方面的计划。jBPM4 的子项目 GWT-console 目前默认的表单实现采用了 freemarker 方案，但是 freemarker 仅仅是一个模板引擎框架，与真正的电子表单产品（例如 infopath，一个完整的电子表单产品，包括表单设计器、表单引擎、数据存储、事件引擎等）还相差甚远。jBPM-side 项目可能会基于 Orbeon 或 Chiba 进行表单引擎及设计器的本土化封装，同时也提供商业电子表单产品的调用接口。

3.3 灵活的临时动态性需求

3.3.1 回退

需求描述：

回退作为审批流来讲是最常见的需求，对于审批流来说，每一个审批环节都有可能会有审批通过、不通过 2 种情况，而审批不通过时，一般是回退到上一个环节，但是在某些情况下，有可能跨环节回退，例如，在第 5 个审批环节，审批不通过时，直接回退到第 2 或第 1 个环节。而到底回退到哪个环节是可以让用户根据业务需求进行自定义的，并且在回退环节工作完成之后，其下一步的方向也可以让用户自定义。如，要是由第 5 个环节回退到第 2 个环节，那么当第 2 个环节重新修改业务数据并办理完毕后，流程引擎可以设定是重新按照 2-3-4-5 的顺序重新执行一遍，也可以设定由第 2 个节点返回给第 5 个节点，由第 5 个节点重新审批。

场景及 jBPM4 实现思路：

图 1 串行流程示意图

场景 1 串行流程：在这个场景中，由于流程是串行的，没有分支的情况，因此处理起来最简单（如图 1 所示）

场景 1 实现思路：

对于这个场景，在 jBPM4 中, 最直接的方式，就是在需要回退的各个节点之间建立回退线（如图 5 所示，如果需要从节点 4 回退到节点 2，则直接在节点 4 之后加一个分支决策节点，连接两个分支，一个是 pass to 节点 5，一个是 reject to 节点 2）。

对于节点 2 来讲，在 jBPM4 中，其参与模式又分为 4 种：task-assignee（assignee user、assignee expression）、task candidates（candidate-groups、candidate-users）、task assignment handler、task swimlanes。

task-assignee 任务的办理人的值可以直接指向一个特指的用户的 id 或者一个关联到业务中某个特指用户的表达式（例如 order.owner）。此时，如果 assignee 赋予了一个特指用户的 id，回退时不用做任何处理。如果 assignee 赋予了一个业务表达式，在回退时，需要保证业务表达式的运算逻辑能够正确执行。
task candidates 任务的办理人为几个特定的组的集合，或者用户的集合，在这个场景下，实际上就是我们俗称的“竞办”。这样的任务被称为 groupTask，必须被某一个组或者用户拾取才能进行办理，因此如果回退到这样的节点时，需要把任务回退给当时的拾取人。而拾取人需要到 HistoryTask 和 HistoryDetailImpl 两个实体对应的历史库中取得。
task assignment handler 任务的办理人通过用户自己编写的代码来实现，此时回退到这样的节点时，也不需要做特殊处理，只要保证自己的代码（AssignmentHandler）在执行回退逻辑时同样能够正确执行即可。
task swimlanes 任务的办理人为“泳道”，回退到这样的节点时，任务的办理人可以自动取得，同样不需要做任何处理。

以上 4 种情况，在回退之后的处理，又分为 2 种情况，一种是，按照原来的路径重新执行，即节点 2—节点 3—节点 4，另一种是，节点 2 办理完毕后，直接返回给节点 4。对于第 1 种情况，不需要做处理。而对于第 2 种情况，由于在节点 2 和节点 4 之间并没有一个转移存在，因此 jBPM4 也没有提供原生的支持。那么针对这种情况，笔者的解决思路是：通过动态创建跳转来实现（具体实现方法，详见 3.3.4），实际上回退也可以用动态创建跳转来实现，而就不用画回退线了。

图 2 串行流程的回退实现

场景 2 M 选 N 分支流程：对于这个场景，N 的取值范围为 M>N>=1，假设回退前流程的执行路径为节点 1- 节点 2- 节点 4- 节点 5（见图 3），此时回退有两种情况：

由节点 5 回退到节点 1，而节点 1 在进行业务数据的修改后，直接返回给节点 5 的处理人进行办理或审批；
由节点 5 回退到节点 1，而节点 1 在进行业务数据的修改后，重新按照节点 1- 节点 2- 节点 4- 节点 5 的路径再执行一遍；

图 3 分支流程示意图

场景 2 实现思路：此场景与场景 1 不同的是，在回退之后继续审批时，需要考虑分支节点的决策条件，在自动决策时要保证决策逻辑正确执行，在人工决策时，需要记录原来的执行路径（保证重走 1-2-4-5）。

场景 3 同步分裂、与汇聚流程（如图 4 所示），回退前执行的路径为节点 1–节点 2–（节点 3、节点 4）–节点 5–节点 6，此时回退有 4 种不同的情况要考虑：

由节点 6（或节点 5）回退到节点 2（或节点 1），节点 2 重新办理完毕后，直接返回给节点 6 的处理人进行办理或审批；
由节点 6（或节点 5）回退到节点 2（或节点 1），节点 2 重新办理完毕后，重新按照节点 2–（节点 3、节点 4）–节点 5–节点 6 的路径再次执行一遍；
由节点 6（或节点 5）回退到节点 3（或节点 4），节点 3（或节点 4）办理完毕后，直接返回给节点 6；
由节点 6（或节点 5）回退到节点 3（或节点 4），节点 3（或节点 4）办理完毕后，按照节点 3—节点 5—节点 6 的执行路径，再次执行。

图 4 同步分裂，与汇聚流程示意图

场景 3 实现思路：此场景当流程由节点 6 回退到节点 3，节点 3 办理完毕后，重走路径节点 3- 节点 5- 节点 6 时，在“与节点”的与运算逻辑就会无法执行，因为另一个与分支，节点 4 并没有新的实例产生，流程就会僵死此处。在 jBPM4 中，可以通过修改JoinActivity.java这个类中的protected boolean isComplete(List<executionimpl> joinedExecutions, Activity activity)这个方法，在方法中加入对此场景的处理代码即可。

场景 4 同步分裂、或汇聚流程（如图 5 所示），回退前执行的路径为节点 1–节点 2–（节点 3、节点 4）–节点 5–节点 6，此时回退有 4 种不同的情况要考虑：

由节点 6（或节点 5）回退到节点 2（或节点 1），节点 2 重新办理完毕后，直接返回给节点 6 的处理人进行办理或审批；
由节点 6（或节点 5）回退到节点 2（或节点 1），节点 2 重新办理完毕后，重新按照节点 2–（节点 3、节点 4）–节点 5–节点 6 的路径再次执行一遍；
由节点 6（或节点 5）回退到节点 3（或节点 4），节点 3（或节点 4）办理完毕后，直接返回给节点 6；
由节点 6（或节点 5）回退到节点 3（或节点 4），节点 3（或节点 4）办理完毕后，按照节点 3—节点 5—节点 6 的执行路径，再次执行。

图 5 同步分裂，或汇聚流程示意图

场景 4 实现思路：此场景与场景 3 相比，因为是或汇聚，因此在实现上不需要做任何处理了。

场景 5 子流程：就是流程嵌套的场景，在父流程中通过子流程节点启动了子流程实例，此时回退时，就更复杂了，因为涉及到了不同的流程实例、还有在父子流程之间的数据传递。

场景 5 实现思路：子流程的回退，原则上是不支持的，因为涉及到不同的流程实例之间的回退，这个场景在 jBPM4 中实现起来异常的复杂，而且实际的业务场景也极少，因此在此不建议做这个实现。

小结：

综合来讲，回退本身在理论上来讲有各种各样的情况存在，再加上业务的回退（或者说业务逻辑补偿？如果需要你就必须在流程的每个环节进行业务快照的备份，在回退时调用这个快照进行补偿），此时回退可以说是整个流程体系中最复杂的情况了。但是在真实的业务场景中，有些情况可能是根本不会出现或者说很少出现的（毕竟理论不等于现实嘛）。因此技术人员一定要摒弃一个习惯，就是不要完全从理论和技术的角度考虑问题，一定要看用户是否有这样的需求，即便有了特定的需求，也首先要考虑的是能不能通过变通的方式处理，或者说服用户放弃这个不合理的需求，最后实在没办法了，再去考虑技术的实现。

3.3.2 会签

需求描述：

会签在政府或企业来讲都是必有的功能，尤其是审批流中。简单来说，会签是可以分为单步会签（只有一个审批环节），及多步会签（每一个子审批流有多个审批环节）的。

单步会签：很简单，就是在流程的某个环节需要由多个办理人（多个不同部门的领导）共同办理，或者签署意见。这个场景就不用说了，在企业或政府的内部都很常见。

多步会签（也叫并联审批）：其实就是一个单步的审批环节就变为了在部门内部一个比较复杂的审批流程，这个审批流程有多个审批环节。

加签：在流程定义期已经定义好会签范围（例如某个岗位或部门），但是在运行期，会签发起人发现对于某个个例需要新增会签人或会签单位，而且新增的会签对象不在原来设定好的范围内。此时由会签发起人直接进行加签操作。

减签：同上，只是相反的操作而已。

补签：会签发起人已经将会签任务发送给张、李、王三个人，而此时，张发现这个任务还需要孙来会签，那么此时，可以由张直接发起一个给孙的补签任务，而不必回退到会签发起人那里。

会签百分比：会签发起人将任务发送给 5 个人办理，而结果是只要有 80% 的会签百分比即可算审批通过（也就是说只要有 4 个人审批通过就 OK 了）。

场景：

单步会签：对于单步会签的场景很简单不在此描述了。

单步会签的实现思路：可以对 TaskService 进行扩展开发，实现动态任务实例的创建，可参照TaskActivity这个类中的方法进行扩展，扩展之后再调用addTaskParticipatingUser()或addTaskParticipatingGroup()方法实现动态增加任务办理人，此时即实现了单步会签功能。

多步会签场景一：审批环节相同。在企业内部的各个部门之间（例如，办公室、采购部、财务部）进行并联审批，每个部门中都需要多个审批环节，而这些部门的审批环节完全相同，只是每个审批环节的办理人不同而已（例如在财务部，需要财务专员、财务经理、财务总监等审批；在办公室需要办公室科员、办公室副主任、办公室主任审批），因此可以公用一个子流程定义。

场景一的实现思路：最常见的方案是通过启动一个子流程定义的多个子流程实例来实现多步会签。这时，即便是对于会签的部门数是未知的，需要动态决定，也可以轻松实现，只需要在运行期根据会签部门数动态地创建同等数量的子流程实例就可以了。但是不要高兴的太早 J，由于在 jBPM4 中，流程的推进是依赖于 ExecutionImpl 来执行的，而对于每一个流程实例 ProcessInstance 持有的 ExecutionImpl 实例也只有一个与之关联的 subProcessInstance，因此对于一个子流程节点 SubProcessActivity 来说也就只能有一个子流程实例与之关联了，此时要想通过启动一个子流程定义的多个子流程实例来实现多步会签，实现方法与在 jBPM3 中实现多子流程实例类似（可以在网上搜到很多 demo），就是结合 Event-Listener 机制和对 Variable 的使用，去创建多个子流程实例（注意的是在 jBPM4 中没有 ActionHandler 了，取而代之的是基于观察者模式的 Event-Listener 机制）。

多步会签场景二：审批环节不同。实际上与场景一相比，就是会签部门的审批环节不同了，也就是说在企业内部的每个部门都要有自己的审批流程，其它与场景一是完全一致的。

场景二的实现思路：此场景，可以和场景一的实现相同，唯一不同的是由一个子流程定义的多个实例，变为了不同子流程定义的不同实例。

多步会签场景三：分布式审批。在政府部门，例如我们需要去政府的行政大厅去办理新公司注册，那么在行政大厅启动一个新公司注册的流程，在申请人提交完所有资料后，流程继续向下执行，这时可能就需要工商局、公安局、地税、国税等多个委办局进行内部的并联审批，每个委办局都需要在内部走一个复杂的审批流程，每个委办局的流程审批完毕后，流程回到行政大厅的那个父流程中。此场景与场景二相比，其实就是企业内部的各个部门变为了不同的委办局或子公司，此时的流程是分布式部署在各个委办局或子公司的。

场景三的实现思路：由父流程执行到某个会签节点时，通过 jms 消息向各个会签部门（注意这个会签部门一般都是分布的，例如公安局、工商局、税务局等）发送业务数据，而父流程在此等待会签结果，而各个会签部门都有自己的监听器，在监听到会签请求时，在内部发起自己的审批流，内部审批完毕再发送业务数据给父流程，父流程接收到审批结果的业务数据后，流程继续向下执行。

在 jBPM4 中实现起来就很简单了，因为 jBPM4 提供了 jms 的消息、Event-Listener 机制，而 jBPM4 本身也完全是基于观察者模式进行设计的，此时通过在会签节点上绑定特定的 Listener，在 Listener 中向特定的目标发送 jms 消息（可参见 MailListener 的实现）。

小结

对于单步会签的应用场景较多，在 jBPM4 中也提供了直接的支持。

对于多步会签场景一，实际上这个场景在真实的企业中并不多见，因为大多数的需要会签的业务都是只需要部门中的一个关键领导审批就可以了，也就是单步会签的场景。当然如果在某个特定的企业中，这种情景很多，为了流程管理员使用方便，那么对 jBPM4 的代码做一定的修改也是可以的。

对于多步会签场景三，实际上，由于各个部门（公安局、工商局、税务局）都是分布的，采用的工作流产品也是不同的，即便是同一个公司的产品，也是分布式部署的，因此在这个场景中，是不需要用 subprocess 或 subProcessActivity 这些概念的。因为此时的并联审批本质上是两个相同等级的流程之间的通信而已。

3.3.3 撤销

需求描述：

任务在发送给下一个办理人之后，发现任务发送错误了，此时在下一个办理人还没有办理之前，可以撤回当前任务，而重新选择其它人进行办理。

场景：

撤销的场景与回退的场景很类似，虽然有很多的场景，但是各个场景的处理情况是一样的，因此在此只给出最简单的一个场景，如下图 6 所示：

图 6 串行流程示意图

节点 2 的处理人（假设是张三），办理完毕之后，将任务提交，此时任务到达了节点 3（假设李四办理），这时李四就会收到一个待办任务，在李四还没有办理之前，张三突然发现，有一个业务数据填写错误，或者粘贴的附件错误，这时张三需要将发送给李四的任务撤销（也叫收回），重新更正数据后或修改粘贴的附件后再发送给李四审批。还有一种情况是，假设节点 3 的办理人有 2 个人（李四和王五），那么张三需要在运行期根据业务特性手动地选择任务是提交给李四还是王五，但是由于李四的误操作，把本来应该发给王五的办理任务错发送给了李四，此时，在李四办理之前，张三也可以将发送给李四的任务撤销（或收回），然后重新发送给王五。

jBPM4 实现：

在 jBPM4 中实现撤销，虽然场景有很多，但是各个场景的处理是一样的，也就是在撤销时，首先删除需要撤销的任务实例及其与此任务实例相关的所有工作流实例。在 jBPM4 提供了级联删除任务实例的相关方法，如下：

复制代码

  
TaskServiceImpl.java
 
public void deleteTaskCascade(String taskId) {
   commandService.execute(new DeleteTaskCmd(taskId, true));
}

其次修改当前任务实例的状态，即将张三的已经办理完毕的节点 2 对应的 TaskInstance 的状态更改为待办状态：

复制代码

  
（Task.STATE_OPEN）
 
                           task.setState(ask.STATE_OPEN);
                           taskService.saveTask(task);

小结：

撤销的需求在审批流中也是最常见的业务需求，毕竟人都有犯错的时候嘛，而且一般的软件都有 Undo 功能。但是对于 jBPM4 中的 fork-join，sub-process 都需要把撤销任务的相关实例都删除。

3.3.4 自由流（动态路由）

需求描述：

针对于特定的业务实例，在原本没有转移关系的环节之间进行特定的跳转，例如在一个串行的流程中（1-2-3-4-5），节点 2 与节点 5 之间是没有任何转移存在的，但是针对于某个运行期的特定业务实例，要求，审批环节直接从节点 2 跳转到节点 5（而略过了节点 3 和节点 4）。

场景：

图 7 串行流程示意图

jBPM4 实现：

图 8 动态路由实现示意图

如图 8 所示，在节点 2 和节点 4 之间由程序动态地创建一个转移（transition），并设定为优先级最高，那么在执行takeTransition()方法时，按照优先级优先执行动态的转移，然后对外暴露一个jumpTransition（String destinationActivityName）方法给客户端。在 jBPM4 中，可按照如下步骤实现：

参照 CompleteTaskCmd.java 扩展开发用于跳转的 cmd：JumpTaskCmd（jBPM4 中的动作都是基于 Command 模式的）；
参照 TransitionStartActivity.java 的原子操作，定制开发用于跳转的原子操作 JumpTransitionStartActivity;

小结：

jBPM4 中的执行动作都是基于 Command 模式来实现的，因此我们在扩展开发自己的跳转动作时，就可以做到对 jBPM4 本身的代码不做侵入修改而实现。

4. 总结

jBPM4 做为目前应用最广泛的开源工作流产品，有着很好的架构及扩展性，但是由于国外的流程应用与国内的应用存在着一些不同，因此要想让 jBPM4 更好地满足国内的流程应用的需求，就需要做一定的定制开发。而其最大的问题就是没有一个可供业务流程管理员用来进行流程改进的设计器，因此从这一点上，也大大阻碍了其在国内的应用。而本文针对国内的流程应用的一些典型特点进行较详细的分析，并给出基于 jBPM4 的大概的解决思路和办法，但是并没有给出很详细的完全可以 run 的 code，但是笔者认为这些不是最重要的，最重要的是解决问题的思路。而具体的解决方案的 code，请读者关注 jBPM-side ，因为是一个开源项目，因此在此项目中，将会看到完全可以 run 的 code。

作者简介：辛鹏，东方易维 CTO 兼首席咨询顾问，领导研发团队研发了市场上知名的东方易维工作流管理系统 BizFocus-wfms、BizFocus-DEV 业务开发平台。曾在神州数码作为工作流产品经理主持设计了《国家税务总局信息资源整合项目》中的工作流平台的架构、流程规范与实现。对基于 J2EE 的设计研发企业应用软件平台、流程平台有着非常丰富的 7 年的实战经验。今年发起中国开放流程社区（China-OPC/OPUG），成员包括业内的众多知名公司的 BPM 专家。曾发表文章数篇，目前正从事《Head First Process- 深入浅出流程》一书写作，该书将由人民邮电出版社出版。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。