工作流控制模式-高级分支和同步模式14种
版权声明：工作流模式版权归 Workflow Patterns 组 织 ( http://www.workflowpatterns.com ) 所 有 。 经 Workflow Patterns授权，中文简体版由辛鹏和荣浩翻译。未经译者书面许可，不得将该中文简体版用于商业目的。
高级分支和同步模式使得各个工作流产品在技术水平上拉开档次，技术上实现比较复杂。高 级分支、同步模式共有14种，如图A-8所示。
图 A-8 高级分支和同步模式
- 多选择:分支分裂为两个或多个后续分支，当分支执行完毕后会选择触发后续分支的一 个或多个同时执行，M选N。
- 结构化同步合并:两个或多个分支合并为一个后续分支，只有当所有被实际触发的分支 都执行完毕后才会触发后续分支的执行。
- 多合并:两个或多个分支合并为一个后续分支，每个实际触发的分支执行完毕后都会触 发后续分支的执行。
- 结构化鉴别器:两个或多个分支合并为一个后续分支，第一个执行完毕的分支触发后续 分支的执行，其他分支继续执行，但是被忽略，执行完毕后不再触发后续分支。
- 阻塞鉴别器:两个或多个分支合并为一个后续分支，第一个执行完毕的分支触发后续分 支的执行，其他分支继续执行，但是被忽略，执行完毕后不再触发后续分支。如果分支 有多个执行线程，那么在第一个执行线程被合并之前，后续线程被阻塞。
- 取消鉴别器:两个或多个分支合并为一个后续分支，第一个执行完毕的分支触发后续分 支的执行，其他分支取消执行。
- 结构化部分合并:两个或多个分支合并为一个后续分支，假设流程实例中实际触发的分 支为M个，第N个实际触发的分支执行完毕后触发后续分支的执行，N < M，其他分支继 续执行，但是被忽略，执行完毕后不再触发后续分支。
- 阻塞部分合并:两个或多个分支合并为一个后续分支，第N个实际触发的分支执行完毕后 触发后续分支的执行，其他分支继续执行，但是被忽略，执行完毕后不再触发后续分支。 如果分支有多个执行线程，那么在第一个执行线程被合并之前，后续线程被阻塞。
- 取消部分合并:两个或多个分支合并为一个后续分支，第N个实际触发的分支执行完毕后 触发后续分支的执行，其他分支取消执行。
- 泛化同步:同步模式的泛化，两个或多个分支合并为一个后续分支，等待所有分支都执 行完毕后，后续分支才会触发，支持多个分支执行线程的同时合并。
- 本地同步合并:两个或多个分支合并为一个后续分支，该模式基于本地数据来决定需要 同步的分支以及时机。
- 通用同步合并:两个或多个分支合并为一个后续分支，当所有被实际触发的分支都执行 完毕并且未来也不会再被触发后才会触发后续分支的执行。与结构化同步合并的区别在 于没有前提条件:不需要结构化建模，也不需要执行线程安全。
- 多线程合并:在流程的一个特定点，将一个分支的多个执行线程合并为一个执行线程。 合并线程的数量在定义期确定。
- 多线程分裂:在流程的一个特定点，为一个分支初始化多个执行线程。执行线程的数量 在定义期确定。
多选择(WCP_6: Multi-Choice)
描述
分支分裂为两个或多个后续分支，当分支执行完毕后，根据用户决策或流程数据选择触发后 续分支的一个或多个同时执行，即M选N模式(多选多)，后续有M个分支，根据运行时情况选择 N个分支进行执行，1 <= N <= M。如图A-9所示，当110接到报警电话后，会根据情况，如是否有 火情、是否有伤亡，选择是否同时出动消防和救护。
图 A-9 多选择
同义词
条件路由、多选、OR-split。
应用
从去年到今年，针对可能出现的重大灾害和突发事件，很多地方都建立起了联合紧急处理预 案，围绕一个目标建立起来一整套处理机制，这套机制打破了原有职能部门的界限，减少了不必 要的协调成本，是资源按照目标进行重组的一种形式。
结构化同步合并(WCP_7: Structured Synchronizing Merge)
描述
两个或多个分支合并为一个后续分支，只有当所有被实际触发的分支都执行完毕后才会触发 后续分支的执行，分支需要同步。如图A-10所示，当110接到报警电话后，根据情况同时出动了 警察和救护，当所有任务都执行完成后会进行出警情况的总结汇报。
图A-10 结构化同步合并
前提条件
该模式存在两个前提条件:结构化和执行线程安全。
- 结构化:在流程定义里必须存在一个OR-split网关与该OR-join网关对应，OR-join网关合 并从OR-split网关分裂出来的分支，在OR-split网关和OR-join网关之间的分支不允许存在 任何的分裂和合并网关，如果存在，必须配对出现;
- 执行线程安全:在一个流程实例里，OR-join网关激活重置之前(合并完成当前所有分支 执行线程之前)，不允许OR-split网关再次激活产生需要合并的分支执行线程。
多合并(WCP_8: Multi-Merge)
两个或多个分支合并为一个后续分支，每个实际触发的分支执行完毕后都会触发后续分支的 执行，如图A-11所示。项目立项后，项目经理需要申请服务器和申请项目人员，不管是申请服务 器还是申请人员都需要经过一次部门经理的审批。
图A-11 多合并 图A-11的流程定义等效于图A-12所示的流程定义。
图A-12 经理需要分别审批两次
应用
多合并模式被用来简化建模。在存在很多并发分支且后续活动相似的情况下，这种模式能够 减少流程定义的复杂度，类似于代码里的DRY原则。但应用该模式后，分支会产生多个执行线程， 导致后续的合并节点处于一种线程不安全的状态。
结构化鉴别器(WCP_9: Structured Discriminator)
描述
两个或多个分支合并为一个后续分支，第一个执行完毕的分支触发后续分支的执行，其他分 支继续执行，但是被忽略，执行完毕后不再触发后续分支。如图A-13所示，员工请假申请将同时 发送给项目经理和直属领导审批，但只要一个审批通过即可。
图A-13 结构化鉴别器
前提条件
该模式存在两个前提条件:结构化和执行线程安全。
- 结构化:在流程定义里必须存在一个AND-split或OR-split网关与该Discriminator网关对应， Discriminator网关合并从AND-split或OR-split网关分裂出来的分支，在AND-split或OR-split 网关和Discriminator网关之间的分支不允许存在任何的分裂和合并网关，如果存在，必须 配对出现。
- 执行线程安全:在Discriminator网关被激活且未重置的情况下，不允许前续分支再次产生需要合并的执行线程。
阻塞鉴别器(WCP_28: Blocking Discriminator)
两个或多个分支合并为一个后续分支，第一个执行完毕的分支触发后续分支的执行，其他分 支继续执行，但是被忽略，执行完毕后不再触发后续分支。该模式的关键词是阻塞，如果分支有 多个执行线程需要合并，那么在第一个执行线程被合并之前，后续线程被阻塞。与结构化鉴别器 模式相比，该模式通过自身的实现机制保证Discriminator网关处于线程安全的状态。
如图A-14所示，工程招标预审流程，投标公司根据招标公告向招标公司报名，购买资格预审 文件，接下来，根据资格预审文件要求，完成资格预审申请文件的制作，然后在规定时间内交到 招标公司，进行预审。招标公司进行资格的预审，只要一个评委评审完成，我们即通知评审结果。 我们使用多实例子流程对投标公司的投标流程进行建模;使用条件中间事件:没有进行中的评审 活动，保证每次只对一家公司的申请进行审核。
图A-14 阻塞鉴别器
取消鉴别器(WCP_29: Canceling Discriminator)
描述
和结构化鉴别器模式相似，第一个实际触发的分支执行完毕后触发后续分支的执行，区别是， 其他分支不再继续执行，被取消。如图A-15所示，员工请假申请将同时发送给项目经理和直属领 导审批，但只要一个审批通过即可，审批通过后我们发送审批通过的信号事件，另外一个进行中 审批活动捕获该信号事件然后取消活动的执行。
图A-15 取消鉴别器
结构化部分合并(WCP_30: Structured Partial Join)
描述
两个或多个分支合并为一个后续分支，假设流程实例中实际触发的分支为M个，第N个实际 触发的分支执行完毕后即触发后续分支的执行，N <= M，其他分支继续执行，但是被忽略，执 行完毕后不再触发后续分支。如图A-16所示，每年的晋级面试需要先提出申请，申请将发给两位 通道评委评审，如果是升高级职称则还需要发送给部门经理评审，只需要两个人完成了评审，评 审即完成，评审结果里只要有一个不通过则申请晋级不通过。
该模式是结构化鉴别器模式的泛化，在结构化鉴别器模式里，N=1。
图A-16 结构化部分合并
阻塞部分合并(WCP_31: Blocking Partial Join)
两个或多个分支合并为一个后续分支，假设流程实例中实际触发的分支为M个，第N个实际 触发的分支执行完毕后即触发后续分支的执行，N<=M，其他分支继续执行，但是被忽略，执行 完毕后不再触发后续分支。该模式的关键词是阻塞，如果分支有多个执行线程需要合并，那么在 第一个执行线程被合并之前，后续线程被阻塞。与结构化部分合并模式相比，该模式通过自身的 实现机制保证Partial-join网关处于线程安全的状态。
如图A-17所示，工程招标预审流程，招标公司进行资格的预审，需要两位评委完成评审，评 审才结束，评审结果里只要有一个不通过则预审不通过。我们使用多实例子流程对投标公司的投 标流程进行建模;使用条件中间事件:没有进行中的评审活动，保证每次只对一家公司的申请进 行审核。
图A-17 阻塞部门合并
取消部分合并(WCP_32: Canceling Partial Join)
和结构化部分合并模式相似，第N个实际触发的分支执行完毕后触发后续分支的执行，区别 是，其他分支不再继续执行，被取消。
如图A-18所示，工程招标预审流程，招标公司进行资格的预审，需要两位评委完成评审，评 审才结束，评审结果里只要有一个不通过则预审不通过。剩下一位评委的评审活动被取消。
图A-18 取消部分合并
泛化同步(WCP_33: Generalized AND-Join)
两个或多个分支合并为一个后续分支，等待所有分支都执行完毕后，后续分支才会触发。与 同步模式的不同:允许与Gen.AND-join网关连接的前续分支产生多个执行线程，支持多个分支执 行线程的同步合并。
如图A-19所示，新员工入职时，先去人力资源部报道，接下来填写入职资料和签订合同，于 此同时，IT部门帮忙开通RTX邮件开发环境权限、初始化机器。初始化机器是一个多实例子流程， 包含了多项工作:开通RTX、开通邮件、开通开发环境、安装软件、打包机器送至工位。只有这 些工作都完成了，员工才能收拾工位开始工作。我们将IT部门的工作建模为多实例子流程，每一 项工作都产生一个执行线程。
图A-19 泛化同步
本地同步合并(WCP_37: Local Synchronizing Merge)
如图A-20所示，公司产品要进行市场推广，首先是确定推广策略:电视、广播和网站选择哪 10 些渠道投放广告。如果选择电视和广播渠道，那么这两个渠道需要同步推广;如果选择了网站渠 道，那么需要决定是否与电视广播渠道同步推广。我们是用条件事件决定需要同步的工作和时间。
图A-20 本地同步合并
通用同步合并(WCP_38: General Synchronizing Merge)
描述
两个或多个分支合并为一个后续分支，当所有被实际触发的分支都执行完毕并且未来也不会 再被触发后才会触发后续分支的执行。该模式没有前提条件，不要求结构化，也不要求执行线程 安全。
通用同步合并、结构化同步合并和本地同步合并模式解决的问题是一致的:对实际触发的前 续分支进行同步合并。区别在于实现同步合并的机制:结构化同步合并通过建模的结构化判断需 要同步的分支，本地同步合并基于本地数据分析实现同步合并，通用同步合并通过对流程实例的 全面分析确定不再有需要合并的分支，触发流程的向后流转。
多线程合并(WCP_41: Thread Merge)
描述
在流程的一个特定点，将一个分支的多个执行线程合并为一个执行线程。合并线程的数目在 定义期确定。
如图A-21所示，公司计划对项目管理现状进行一次调研，将调查问卷发送到1000名员工手中， 当所有人反馈后对反馈情况进行分析。
图A-21 多线程合并
我们使用多实例子流程对员工反馈情况进行建模，如图A-22所示，启动数量表明我们需要 1000名员工的反馈，为每位员工启动了一个子流程实例;多实例循环顺序为并行，表明这些子流 程实例并行执行;流转条件是All，表明需要将所有子流程实例都合并即所有员工都提交反馈后 再触发后续分析活动。
图A-22 使用多实例子流程合并多线程
多线程分裂(WCP_42: Thread Split)
描述
在流程的一个特定点，为一个分支初始化多个执行线程。执行线程的数量在定义期确定。 如图A-23所示，公司计划对项目管理现状进行一次调研，将调查问卷发送到100名员工手中，
一旦有反馈就对反馈情况进行分析。
图A-23 多线程分裂
我们使用多实例子流程对员工反馈情况进行建模，如图A-24所示，启动数量表明我们需要100 名员工的反馈，为每位员工启动了一个子流程实例;多实例循环顺序为并行，表明这些子流程实 例并行执行;流转条件是One，表明任何一个子流程实例完成即任一员工有反馈后都会触发后续 的分析活动。
图A-24 使用多实例子流程产生多线程
小结
业务人员所建立的流程模型很难被直接执行，原因在于这些模型是对业务的直接描述，流程 存在的目的在于沟通而不是机器执行。在本节所描述的模式里，很多模式实现起来非常困难，比 如说非结构化的模式、非执行线程安全的模式，但是这些情况在实际业务中非常常见，原因就在于这些业务的处理者是人，人能够基于整个流程的执行情况具体情况具体分析，而工作流引擎则 必须基于明确的输入进行计算，此时就需要系统分析人员在业务语言与计算机语言间进行转换。 没有工作流产品能对上述所有模式进行支持，都有建模的各种约束。选择工作流产品时，很重要 的一点就是看其所支持的模式是否与当前的业务相契合或者说做到最大程度上的适配。
同时，在应用工作流产品时，通过在流程定义里增加信息能够显著减少引擎运行期计算的难 度，例如在应用结构化的合并模式时，我们在定义合并网关时就将与之对应的分裂网关信息保存 到了它的属性定义中，避免运行期的计算。
