―Childe Zhao，
http://www.workflow-fortune.com
－译自
http://tmitwww.tm.tue.nl/research/patterns/
欢迎阅读工作流原型模式。工作流原型模式可用于检验工作流服务器的表现能力
,即工作流如何实现你所需的业务需求。
本文档所含的模式由
Wil van der Aalst、Bartek Kiepuszewski、Arthur ter Hofstede 及 Alistair Barros收集并成档。且对下属工作流管理系统进行了评估： COSA、FLOWer、Domino Workflow、Eastman、Visual Workflow、Forte Conductor、Meteor、Mobile、 MQSeries/Workflow、Staffware、Verve Workflow、I-Flow、InConcert、 Changengine, 以及SAP R/3 Workflow.有关连接见模式、产品评测及文档。
2002-12于北京
1、基本控制模式
- 顺序（Sequence ）-- 顺序执行任务;；
- 并行分叉（Parallel Split） -- 并行执行任务；
- 同步（Synchronization）-- 同步两个并行执行的线程；
- 排它选择（Exclusive Choice） -- 从多个路径种选择一个执行；
- 简单合并（Simple Merge） -- 合并两个可选执行路径。
2、高级分支和同步模式
- 多路选择（Multiple Choice） -- 从多个可选路径中选择几路执行；
- 多路合并（Multiple Merge） -- 无同步合并多个执行路径；
- 路径鉴别（Discriminator） -- 无同步合并多个执行路径，然并发任务仅执行一次；
- M并N（N-out-of-M Join） -- 合并多个执行路径，实现部分同步，并发任务仅执行一次。
- 同步连接（Synchronising Join） -- 合并多个执行路径，若多路执行则同步；若一路执行则简单合并（Simple merge）。
3、结构化模式
- 任意循环（Arbitrary Cycles） -- 执行工作流图时无任何环路限制；
- 绝对终止（Implicit Termination） -- 若无事可做时则终止。
4、多实例调用模式
- 同一任务多实例在流程设计时已知实例数目；
- 同一任务的实例数目在运砖时某刻才能确定；
- 同一任务的实例数目无法确知；
- 同一任务多实例并要求同步。
5、基于状态的模式
- 延期选择（Deferred Choice） -- 执行两个可选进程之一，选择执行进程是隐含的；
- 交叉并行路由（Interleaved Parallel Routing） -- 随机执行一个任务但不并行；
- 里程碑（Milestone） -- 直到达到某个里程碑方激活一个任务。
6、取消模式
- 取消任务（Cancel Activity） -- 取消（或禁止）一个激活任务；
- 取消流程（Cancel Case） -- 取消（或禁止）一个流程。
1、顺序（Sequence）
顺序模式是最基本的工作流模式。当两个或更多任务间存在依赖关系时需用顺序模式――在前一任务完成之前，本任务不能执行（调度）。
在同一流程中，一个任务在另一任务完成后才能被激活。
顺序路由,串行路由。
· 任务“发送账单”在任务“发送货物”之后才能执行。
- 在检索到客户端文件后才能计算保险索赔。
- 任务“累计航行里程”在任务“预订航班” 后才能执行。
顺序模式用于对工作流程中连贯的步骤建模，所有的工作流管理系统都支持该模式。
2、并行分叉（Parallel Split）
当两个或更多任务需并行执行时需要并行分叉。除不要求任何程度并行支持的系统外大多数工作流引擎都较易支持并行分叉。
在流程中，需将单进程的某控制点分成可并行执行的多进程控制，于是允许任务同时执行或以任何顺序执行。
与分支，并行路由, 分叉。
n
任务“付款”的执行，使得任务“装船”和“通知客户”同时执行能够。
n
注册“保险索赔”后，两个并行子流程被触发：一个是“校核顾客符合的条款”，另一是评估实际损害。
所有的工作流引擎都可能支持并行任务。可区分两种基本的方法：显性与分叉和隐性与分叉。支持显性与分叉结构的工作流引擎（诸如：Visual Workflo）可定义一激活即使能的有多个流出转移的路由选择节点。支持隐性与分叉的工作流引擎(如MQSeries/Workflow) 不提供特殊的路由选择结构――每个任务可有多于一个的流出转移，且每个转移都有相关条件。为达到并行执行的目的，流程设计者须保证流出转移的多个相关条件为真(典型的方法是将条件置为空)。
3、同步（Synchronization）
当两个并行任务都完成后下一任务才能开始执行时需要同步。
流程中，多个并行子流程
/任务在某点汇聚成一个单进程，从而同步多个进程。
与结合，结合，同步。
· 任务“存档”在“送票”和“收费”两个任务完成后才能使能。
· “保险索赔”在“核定条款”和“估算实际损伤”后才能计算。
本模式极易为所有支持并行运行的工作流引擎所支持。值得注意的是，对于某些实现，“与连接”的错误应用可能易于造成死锁。
1.
所有可用的工作流引擎支持本模式。典型的是具有可用的同步结构。在某些罕见的情形下，通过对一个多入口的任务定义特殊的开始条件实现同步。
2.
当具有显性的同步结构时，典型的特征是同步器应具有多于一个入口，却只有一个出口。例如，若任务
C之前有一以任务A和任务B为输入的同步器，如果已有任务A的实例，当它执行完毕时，同步器将不作处理，而是等待任务B的实例的终止。 另一方法是，在等待任务B时，简单地明了任务A的“额外”实例的数目，然后用相应的任务B的实例匹配它们。
4、排它选择
在流程的某一点，依据一个结果或流程控制数据, 从多个分支路径中选定一个路径。
异或分叉, 条件路径, 开关, 决议。
任务“计算赔偿金”后继是两个任务“支付赔偿金”和“联系顾客”中的任一个
。
1.
类似于“并行分叉”，有两种基本策略――某些工作流引擎提供显性的结构以实现“排他选择”模式
(譬如Staffware, Visual WorkFlo), 但是在其它工作流引擎 (MQSeries/Workflow, Verve)中，流程设计者不得不选择转移条件仿效“排他选择”。
5、简单合并
欲将选择执行的路径合并成一个路径需用“合并”模式。
在流程中某点，需将两个或更多可选分支聚合而不同步；换言之，“合并”在任一入口连接触发时被触发。
异或连接,，异步连接，合并。
任务“存档索赔”在任务“支付赔偿金”和“联系顾客”任一之后使能。
1、多路选择（Multiple Choice）
排它模式采取的是只有一个可选项被选定并执行，亦即它对应于排它或。有时，要用到从给定的一组选项中选定多项（而非一项）的结构，于是，引入（非排它）多重选择。
在工作流过程的某点，依据判定或工作流控制数据，选择一个或多个分支。
条件路径,选择, 或分叉。
执行任务
evaluate_damage之后任务
contact_fire_department或contact_insurance_company被执行，至少其中之一被执行，但是，也可能两者都被执行。
很多工作流管理斜体中，转移上可以定义条件。这些系统中可直接实现OR-分叉，但是有几种工作流管理系统不能在转移上设置条件，仅提供纯粹的AND-split和XOR-split建模元素 (例如Staffware).。
1.
正如所述，对于可在转移上设置条件的工作流管理系统
(诸如Verve, MQSeries/Workflow, Forte Conductor)实现多重选择是直截了当的,流程设计者只需简单地设定每一转移的条件即可。值得注意的是多重选择是并行分叉和排它选择的泛化。
2.
多重选择的实现需要将
并行分叉和
排它选择二者结合起来。每一可能的分支由一前置的
异或分叉基于控制数据决定，或者激活该分支，或者跳过它。所有
异或分叉由一
与分叉激活，该
与分叉也可用于设置
异或分支所用的控制数据。
3.
另一与上述方案类似的方案是颠倒与分叉和异或分叉的结构顺序。每组可激活的并行分支，加入一与分叉。所有与分叉由一前置的异或分叉激活适当的与分叉。注意并非所有的分支组合可行的。所以本方案将导致简单的工作流定义。
本模式旨在阐述简单合并模式中提及的问题, 即当一个合并中有多于一条流入转移被激活时的情形。
多路合并是指在流程中某点，两条或更多分支无同步再收敛。若多于一个分支被激活,可能同时被激活,任务后的合并对于每条流入的激活分支都响应一次(亦即，在上图中，D将被实例化两次)。
有时两个或更多并行的分支共享一个终点。此类情况的翻版是(可能复杂的)流程中每一分支可用一个多路合并。一个简单的例子是两个并行运行的任务
audit_application及
process_application ，二者都后接任务
close_case.。
大多数工作流引擎 (诸如Staffware, HP Changengine, I-Flow)若一个任务的第一个实例仍在运行时，将不产生第二个实例。Verve Worflow 和Forte Conductor例外。
如果
多路合并不是
循环(loop)的一部分, 作为一个任务不能创建多于一个实例的语言的通用设计模式是在工作流模型中复制该任务。如果
多路合并是
循环
(loop)的一部分, 典型的情况是
多路合并其后所接的任务的数目在设计（建模）时未知。关于这个问题的典型方案，见有关多实例模式。
3、路径鉴别器（Discriminator）
本模式可以看作多路合并模式的逆。其语义实现是合并后仅一个任务应被实例化。
路径鉴别器是指在流程的某点，激活后续任务之前等待许多流入分支的完成。从它开始之时起，等待所有剩余分支的完成并“忽略”它们。一旦所有的流入分支都被触发，它使自己复位，以便可被再次触发
· 一篇论文需被送给外部审阅者。如果两个评价皆为正，则论文被接受；如果第一个评价为负，应提示作者，不必等待第二个评价。
· 为缩短查询响应时间, 一个复杂的查询通过internet被送往两个数据库。第一个给出结果后流程将继续流转，第二个结果将被忽略。
一些工作流引擎(如Staffware, HP ChangeEngine, I-Flow)，若任务的第一个实例仍在运行，则生成该任务的第二个实例。然而，这不能提供一个路由鉴别解决方案，因为只要该任务的第一个实例完成，第二个实例将被创建。
1.
Verve中有一个特殊的结构实现路由鉴别语义。
2.
支持
定制触发器的产品可实现
路由鉴别功能
(详见M中选N)
3.
所有其它的工作流引擎很难或无法实现路由鉴别功能。通用的设计模式是采用
取消任务模式。只要路由鉴别后接任务的第一个实例被创建
, 仍未完成的流入分支的任务可被取消，如此第二个实例将不会被创建。模式见下图。本方案的问题是若任务B和C同时完成, 任务D 可能仍将执行两次。此外, 路由鉴别的原有语义是允许B 和C 都完成。本方案任务B 或C 将被取消。
下述模式可视作基本路由鉴别的泛化，意欲从M个流入转移中同步N个线程。
M中选N合并是指流程的某点M 条并行路径聚合到一点，只要其中N条路径完成则激活后续任务，所有其它剩余路径的完成应被忽略。类似于路由鉴别,只要所有流入分支被触发,则该合并使自己复位，以便可被再次触发。
部分合并, 鉴别器, 定制合并。
一篇论文需送往三个外部的审阅者。收到两个评审后继续处理论文，第三个评审将被忽略。
大多数工作流产品不提供结构以直接实现M中选N合并。
1.
某些工作流引擎 (如Forte Conductor) 提供对
定制触发器的支持。对于具有多于一个流入转移的任务可定义
定制触发器，它定义条件，典型地使用某些内部脚本语言, 当条件计算为真时，激活该任务。这样的脚本很容易用于定义与M中选N等价的语义。 该方法的缺点是采用定制触发器语义的合并，不仔细检验触发器脚本是无法定义的，亦将导致模型的不当和难于理解。
2.
通过By comb融合路由鉴别模式和同步模式（
Discriminator 与
Synchronisation ），可达到同样目的，尽管工作流定义（或模型）会变得大而复杂。下图所示为一3中选2合并的例子。
现代的工作流产品很容易处理多路选择模式。不幸的是，对应于合并（Or－Join）结构的实现却极度困难。OR-join应具有同步并发流及合并可选流的功能。困难在于决定何时同步，何时合并。同步可选流导致可能的死锁，合并并发流可能导致不期望的任务多重执行。
流程中某点多条路径聚合成一个线程，若多于一条路径触发，则活动线程需同步；若仅有一条路径触发，则可选分支应再收敛，无需同步。
拓展多重选择模式中的例子，任务
contact_fire_department 及
contact_insurance_company 任一或二者都完成后(取决于它们是否都不执行)，任务
submit report 需完成 (仅一次)。
本模式的主要困难在于决定何时同步，何时合并。同步可选流导致可能的死锁，合并并发流可能导致不期望的紧接标准OR－join结构的任务的多重执行。
1.
已知有两种工作流引擎
MQSeries/Workflow 和InConcert中直接实现了这个模式。正如前面提及的，若一同步合并后接一OR-split，该 OR-split可触发多于一条流出转移,不必等到运行时方知同步是否应该发生。
2.
在其它工作流引擎中未直接实现本模式。通常的作发是避免明显地使用可能触发多条流出转移的
OR-split，而代之以一个AND-splits和XOR-splits的联合。该方法可轻易地使用AND-splits和XOR-splits结构同步相应分支。
1、任意循环（Arbitrary Cycles）
在工作流分析/设计期间，人们不希望受各种各样工作流定义工具的语法约束，诸如循环仅有一个入口一个出口。事实上,为正确抽象, 工作流引擎应允许无约束模型的执行，也许更利于最终用户跟踪过程的执行。
意指在流程中，一个或多个任务可被重复执行。
循环（loop）, 叠代(iterate), 周期（cycle）。
- 大多数原始的工作流模型在分析阶段包含任意循环 (除非不含循环).。
某些工作流引擎不允许任意循环 – 仅支持结构化循环, 或者借助分解结构(MQSeries/Workflow, InConcert)，或者依靠特定的循环结构 (Visual WorkFlo, SAP R/3)。
任意循环可典型地转换成结构化循环，除非含有更高级模式之一，诸如
多实例模式。此类变换不是通过辅助变量，就是节点复制。下图是一任意循环转换成结构化循环的例子。
2、绝对终止(Implicit Termination）
另一类工作流引擎对模型加以限制的例子是模型中只能包含一个结束节点,若有多个结束节点,当第一个结束节点到达时，工作流模型终止。其次，大多数业务模型不遵循本模式－－认为业务过程当无事可作时终止更自然。
一给定的子流程当无事可作时应终止；换言之，流程中无活动任务，且无其它任务可被激活 (同时，流程并非死锁)。
这样的语法在分析阶段为每种工作流模型采用。
大多数工作流引擎当流程到达一显性的Final节点时终止流程。任何当前正在运行的任务在流程终止时将被取消，这可能干扰最终用户。某些工作流引擎(Staffware, MQSeries/Workflow, InConcert) 在子流程无任务时结束子流程。
这类问题的典型解决方案是将模型转换成仅有一个终止节点的等价模型，其复杂性更多地取决于实际模型。有时是容易的、直截了当的
, 具有代表性的作法是利用不同接合结构及任务复制的组合。然而，有时较难甚至不可能实现。一个包含多实例及绝对（或隐性）终止 的模型很难转换成显性终止的模型。
1、多实例（设计时已知实例数目）
流程中的某个任务可能乐于创建多个实例，其数目在设计模型时已知。
某种情形下，一个任务被激活多次，其指定任务在给定情况下实例的个数在设计时已知。
危险材料的申请单要求三次不同的审批。
若实例的个数在设计时已知，一个简单的处理方法是在模型中复制该任务，并结合使用并行执行模式。
2、多实例（运行时才知实例数目）
一个任务的实例个数是动态的，亦即在设计时未知，而在运行期间所有实例需被执行前的某点可获知其数目。可以将本模式看作一初始化该任务的For循环。
在某种情况下，任务可被激活多次，给定任务的实例数在指定情形下是一变量，取决于情况特征或资源的可用性, 但在运行期的某些阶段才已知, 即该任务的实例不得不被创建之前。
l
在将科学论文提交杂志审阅的流程中，任务
review_paper被实例化几次取决于论文的内容、受托人的可用性, 以及作者的信任度。
l
对于多本书的订购过程, 任务
check_availability 每本书都执行一次。
l
当预定旅行时, 任务
book_flight 执行多次，若该旅程包含多个航程。
l
当申请审批包含多项，且每项需不同的人审批。
只有少数工作流管理系统提供指定情况下一个任务的多次激活。大多数系统不得不采取同一任务确定数目的并行实例，或者采用叠代（或重复）结构――其中任务串形处理。
1.
可用任何适用的方案。
2.
若存在可能的最大实例数, 则
AND-split 和
XOR-split 可用于获取期望的路径。一XOR-split用于选择实例的数目，并触发几个AND-splits之一。每一可能的实例数对应一个带有基数的AND-split。本方法的缺点是使得模型变得庞大且复杂，另为可能的最大实例数所限。
3.
某些工作流引擎提供一特殊结构用于实例化一任务的给定数量的实例。例如MQSeries/Workflow 中的
Bundle 。
4.
正如很多情况下，期望的路由行为极易支持――使其更串形化。简单地利用叠代（重复）串形地激活任务的实例。假设任务
A 后接任务
B 的
n个实例且后接任务
C
，首先执行
A，然后执行
B 的第一个实例，每一
B 的实例后接一XOR-split来确定需要另一
B 的实例或者
C 为下一需执行的任务步。 本方法相当简单。可是，
B的
n 个实例是非并行执行的但以确定的次序，在很多情形下是无法接受的。请思考论文审阅的例子，显然，第二个审阅者不得不等待第一个审阅者完成审阅后才能审阅是无法让人接受的，等等。
3、多实例（无预知）
实例的数目是动态的，亦即实例数设计时不知，在运行期间，所有这些实例需要被激活前的任何阶段都无法知道。可将本模式看作是任务实例化的WHILE循环。
某种情况下任务可激活多次，然实例数设计时不知，在运行期间，所有这些实例不得不被创建之前的任何阶段都无法预知。
100台计算机的订单，然供货商数目未知。每一供货商交付的计算机数量未知，因之，交付的综述事先未知。每次交货后，通过比较已截止目前已交付的总数和需求数量来确定是否还有下次交易。
大多数工作流引擎不允许同一任务多于一个实例同时激活。
1.
本模式的最简单实现是利用循环和并行分叉结构，只要工作流引擎直接支持多实例。在
Forte 和Verve中是可行的。
2.
某些工作流支持额外的结构使得设计器可创建子流程（
subprocess 或subflow ），从主流程中分离且并行执行。例如， Visual WorkFlo 支持Release 结构、I-Flow 支持Chained Process Node.。
3.
若工作流支持特殊的结构――孵化子流程
, 那么可通过调用子流程――作为流程中任务的一部分。
4.
同样运行时已知实例数的多实例模式，期望的路径行为通过使其有序执行极易支持。
4、多实例（要求同步的多实例）
以上多实例模式未考虑多实例的同步问题。例如，从主流程中孵化出一可变数量的子流程, 如Visual WorkFlo 和I-Flow中支持的那样, 仅启动多实例未考虑同步问题；但是有时候要求所有实例完成后方可继续流程运转, 可能不知道创建了多少实例。
实例的数在设计时未知，任务的所有实例完成后另一任务才能启动（或开始）。
· 预订旅行时
, 任务book_flight 被执行多次――若形成设计多个航班。只有所有预订完成, 发票才能送往客户。
· 100台计算机的订单导致确定数量的交货，只有所有交货处理后，订单才能关闭。
大多数工作流引擎不允许多实例。而允许多实例的工作流语言(如Forte, Verve)未通过任何结构来处理多实例的同步。支持Release结构的工作流语言 (Visual WorkFlo, I-Flow) 不提供任何结构允许同步孵化的子流程。
1.
若实例数
(或最大实例数) 设计时已知, 那么通过复制任务及使用基本的同步模式可实现多实例的同步。
2.
若工作流语言支持多实例与除非所有任务完成不终止流程的分解
, 那么多实例可实现同步――将流程中包含循环生成多实例的子流程放入分解块中，只有任务的所有实例完成后，才能继续执行块。
3.
MQSeries/Workflow的 Bundle结构可用于同步运行时实例数已知的所有实例。
4.
大多数工作流语言中不易实现本方法。典型的的解决之道是采用外部触发器，只有该任务的每一实例完成
, 然后发送事件，主流程中应有另一任务等待发送的事件，此任务只有在收到每一实例的所有事件后才能完成。
1、延期选择（Deferred Choice）
在选择时刻，诸如由XOR-splits/OR-splits所支持的结构,工作流管理系统是自然的事情，亦即基于数据或通过判别任务获取。这意味着选择是优先的, 也就是说在一选定分支被实际执行之前先作选择。有时这样的作法是不当的。存在两个线程只能执行一个的情形 (设一个线程激活任务A, 另一线程激活任务 B，而两个任务都在任务列表中)，只要一个线程启动, 另一线程应消失(亦即若任务 A 启动，则任务B 应从工作列表中消失)。
流程某点几个分支中之一被选中，相对于XOR-split的是, 选择不是显性的 (例如基于数据或判定) 但有几个可选路径；然而，相对于AND-split, 仅有一个可选路径被执行。这意味着环境激活可选分支之一，其余分支忽略。请注意，重要的是该选择延期到可选分支之一确实启动之时, 亦即选择的时刻仅可能迟。
外部选择, 隐性选择（implicit choice.）
· 接收产品时有两条途径将产品运往部门，选择是基于相应资源的可用性，因之，选择延期到一个资源可用。
· 考虑任务
send_questionnaire, 后接任务
time_out 和
process_questionnaire，任务
time_out 要求一个时间触发器, 任务
process_questionnaire 只在回复从接收方返回时执行(所以其执行需要一外部触发器)。明显地,在任务
process_questionnaire 和
time_out 作选择时应越迟越好。若这样的选择被建模成一个显性的
XOR-split , 可能在回复表单到达是被拒收, 亦或若无回复返回时锁定流程。
很多工作流管理系统支持 XOR-split, 但不支持隐性 XOR-split。由于两个选择都是期望的, 缺乏隐性 OR-split 是一个实在的问题。
1.
假设所用的工作流语言支持
AND-split 和Cancel Activity 模式，隐性XOR-split可借助一AND-split激活所有可选分支实现。只要可选分支之一的处理开始,所有其它可选分支被取消。请考虑上图中在任务B 和C 之间的隐性选择，任务A之后, 激活任务 B 和C，只要B 被选中或执行，任务C 被取消(无它法)。请注意，该方法常常不可行，因为B 和 C 可被同时选中或执行。
2.
解决此问题的另一方法是由一显性
XOR-split代替隐性XOR-split,亦即增加一额外任务。所有触发器激活的可选分支被重定位到一新加的任务。假设任务可以在触发器之间区分, 则它可激活适当的分支。请注意，此方法将部分路由移入应用或任务（应用中的任务）层。
2、交叉路由（Interleaved Routing）
AND-split
和AND-join模式典型地用于定义并发路由。大多数工作流管理系统支持真正的并行, 亦即两个任务同时被执行。若这些任务共享数据或资源,真正的并行是不可能的或者导致紊乱，诸如丢失更新的数据或死锁。
一组任务的以任意顺序执行:组中的每一任务被执行, 执行顺序运行时决定, 没有两个任务在同一时刻执行 (亦即同一流程实例同一时刻没有两个任务活动。
无序串形。
· 海军要求每个工作申请必须进行两项测试
: physical_test 和mental_test。这些测试可以任意顺序进行，但不能同时进行。
· 每年年终时，银行对每一帐户执行两项任务
: add_interest 和charge_credit_card_costs。这些任务可以任意顺序执行，但是由于都要更新帐户数据,它们不能同时执行。
由于多数工作流管理系统支持并行执行――利用诸如AND-split 和AND-join这样的结构, 不可能定义交叉并行路由。
1.
固定执行顺序
,亦即将并行执行代之以串形执行。由于任务可以任意顺序执行,采用预定义执行顺序的方法是可以接受的。但是, 固定执行顺序, 就降低了柔性，且所有潜在的资源不能被利。
2.
利用
XOR-split 和Sequence的混合, 亦即确定几个可选次序，执行前通过一 XOR-split选择一个次序；缺点是开始执行前次序是确定的。然而, 工作流模型由于列举所有可能的次序而可能变得非常复杂和庞大。
4.
F对于基于Petri网的工作流模型, 任务的交叉须得强制加入一个位置――作为所有潜在并行任务输入及输出的地方。AND-split增加一个令牌到该处， AND-join从该处去除索价令牌。易见如此的位置实现了所要求的“互斥现象”。
3、里程碑（Milestone）
这个模式允许测试一个流程是否到达某一阶段。到达某些阶段时，就取消一些以前允许运行的任务。
任务节点的可用性取决于特定的状态条件，也就是说任务只有在某一里程碑已经达到并且还没有过期的时候才可被激活。假设有
3个任务A,B,C，任务A只有在任务B已经被执行，并且C还没有被执行的情况下才被激活，亦即A在B执行前是不可被激活的，在C执行后A又是不可被激活的。
测试临界点，最终期限，状态条件
· 假设一个处理控告的流程，第一步，控诉材料被登记注册（
register任务），然后平行的一个调查表发送给原告（
send_questionnaire任务），同时控告材料需要进行评估（
evaluate任务）。如果在2周内，原告送回了调查表，任务
process_questionnaire 执行完成。如果在2周内，原告没有送回调查表，调查表的调查结果被放弃（任务
time_out） 根据对控告材料的评估结果，决定是否受理。实际的控诉受理（
process_complaint任务）必须等调查表被处理完成或者已经超时，才可以进行。对控告的处理结果需要通过
check_processing任务的检查。最后归档任务（
archive）被执行。
· 在一旅行社，航班机票、汽车租赁、旅馆等在发票还没有打印出来的时就可以预定。
· 一个顾客可以直到规定的交付日期前
2天退掉其购买的商品。
· 一个顾客可以乘机
6个月后向航空公司索赔。
这个问题与在延期选择模式中提到的问题很相似。在许多的任务之间这里有一个竞争，一些任务的执行会导致别的不能执行。注意，在控告登记例子中，任务
process_complaint 可被执行任意多次，也就是可能不执行
process_complaint, 也可能执行多次。
1.
假设有
3个任务 A、B和 C，任务 A 在任务C执行前和任务B执行后可以执行任意多次。这样的里程碑可以用延期选择模式实现。任务B开始执行之后，可以设置一含有两个并行任务的延期选择：B、C，若B被执行完后，同样的延迟选项被激活。如果C执行完了，B被延迟选项设置成不起作用。注意，这种方法只有在B的执行不受别的并行线程控制的条件下才可以工作。例如，这种结构在控告登记例子里就不可以用，因为process_complaint 只有在一个积极的评估或者一个消极的检查之后才可以直接执行。亦即，process_complaint 的执行受两个并行的线程制约。
2.
另一方法是使用数据透视法，例如，引入一
Boolean 流程变量m。再次假设3个任务A, B和C ，任务 A 在任务B和C之间才可以被执行。起始，m 被设置成 false。在B执行完后，m 设置成true, 同样的任务 C 将 m 设置成 false。任务 A 由一个周期m值的循环来执行：如果 m 是 true, 则 A 是激活；如果m 是 false, 则过一个指定的周期后再检查条件。注意这是一个激活等待（busy wait）方法。可使用更多成熟的本方法的变种（或派生），如使用数据库的触发器等。但是，其缺点是，部分流程的真正处理被隐藏到任务和应用中。此外，混合使用并行模式和选择模式会导致各种各样的并发问题。
1、取消任务（Cancel Activity）
典型的处理是一个任务完成后激活另一任务，但是某些业务过程要求有不同的动作（action）发生。取消任务模式可有效地用于禁止另一任务，以作为一任务完成的结果。
一个被激活的任务被取消, 亦即一个等待一任务执行的线程被去除。
撤销任务。
· 通常地
, 一个设计被两组工程师检查，然而,为满足最终期限，可能其中一组检查被取消。
· 若一客户取消一信息请求，则对应的任务被取消。
仅有少数工作流管理系统在工作流模型语言中直接支持任务的取消, 亦即在（半）图形方式下
1.
若一种工作流语言支持延期选择模式
, 那么它可以通过增加一个所谓的“影子任务”来取消一个任务。实际任务和影子任务都置于一隐性OR-split之后。而且,影子任务不与人进行交互，而由一取消该任务的信号触发。考虑基于Petri网的工作流语言的例子，一任务通过从其输入之处去除令牌被取消；该令牌由具有同组输入点的另一任务的执行被去除。注意，本方法的缺点在于引入一与实际过程无关的任务。
2.
多数工作流管理系统利用
API支持任务的取消――简单地从数据库中去除相应的记录，亦即，不可能直接在图形化方式下建立取消任务的模型, 但是其中的一个任务可以承担取消另一任务的功能。
2、取消流程（Cancel Case）
一个案例，亦即流程实例, 被完全取消。
撤销流程。
· 在雇佣新员工的过程中
,一个申请者撤销其申请。
· 在最终判决之前客户撤销保险索赔。
工作流管理系统常常不支持取消整个流程。
1.
取消任务模式可以被流定义中的每一任务重复。流程中没有一触发每一任务撤销的任务。请注意，这个方法不是最好的，因为“正常的控制流”和仅由去除流程实例引入的各种各样的关系纠缠在一起。
2.
类似于取消任务模式，多数工作流管理系统支持利用一API取消流程――简单地从数据库中去除相应的记录（或项目）。
扫一扫
96
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
