第五章-工作流资源模式之折回模式

五、折回模式

实际工作中，工作的执行状态不可能总是与预想相符的，总会出现各种各样的情况，例如原本分配给员工甲的任务由于甲要请假不得不重新分配，由于新的紧急任务员工乙当前的工作需要挂起一段时间等等。折回模式则刚好对应着这些情况，折回代表着工作项状态的反复、回退。

 

图 5-33

如图5-33所示，折回模式对应着红线标识着的工作项的状态变迁。这些状态变迁对应着以下情况：

委派：资源将先前指派给他的工作项委派给他人执行。

系统重新分配：系统将没有完成的工作项重新提供或指派给其他资源执行。

退回指派：资源撤销指派给他的工作项，工作项可以重新指派给其他资源。

工作移交：资源将其已经开始执行的工作项移交给他人执行。

挂起/恢复执行：资源临时挂起当前执行的工作项，并在某一个时候重新恢复执行该工作项。

跳过：资源选择跳过指派给他的工作项的执行，不执行该工作项。

重做：资源重新执行先前已经完成的工作项。

提前执行：资源在流程实际触发该工作前已经开始执行该工作。

折回模式共有9种。

 

1、委派（WRP_27: Delegation）

描述

资源能够将先前指派给他的工作项指派给另外的资源执行。

 

图 5-34

如图5-34所示，委派对应于红线标识着的工作项状态变迁。

 

应用

委派在平常工作中非常常见，例如员工甲将要请假，他将他要完成的工作委派给同事乙执行；在协同办公里，领导将相关工作委派给下属执行等等。

 

实现

实际应用中，委派按照粒度分为了两种：一种 是工作项的委派，这是一种细粒度的委派，指单一任务实例的委派，与某一特定的任务实例关联；另一种是业务的委派，这是一种粗粒度的委派，例如，员工甲将其 负责的某类业务的工作全部委派给员工乙，这意味着属于这类业务的所有工作都将由员工乙执行。业务的委派通常与权限紧密关联，实际实现时为避免用户权限的混 淆，一般采取分开登录系统的方式进行实现，即员工乙如果想处理员工甲委派给其的工作，则需要用员工甲的账号和其给定的密码重新登录系统，并注销掉自己账号 的使用。

需要注意的一点是：委派意味着原先指派的资源还必须对该工作负责，例如员工甲将某项工作委派给员工乙执行，尽管员工乙实际执行了该工作，但该工作仍然必须由员工甲负责。所以在实现中，员工甲必须能够保持对委派工作项的追踪和控制。

 

2、系统重新分配（WRP_28: Escalation）

描述

系统能够重新分配已经分配的工作项，以加快工作项的执行。

 

图 5-35

如图5-35所示，工作项原先提供或指派给了一个或多个资源执行，现在由于各种原因，需要优化该工作项的执行，所以将该工作项收回重新分配，提供或指派给其他的资源。

 

应用

工作分配的优化。很多时候，计划跟不上变 化，工作也是这样，分配工作前有许多的考虑因素，例如个人能力、工作经验、技能要求等等，但在实际工作中往往会发现原先的人力分配并不合理，或者有些人承 担了太多的职责，或者有人能力超出其目前担承的职责等等（在敏捷软件开发里，我们通过频繁的交换结对编程以达到部分的平衡），在这种时候就需要对工作进行 灵活的重新分配以到达最高的执行效率。

 

实现

实际实现中非常受限，对流程的优化始终是一 个对人的命题，而不是对机器对工具的命题，工具所能做到的只是尽可能多的提供可供参考的数据模型，例如各种报表、数据分析等等，最后做出决策的还是人。所 以该模式的实现也以提供给流程管理员重新分配工作项的能力为主，同时提供工作项超时的提示为辅。

 

3、退回指派（WRP_29: Deallocation）

描述

资源撤销指派给他的工作项，工作项可以重新分配给其他资源。

 

图 5-36

如图5-36所示，资源能够退回原先指派给他的工作项，该工作项可以交由系统重新分配给其他资源。

 

应用

同样是工作分配的优化，只不过该模式由资源驱动。

实际工作中，由于各种原因，例如经验不足、当前承担职责过多等等，发现自己并不能很好完成当前的任务时，可以提出不执行该任务。

 

实现

实现的难点在于资源退回工作项后的重新分配，即如何重新分配该工作项。

与提供给多个资源模式对应，该模式的最简单支持是退回重新提供给多个资源。例如工作项分配给开发人员这一角色执行，开发人员甲拾取了该工作项（故事卡），经过一番痛苦和彷徨，最终将该工作项退回，这样所有开发人员又都能拾取该工作项。

 

4、有状态工作移交（WRP_30: Stateful Reallocation）

描述

资源将正在执行的工作项移交给其他资源执行，该工作的状态将得到保存。

 

图 5-37

如图5-37所示，资源将已开始执行的工作移交给其他资源执行。该模式与委派模式很相似，差别就在于委派模式是将未开始执行的工作进行重新指派执行，而该模式则是将已开始执行的工作进行重新指派执行。委派模式中的委派者仍需要为委派出去的工作负责，而移交则同时意味着责任的移交。

 

应用

工作移交非常常见，最常见的原因包括位置调动、离职、休假等等。

 

实现

在大多数的工作流系统实现里，业务数据与流程数据是相互隔离的，仅仅通过某一字段进行关联（例如业务主键），流程的目标是携带业务数据进行流转。在这种情况下，该模式的实现变成了默认实现，系统不需要做任何回退或清理操作，直接做工作项的转发即可。

 

5、无状态工作移交（WRP_31: Stateless Reallocation）

描述

资源将正在执行的工作项移交给其他资源执行，该工作的状态不会得到保存。

与有状态工作移交对应。

 

应用

工作的无状态移交通常意味着工作的重新执行，并且原有的工作对重启的工作而言没有太大的价值。

 

实现

与有状态工作移交相比，该模式需要处理相应业务数据的回退或清理。直接支持该模式比较困难，需要在实施时根据情况对该任务节点操作业务数据的权限进行限定，并在限定的基础上进行记录和回退。

 

6、挂起/恢复执行（WRP_32: Suspension/Resumption）

描述

资源能够挂起当前执行的工作项，并在某一个时候重新恢复执行该工作项。

 

图 5-38

应用

资源对分配给其的工作进行优化执行，能够根据自己和当前的实际情况合理的安排工作执行，挂起正在执行的工作，执行当前最重要或效率最高的工作，然后再返回执行该工作。

 

实现

基本的状态变迁。

 

7、跳过（WRP_33: Skip）

描述

资源能够选择跳过指派给他的工作项的执行，不执行该工作项，并将该工作项标识为完成。

 

图 5-39

 

应用

实际工作中，对于非关键工作，可以选择跳过，以便进行后续更为紧急或重要的工作。

 

实现

对于实现工作项本身的状态变迁来说，支持该模式非常简单，问题在于业务数据的依赖关系，如果后续工作的处理依赖于该节点处理后的业务数据，那么简单的选择跳过该工作项的执行就会产生问题。所以一个好的做法是给一些关键任务节点加上约束，不允许执行跳过操作。

 

8、重做（WRP_34: Redo）

描述

资源能够对先前完成的工作项重新处理，同时，该工作的后续工作项（后续任务所对应的工作项）也将被重新处理。

 

图 5-40

 

应用

对已完成的工作进行重新处理并不少见，但该 模式最为重要的部分还是在于要求所有后续工作的重新处理。所以该模式一般应用在极其重要的关键任务节点，例如非常重要的决策节点，因为后续的任务严重依赖 于该节点所作出的决策（所产生的数据），一旦决策发生变化，那么相应的后续工作必须都要做出变化。这也是业务敏捷性的一种反映。同时需要注意，该模式也是 一种代价高昂的应用，因为这往往意味着该业务流程实例中的很多工作都需要重新处理，所以如何在业务处理中尽早发现可能的环境变化并及时作出决策的调整并避 免成本高昂的返工才是最为重要的一点。

现在的软件开发越来越强调于拥抱变化，强调 代码的重构和演进，尽管如此，如果软件的基础架构需要根据当前业务变化发生重大变更，那么这依旧是一件成本高昂的事情，因为一旦基础架构发生变化，那么很 多模块实现将不得不重新编写代码。所以尽管越来越多的开发团队开始引入敏捷的开发方法，但是经验丰富的开发人员才是整个敏捷团队的基石（敏捷开发非常重视 人）。

 

实现

从该模式里能够看到资源模式与控制模式的结合，工作项的重做需要后续任务的重新执行，这需要取消当前的执行任务，并将流程实例的控制点重新返回至该工作项所对应的任务。这涉及到两种控制模式，分别是：取消任务模式和任意循环模式（具体可以参考第四章的说明）。

 

9、提前执行（WRP_35: Pre-Do）

描述

在工作项实际提供或指派给资源执行之前，资源已经可以执行该工作项。

 

图 5-41

如图5-41所示，任务A还在执行，任务B还未激活，但此时员工甲已经可以开始执行任务B的工作项。该模式的实现需要一个前提条件：任务B不能依赖于任务A的执行结果，即不能依赖于前续任务的处理输出。

可以看出，该模式与前面推模式里的提前分配模式非常相似，所不同的是：提前分配强调一种通知机制，强调预先准备；而提前执行则已经可以开始实际的执行工作。

 

应用

和提前分配模式不同，该模式实际提供了一种 流程任务执行的灵活机制，在预先定义的业务流程里，任务的执行是具有一定顺序的，可能在大多数情况下，这种顺序是合理的，但是在某些具体的流程实例里，某 些串行执行的任务节点可以并行的执行以达到最好的执行效率和负载均衡，在这种情况下，就可以应用该模式并行执行部分任务。

需要注意的是，该模式仅仅引入了一种实际执行任务的灵活性，是对业务流程定义固化的补偿，如果在一个业务流程中频繁应用到该模式，则往往意味着流程定义本身需要作出调整。