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。
| 
