希望之路

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。本文将把这两种模式放在一起讨论。

具体场景

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

在 IBM WID V6.1.2 中的实现

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

其中关键步骤是 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) 来实现指定的操作。

强制回退模式（Arbitrary Cycles）

工作流模式简介

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

具体场景

某 财政厅预算处理流程。各科室发起当年需要的财政预算，递交给上级各领导进行审批。步骤如下：首先递交给单位经办人的审批，然后是财务主管的审批，最后是预 算处处长的审批，每一级别的审批人都可以打回到上一级别重新审批，预算处处长有权利一上退回，即直接打回给预算递交科室。如下图 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 给出了不同实现技术方案的比较。

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

在 IBM FileNet Process Designer 的实现

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

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

• 通过 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 图示
  
  
  

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

  1. 在 父流程中预先设置好标志变量。以上面的流程为例，如果要实现该跳转，意味着子流程中将会有两种情况，一是从 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 中设置标志变量
     
     
     
  2. 在子流程中，根据标志标量来进行条件判断，实现不同 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 所示：

关键设置如下：

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

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

2. 通向 Approve 的 route1 条件是： COUNT(Approve)>COUNT(Reject)，如下图 32 所示：
   
   图 32. route1条件
   
   
   
3. 通向 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 还在发展之中，是未来的发展趋势。