本文将先概要介绍IBM WebSphere BPM和IBM FileNet BPM这两种工作流实现方式，然后逐一介绍若干典型的工作流模式及其具体场景，并给出其分别在WebSphere Integration Developer V6.1.2和IBM FileNet Process Designer的具体实现，同时我们会给出一些具体实现的最佳实践或者建议。

　　IBM WebSphere BPM简介

　　IBM WebSphere BPM使用并扩展BPEL(Business Process Execution Language)来定义工作流。利用IBM WebSphere BPM实现的工作流，其生命周期实际上分为四个阶段：流程建模、流程实现、流程部署和流程的监控管理。每个阶段使用不同的产品。建模阶段使用WebSphere Business Modeler，开发阶段使用WebSphere Integration Developer（以下简称为WID），部署阶段使用WebSphere Process Server（以下简称为WPS），管理监控阶段使用WebSphere Business Monitor 。

　　整个流程开发过程中，四个阶段迭代进行，不断完成对业务流程的优化。关于IBM WebSphere BPM介绍的文章很多，本文主要以开发阶段实现不同工作流模式作为侧重点。

　　IBM FileNet BPM简介

　　IBM FileNet Business Process Manager(BPM)使用并扩展了XML Process Definition Language(XPDL)V2.0来定义工作流，并通过整合IBM FileNet的各种组件和工具（Process Designer， Process Engine， Process Tracker， Process Simulator， Process Analyzer以及Business Activity Monitor），能够对工作流进行设计、实现、运行、跟踪管理、模拟、分析、监控以及优化，其功能涵盖了工作流端到端的完整生命周期。IBM FileNet Process Designer是FileNet提供的基于Web的可视化工作流开发工具，其地位相当于WID。本文中提及到的各种工作流模式在IBM FileNet BPM中的具体实现，都是指在IBM FileNet Process Designer中的实现。因为是基于并扩展了XPDL V2.0，所以Process Designer在工作流实现中所呈现的许多特点，都是与XPDL有密切关联的。

　　多分支（Multiple-Choice）和多汇聚（Multiple-Merger）模式

　　工作流模式简介

　　工作流从某一节点出发，流向若干分支工作流中的几个，并且这些分支是并行的，此为多分支（Multiple-Choice）模式，如图1所示。若干并行的工作流，非同步地汇聚于同一个节点，符合汇聚条件后才能到达下一个节点，此为多汇聚(Multiple-Merge)模式，如图2所示。通常情况下，这两种模式会被结合起来使用，如图3。本文将把这两种模式放在一起讨论。

　　图1. 多分支模式图示

　　图2. 多汇聚模式图示

　　图3. 多分支和多汇聚模式图示

　　具体场景

　　学生办理离校手续，提交离校申请后，必须要等到财务处、后勤室、图书馆和学工部核实通过后，才能正式离校。如图4所示，学生提出离校申请后，便触发了到财务处、后勤处、图书馆以及学工部4个子流程，并且它们是并行的，没有先后之分；待所有4个程序完成后，才能正式办理离校手续。该场景便是一个多分支模式和多汇聚模式结合起来使用的典型场景。

　　图4. 离校申请场景图示

　　在IBM WID V6.1.2中的实现

　　在WID中，可以利用并行活动节点(ParallelActivity)方便的实现多分支(Multiple Choice)和多汇聚(Multiple Merge)功能。并行活动节点是一个特殊的活动节点，包含在该活动节点之内的其他活动节点以并行的方式执行，当流程一进入并行活动节点范畴（scope），流程就会 以多分支并行处理的方式运行，而在汇聚的节点上完成聚合功能。其开发如下图5所示：

　　图5. 离校申请场景图示

　　当学生提交离校申请后，该流程启动。由于使用了并行活动节点，财务、图书馆、后勤和学工部会同时收到离校请求，然后分别处理。只有当四个部门的负责人都处理 好了各自的任务后，流程才会走到“完成离校”这个步骤。实际应用中，“完成离校”步骤可以得到各部门的反馈意见，汇总然后统一处理。

　　建议和最佳实践

　　Link Condition

　　在并行活动节点中，节点和节点之间是通过连线(link)来连接的，我们可以在连线上面定义连接条件(link condition)，只有当返回True的时候，流程才能从该连线上通过。实际上，如果存在多个连线时，流程会从左向右的顺序依次计算，如果多个连线返回都是True，则流程就会以并行的方式处理。在上图中由于每条分支都要执行，所以我们没有设置连接条件，默认为True，即每条分支都要执行。

　　超时处理

　　给出的实现中使用的节点都是人工任务节点，很有可能由于人为的原因使得流程被暂停，如果出现这种情况，一般利用人工任务的功能，使用任务转移(Task transfer)或者提醒(Notification)来处理。

　　在IBM FileNet Process Designer的实现

　　在Process Designer中，多分支总是与多汇聚一起结合使用的。其中，Process Designer使用And-Split Step来实现多分支模式，使用Collector Step来实现多汇聚模式。其实现如下图6所示:

　　图6. 离校申请场景在Process Designer中的实现

　　其中关键步骤是And-Split Step和Collector Step:

　　设置And-Split Step:

　　在分出点“申请离校”这一步骤的Routing属性中，设置Outgoing Routing Information为All true conditions，如下图7所示，使得从该节点流出的分支流程能够支持多选模式。

　　图7. 设置And-Split Step

　　设置Collector Step：

　　在汇聚点“完成离校”这一步骤的Routing属性中，设置Incoming Routing Information为选中Collector Step，如下图8所示，在使得汇聚到该节点的分支流程能够非同步汇聚，从而支持多汇聚模式。

　　图8. 设置Collector Step

　　建议和最佳实践

　　使用Deadline来处理流程的异常

　　在该模式中，因为各个分支的工作流是并行、非同步汇聚的，因此，如果其中的某些分支流程出现异常而未能顺利完成，并且我们又没有做任何异常处理的话，整个主 流程就会走不下去。因此，流程的异常处理在该模式中实现显得非常重要。

　　Process Designer为每个流程（Map）以及Step提供了Deadline机制来处理异常。如果流程当中出现异常，最终表现都为超时未完成，Deadline机制正是让我们可以在超时未完成的情况下，可以自动跳转到指定的子流程（Submap），去执行指定的处理操作，以此来达到异常处理的目的。一般情况下， 在子流程（Submap）中你可以选择：

　　·系统提供的缺省的异常处理流程Malfunction：到达该流程后，系统管理员就可以对该异常的流程进行分析、处理。
　　·系统提供的自动终止该分支流程Terminate：到达该流程后，该分支流程就算自动终止了，如果分支流程是从And-Split节点流出的，那么，相应的Collector Step将不需要再等待该分支的完成。这在多分支与多汇聚模式中显得非常重要，这样，就提供了一种可能：不需要依赖所有的节点顺利完成才能达到汇聚点。
　　·各种自定义的流程：通过流程跳转为异常处理提供了无限可能。例如，我们可以通过跳转到指定委托人能够处理的流程中，实现委托功能；通过回退到前一步来重新开始（这需要把前一步设置为一个子流程），等等。

　　Deadline中相关的设置及其描述，如下图9所示。

　　Complete within：

　　设定时间限制，该时限既可支持静态设定，也可支持动态设定（能够根据流程中的变量及条件动态变化）；时间粒度支持Minute(s)，Hour(s)，Day(s)，Hour(s)。

　　Send Reminder before deadline:

　　设定到达时限前的某个时间点后，通过发送Step Reminder Notification来提醒相应负责人尽快来完成该Step 。

　　Deadline Submap：

　　设定到达时限后，通过指定到达的流程: Malfuntion，Terminate，Workflow(Main Map)， 或者其它的workflows(sub maps)来实现指定的操作。

　　图9. Deadline中相关的设置

 
　　强制回退模式（Arbitrary Cycles）

　　工作流模式简介

　　工作流中的一个节点支持一个或多个活动反复的执行。支持这种模式的工作流特点就是其中的每个节点都可以在一定条件下，任意回退到另一个节点。

　　具体场景

　　某 财政厅预算处理流程。各科室发起当年需要的财政预算，递交给上级各领导进行审批。步骤如下：首先递交给单位经办人的审批，然后是财务主管的审批，最后是预 算处处长的审批，每一级别的审批人都可以打回到上一级别重新审批，预算处处长有权利一上退回，即直接打回给预算递交科室。如下图10所示：

　　图10. 预算处理场景图示

　
　　在IBM WID V6.1.2中的实现

　　流程的回退和跳转是在项目实施中经常会遇到的需求，尽管WPS最大的优势是能够灵活快速的和各种异构系统交互，但是根据笔者的经验，特别在国内的项目往往流程中大部分的环节都是需要人工参与的，换句话说，需要领导的 审批。和其他一些工作流产品比较起来，WPS在回退和跳转方面做得差强人意，毕竟传统的工作流软件底层采用XPDL语言描述流程的，而WPS的流程是通过BPEL语言描述的，两种不同语言的特性也许决定了其不同的特点。

　　目前最新的WID版本是6.1.2，相对于之前旧的版本，WID V6.1.2提供了新的强大功能。下面，我们将针对上面的场景给出目前WID V6.1.2中对回退和跳转的几种不同解决方案。

　　方案1：While Loop + Join Behavior

　　早期的WID往往采用这种方式来实现回退和跳转，采用While节点来实现回退，采用Join Behavior. 来实现跳转。Join Behavior.是在并行活动节点中包含节点的一种属性，我们可以在之上判断返回值，只有当返回值是True的时候，该节点才被执行，否则跳过该节点继续向下执行。场景的实现如下图11所示：

　　图11. While Loop + Join Behavior.场景图示

　　通过WhileLoop确定是否要回退，通过Join Behavior.确定是否该节点将被跳过。Join Behavior.的实现如下图12，选中某节点，查看属性的Join Behavior.项：

　　图12. 查看属性的Join Behavior.项图示

　　如果不修改Join behavior.，则默认返回True ，即每个节点都会被执行，整个流程将会从上到下依次运行。

　　方案2：Cyclic Flow

　　Cyclic Flow是WID V6.1新增加的功能节点，专门实现类似GOTO功能。使用该节点，我们就不用把回退功能都实现在While中。Cyclic Flow和并行活动节点(Parallel Activity)节点非常类似，节点和节点之间还是通过link来连接的，我们可以在link上面定义条件控制流程走向。最大的区别在于，Cyclic Flow中的link可以实现回退，从一个节点转移到任意另外一个节点，当然Cyclic Flow中的节点都是单线程执行的，不能实现Parallel Activity中的并行处理功能。场景的实现如下图13所示：

　　图13. Cyclic Flow场景图示

　　上图中，每个link上的圆点表示上面定义了条件，只有在该条件满足的情况下，才执行到这条分支。由于是单线程执行，所以从某个节点输出的分支中一定要有一条是返回True，如果都是False，那么流程会走向到Otherwise分支，如果Otherwise也没有定义，那么流程会抛出CWWBE0136E错误。如果同时多个link都返回True，那么会执行哪条分支呢？其实这是由Link Evaluation Order决定的，它将执行第一个返回True的分支，如下图14所示：

　　图14. Link Evaluation Order图示

　　方案3 ：Business State Machine（状态机）

　　状态机是实现业务流程的另一种方式，需要指出的是虽然状态机是使用SACL（State Adaptive Choreography Language）来描述流程，但是在部署到WPS上还是会被编译成BPEL 。采用状态机开发业务流程一定要定义好流程的状态点，之后可以在不同状态点之间来回切换，利用状态机的这种特性，再和人工任务结合，可以实现灵活、复杂的 回退或跳转。用状态机实现的场景如下图15所示：

　　图15. Business State Machine（状态机）场景图示

　　从上图可以发现，采用状态机开发流程，在呈现上能够最大程度的和场景业务图类似，业务人员看到状态机图就可以很快理解。在笔者之前一个项目中，WID上的状态机草图是由业务分析人员画出来的，然后开发人员在之上做具体实现。当和人工任务结合使用时，在进入每个状态之前，利用状态机的Entry Event调用人工任务。人工任务在Assembly Diagram上组装，如下图16所示：

　　图16. Assembly Diagram组装人工任务图示

　　通过这样状态机和人工任务结合的方式，我们可以实现不同任务之间的跳转以及人工任务的分配。

　　方案4：Skip and Jump API（6.1.2新功能）

　　WPS V6.1.2提供了一个功能强大的API，可以实现流程中的节点跳转到任意位置。通过调用API，在代码级别对流程的跳转和走向进行控制，而在WID中对流程的开发非常简单，只需要罗列出需要用到的节点就可以了。场景实现如下图17所示：

　　图17. Skip and Jump API场景图示

　　上图可以看出，流程很简单，那么在代码上如何控制呢？这里要介绍WPS V6.1.2新增的几个API：

　　·completeAndJump(AIID aiid， ClientObjectWrapper output，java.lang.String targetActivityName)：完成声明过(claimed)的节点任务并且跳到指定的节点，其中完成任务的响应放在output变量中。
　　·forceCompleteAndJump(AIID aiid， ClientObjectWrapper output， java.lang.String targetActivityName)：不管节点任务是否声明过，强行完成节点任务，并跳到指定的节点，完成任务的相应放到output变量中。
　　·skip(java.lang.String aiid)：跳过当前任务，不做任何执行，流程继续执行。
　　·cancelSkipRequest(java.lang.String aiid)：取消之前的任务跳过请求，恢复流程状态到跳转之前。
　　·当需要流程从某个节点跳转时，我们只需要知道当前节点的activity id以及目标的activity的名称就可以了。这种方式做到了最大的灵活性。目前的WPS V6.1.2版本只适用于同一个流程中的节点之间的跳转，如果是主流程和子流程的情况，节点之间不能相互跳转。

　　建议和最佳实践

　　选用适合的实现方式

　　上述可以看出WPS提供了众多实现流程回退和跳转的技术方案，那么应该选用哪种呢？既然都可以实现跳转功能，那么可以从非功能性上考虑，下面表1给出了不同实现技术方案的比较。

　　表1. 不同实现技术方案比较

　　需要指出的是，以上四种方法目前都不直接支持主流程和子流程之间的相互跳转。

　　在IBM FileNet Process Designer的实现

　　在Process Designer中，同一个流程中的每一个step ，在一定条件下，都可以通过route连接到另一个step ，因此在同一个流程中，强制回退模式的实现是非常自然的。该典型场景的实现如下图18所示，它看起来几乎与业务状态图一致，这一点跟业务状态机类似。

　　图18. 预算处理场景在Process Designer中的实现

　　但是，对于如下特殊情况，强制回退的实现并不支持，或者并不直接支持，需要进行特别的设置：

　　通过And-Split step后的step，在没有经过Collector（And-Join）step的情况下，是不能回退到And-Split step的，如下图19所示：

　　图19. 没有经过Collector step，不能回退到And-Split step

　　对于某个step，在没有经过Collector(And-Join)step对应的And-Split step的情况下，是不能直接回退或者前进到该Collector（And-Join)step的，如下图20和图21所示：

　　图20. 情况1：没有经过And-Split step，不能回退到And-Join step

　　图21. 情况2：没有经过And-Split step，不能前进到And-Join step

　　与WID类似，Process Designer同样不直接支持不同流程（包括父流程与子流程）中节点之间相互跳转。但是，我们仍然有办法通过间接的途径实现。例如在下面的示例中，我们希望能够实现从主 流程中的afterMap step跳转到子流程中（subMap）中的Step2，如下图22所示：

　　图22. 从主流程的step跳到子流程的step图示

　　为了实现这个跳转，我们可以采取设置标志变量的方式来实现。

　　在父流程中预先设置好标志变量。以上面的流程为例，如果要实现该跳转，意味着子流程中将会有两种情况，一是从beforeMap进入后，子流程会先进入Step1；二是从afterMap进入，直接到达Step2。那么，我们需要设置两个标志变量，jump2step1和jump2step2。在beforeMap的Assignments Tab的Before Execution中设置jump2step1为true，jump2step2为false；在afterMap的Assignments Tab Before Execution中设置jump2step1为false，jump2step2为true。如下图23所示：

　　图23. 在beforeMap和afterMap中设置标志变量

　　在子流程中，根据标志标量来进行条件判断，实现不同step的跳转。到Step1的条件是jump2step1为true；到Step2的条件是jump2step2为true。如下图24所示：

　　图24. 根据标志标量来进行条件判断，实现不同step的跳转

　　需要特别指出的是，子流程中的StartStep必须是一个General step，这样它才能够不需要人工干预直接根据条件到达下一步。

　　会签模式( Vote )

　　工作流模式简介

　　在业务流程中，某项任务需要由多人共同进行审批，根据每个人的批复结果，并依据一定的规则（如全数通过、按比例通过或否决等）确定是否被批准，这种业务常常被称之为会签模式。

　　具体场景

　　某人投稿，稿件需要多个专家审阅，如果同意的专家个数大于不同意的专家个数，则稿件被录用，反之则不被录用。

　　在IBM WID V6.1.2中的实现

　　有两种方法可以实现该模式：Event Handler和ForEach节点。其中ForEach是WID V6.1.2新增加的特性。

　　方案1 ：ForEach

　　ForEach节点实际是while节点的一个增强，允许多个分支并行的处理，提供了额外机制，允许当某一些分支达到要求时就跳出循环，继续执行。使用ForEach实现场景如下图25所示：

　　图25. ForEach实现场景图示

　　由于审批的作者人数是动态变化的，在进行审批之前，需要初始化变量，把给定的审批人员名单输入到初始化的数组里。在For Each节点我们做如下图26所示设置：

　　图26. 设置ForEach节点

　　Execution of iteration设置成并行处理，如果设置为Sequential，那么就和while节点功能一样了。Iteration里指定好用于迭代的初始化数组。Early Exit Criterion是可选的，在当前场景下表示当有3个审批员审批过后，就可以不再接受审批，其他初始化好的人工任务都会被系统删除掉。最后在统计结果部分，计算审批结果，当同一通过的人数大于不同意通过的 人数，文章可以被录取，实现代码如下图27所示

　　图27. 实现代码截图

　　方案2：Event Handler

　　Event Handler必须依附于某一个Scope才能存在，一旦该Scope生命周期结束，那么Event Handler也将不存在。通过Event Handler暴露出的接口，正在运行的流程实例可以接收到外系统激发的事件，改变流程本身Scope内的变量。用Event Handler实现场景如下图28所示：

　　图28. Event Handler实现场景图示

　　需要注意的是在当流程执行到SetResultAndDecrementCounter活动时，一方面SetResultAndDecrementCounter需要将审阅结果从流程局部变量myReviewResult复制到流程全局变量results中；另一方面由于已经完成了一次审批，所以流程全局变量activeReviews计数器值也会递减，这两方面的活动都将修改全局变量。如果当外系统有多个事件被激发，同时到达Event Handler会出现同时修改流程实例全局变量的情况，造成流程实例全局变量的不一致，因此需要将该活动的transactional behavior.属性设置为值RequiresOwn。使得此活动在单独的事务中执行，实现事务的隔离。如下图29所示：

　　图29. transactional behavior.属性设置为值RequiresOwn

　　在IBM FileNet Process Designer的实现

　　运用IBM FileNet BPM的以下两个特点，我们可以很简便地实现该会签模式的场景：特点1 ：如果某个step的Step Destination设置为Participants，并添加上了相应的参与成员或成员组，那么这个step就变成了一个需要人工参与的任务。当工作流到达这样一个step的时候，每一个参与成员都能够访问到这个任务，并且当且仅当所有参与者都完成了这个任务，才有可能走到下一步。特点2 ：对于每一个人工任务，可以为其设置相应的Responses，例如Reject和Approve，这样参与人员就可以通过选择Responses来参与这个任务的决策；另一方面，在影响流程走向的Route设置中，我们可以在Conditional Routing的Condition设置中，针对Responses来设置相应的条件组合。待所有参与者都完成了该任务后，FileNet再根据设定的条件，决定流程的走向，例如条件ALL（Approve）就意味着必须要所有的参与者都选择了Approve才能走向该Route，而条件COUNT(Approve)>COUNT(Reject) 则意味着选择Approve的人数多于选择Reject的人数才能走向该Route，而这正是这个场景中需要的条件。基于以上特点，该会签模式的场景可以实现如下图30所示：

　　图30. 会签场景在Process Designer中的实现

　　关键设置如下：

　　Review step的Participants设置为：ReviewerGroup，如下图31所示：

　　图31.为step设置Participants为某group

　　需要特别指出的是，因为我们在设计阶段并不知道具体的参与人员，所以我们将其设置为一个Participant Group，暂定为ReviewerGroup。这样一来，我们可以在运行时通过调整该Group的成员来动态地将这个任务分发给具体的参与人员。

　　通向Approve的route1条件是：COUNT(Approve)>COUNT(Reject)，如下图32所示：

　　图32. route1条件

　　通向Reject的route2条件是：COUNT(Reject)>COUNT(Approve)，如下图33所示：

　　图33. route2条件

　　总结

　　综合以上若干模式的实现对比，我们可以发现，WID作为流程开发工具对流程的实现十分灵活、多样，开发好的流程部署到WPS服务器中也很方便，开发人员有较大的自由度，但是流程实现起来也比较复杂；而FileNet的开发工具Process Designer的实现方式比较单调，开发人员可发挥的余地不大，但是实现起来比较简单直接。从中，我们也能够体会到两个工作流产品的差异化。

　　总的来说，无论是IBM WebSphere BPM还是IBM FileNet BPM，两者对工作流模式的支持都比较全面，但是由于各自底层描述流程的语言的不同，分别是BPEL和XPDL，导致了在实现上各有侧重点：

　　BPEL的优势体现在集成上，当所构建的流程需要串接各异构系统时，WebSphere BPM最适合。但是，由于BPEL语言本身的局限性，WebSphere BPM在处理任意循环的工作流模式时，略受限制，没有FileNet BPM方便。

　　XPDL规范在中国被认可，相对BPEL更为成熟，这点在人工任务上尤其明显。XPDL对人工任务做了详细的设计，其可用性和灵活性更是在国内市场久经考验（考虑到国内市场的流程几乎不可能没有人工任务）。反观BPEL规范，本身并没有任何关于人工任务的内容，在去年八月份才发布出了第一个BPEL4People的规范，目前业界对该规范也是褒贬不一。BPEL4People规范出现之前各家公司的BPEL工作流引擎也是各自有各自的实现，要做到统一还有很长的路要走。

　　从发展上看，XPDL相对成熟，但是已到暮年；而BPEL还在发展之中，是未来的发展趋势。