在软件开发⾥，我们将不在⾃⼰控制范围内因素所造成的问题和没有预料到的情况称为异常。⼯作流异常和软件开发⾥异常的概念⼀致，将流程实例执⾏过程中出现的问题和错误称为异常，这些异常是由各种不确定因素造成的，从⽽使流程实例执⾏偏离了流程设计者最初的期望。引起⼯作流异常的因素有很多，流程定义描述的不准确或不完整，执⾏环境的变化，不能获取资源等都会引起流程执⾏偏离预期。这些因素涉及系统异常：硬件、软件、通讯、⼯作流模型、相关应⽤程序、流程逻辑约束、⼯作流相关数据约束、时间约束以及执⾏算法；涉及业务异常:⼯作⼈员请假离职、资源紧张、突发事件、⽤户中⽌合同、项⽬⽬标发⽣变化等。 在Java和C++⾥，当程序运⾏过程中出现异常时，会中⽌当前程序的运⾏，并将异常层层抛出。⼯作流系统的异常处理与之相同，如果在当前的运⾏上下⽂⾥，我们得不到⾜够的信息来处理这个问题，我们就会停⽌运⾏，并将这个问题交给上层进⾏处理，上层拥有更多的信息。在软件开发⾥，异常处理的⼀个原则是：如果不知道该如何处理这个异常，那么就别去捕捉它。这个原则同样适⽤于流程实例的执⾏过程，如果不知道如何处理⼀个问题，那么就不要处理，把它留给能处理这个问题的⼈去处理。
程序⾥，异常处理的⽬标在于让我们能⽤⽐现在更少的代码，以⼀种更简单的⽅式来开发⼤型、可靠的程序。通过将处理异常的代码从异常发⽣的地⽅移开，我们能够在⼀个地⽅集中精⼒去解决想解决的问
题，然后再到另⼀个地⽅集中处理这些异常问题。程序的主线不会被异常处理这类枝节问题给搞得⽀离破碎，程序也更易于理解和维护。这⼀⽬标同样也是⼯作流系统异常处理的⽬标，当应⽤⼯作流系统时，我们⾸先会进⾏流程建模，复杂的流程定义会导致流程的不可管理，作为⼀个原则，流程定义必须能够被执⾏⼯作的⼈所理解。当对实际业务流程进⾏建模时，如果只建模流程执⾏的乐观路径，模型会直接易懂，但如果将流程执⾏过程中的各种异常情况和如何处理都进⾏建模，那么肯定会带来巨⼤的复杂性，使得流程定义⾮常难以维护。此时⼀是需要⼯作流系统提供异常处理机制;⼆是需要应⽤⼈员进⾏适当的异常分类与建模，并在合适的位置设置异常处理器。
在前⾯的章节⾥，我们分别讨论了⼯作流的控制模式、资源模式和数据模式，这三种模式分别对⼯作流的不同⽅⾯进⾏了描述，异常处理模式与这些模式都紧密关联，因为在⼯作流的执⾏中，流程定义、流转、资源分配与数据约束都会引起异常。
在本章⾥，我们⾸先对⼯作流执⾏过程中可能出现的异常进⾏分类，⼀般来说，异常都会与⼀个正在执⾏的⼯作项关联，即当前正在执⾏的⼯作产⽣了异常，但外部环境的变化也会影响到当前正在执⾏的⼯作。接下来我们将讨论在不同的层次上对异常进⾏处理，这些层次包括⼯作项级别和流程实例级别(包括了流程定义级别)，以及异常发⽣时我们可以采取的恢复动作。当讨论完这些点之后，我们将会看到它们如何互相结合构成我们的⼯作流异常处理模式即⾯。
异常分类
流程执⾏过程中的异常分为五类，如图D-1所⽰。
图D-1 ⼯作流异常分类
1. ⼯作项执⾏失败:⼯作项所代表的⼯作不能继续执⾏或⽆法按照期望完成。导致⼯作项执⾏失败的原因有很多种，与该⼯作项相关的硬
件故障、软件故障或⽹络故障都会导致活动参与者⽆法正常执⾏该⼯作项，同时活动参与者也可能会⾃⼰中⽌该⼯作项的执⾏或者直接放弃。
2. 超时:⼯作项未在指定的时间点完成或未在指定的时间点开始执⾏。
3. 资源不可⽤：没有可⽤的资源执⾏或完成⼯作项。有两种情况，⼀是分配⼯作项时系统不到满⾜执⾏该⼯作条件的资源(⼈⼿不够，
资源被占⽤)，⼆是⼯作项执⾏过程中，
先前指定的资源不能继续或⽆法执⾏该⼯作项(⽣病、离职、调动)。
4. 外部触发：外部触发通常表现为事件，组织外部的事件影响正在执⾏中的⼯作项。例如⽤户突然取消订单会导致订单处理流程中所有⼯
作项的中⽌，并伴随着业务回滚(收回发货)。
5. 违反约束:⼯作流约束包括流程流转的约束(流程死锁，不能继续执⾏，进⼊死循环)、数据的约束、资源的约束(超出当前组织资源所能
达到的能⼒)以及业务约束。⼯作流系统运⾏过程中需要保证流程执⾏的合理性和⼀致性，需要对流程执⾏状态进⾏持续的监控。 ⼯作项级别的异常处理
⼀般来说，异常都会与⼀个正在执⾏的⼯作项关联，即当前正在执⾏的⼯作产⽣了异常，外部触发是个例外，此时异常并不由流程⾃⾝执⾏产⽣，但是影响到当前正在执⾏的⼯作项。当发⽣异常时，⼯作项级别有很多种可能的处理⽅式，这些⽅式与当前⼯作项状态息息相关，所以在讨论具体的处理⽅式之前，我们先简单回顾⼀下⼯作项的⽣命周期，然后讨论⼯作项在其⽣命周期的不同状态时可以选择的异
常处理⽅式。
从资源的⾓度，⼯作项的⽣命周期具有6个状态(相⽐资源模式⾥的讨论，进⾏了简化)，分别是：提供给资源拾取(Offered)、指派给⼀个资源执⾏(Allocated)、执⾏(Started)、完成(Completed)、失败(Failed)和撤回(Withdrawn)。如图D-2所⽰。
图D-2 ⼯作项的⽣命周期
最开始，⼯作流系统创建⼯作项并将其提供给资源拾取，这⾥的资源可以是单个资源也可以是多个资源，⼯作项此时处于提供给资源拾取状态。接下来，其中⼀个资源向⼯作流系统发送⼀个要求指派的请求，要求系统将该⼯作项指派给他进⾏执⾏，然后系统就会将⼯作项指派给该资源执⾏，⼯作项此时处于指派给⼀个资源执⾏的状态，同时，对于前⼀步⼯作项被提供的其他资源来说，⼯作项被撤回了。接下来，资源向系统发送开始执⾏的请求，⼯作项即进⼊执⾏状态。
最后，如果资源正常完成活动，会给系统发送请求，告诉活动完成，系统将⼯作项的状态置为完成，⼯作项的⽣命周期即到此结束;⽽如果资源没有按照期望完成活动或⽆法完成活动，⼯作项的状态置为失败，⼯作项的⽣命周期结束。
赵薇天使旅行箱当⼯作项处于提供给资源拾取的被拾取状态时，可能的异常处理⽅式包括以下4种。
1. 继续被拾取(OCO，continue-offer):⼯作项继续保持被拾取的状态，不发⽣任何变化。
2. 重新分配资源拾取(ORO，re-offer):⼯作项重新分配给新的资源进⾏拾取。
3. 强制完成(OFC，force-complete):⼯作项从资源的待拾取列表撤回，状态变为完成，触发后续活动产⽣新的⼯作项。
4. 强制失败(OFF，force-fail):⼯作项从资源的待拾取列表撤回，状态变为失败，不触发后续活动。
图D-3 ⼯作项处于被拾取状态的异常处理
当⼯作项处于指派给⼀个资源执⾏的被指派状态时，可能的异常处理⽅式包括以下5种。
1. 继续被指派(ACA，continue-allocation):⼯作项继续保持被指派的状态，不发⽣任何变化。
2. 重新指派(ARA，re-allocation):⼯作项从资源的待办列表撤回，⼯作项重新分配给新的 10资源执⾏。
3. 重新分配资源拾取(ARO，re-offer):⼯作项从资源的待办列表撤回，⼯作项重新分配给新的资源进⾏拾取。
4. 强制完成(AFC，force-complete):⼯作项从资源的待办列表撤回，状态变为完成，触发后续活动产⽣新的⼯作项。
5. 强制失败(AFF，force-fail):⼯作项从资源的待办列表撤回，状态变为失败，不触发后续活动。
图D-4 ⼯作项处于被指派状态的异常处理
当⼯作项处于执⾏状态时，可能的异常处理⽅式包括以下6种。
图D-5 ⼯作项处于执⾏状态的异常处理
1. 继续执⾏(SCE，continue-execution):⼯作项继续保持执⾏的状态，不发⽣任何变化。
2. 重新开始执⾏(SRS，re-start)：当前正在执⾏的⼯作中⽌，由同⼀个资源重新执⾏该⼯作项。
3. 重新指派(SRA，re-allocation)：当前正在执⾏的⼯作中⽌，⼯作项从资源的办理列表撤回，⼯作项重新分配给新的资源执⾏。
4. 重新分配资源拾取(SRO，re-offer)：当前正在执⾏的⼯作中⽌，⼯作项从资源的办理列表撤回，⼯作项重新分配给新的资源进⾏拾取。
5. 强制完成(SFC，force-complete)：当前正在执⾏的⼯作中⽌，⼯作项从资源的办理列表撤回，状态变为完成，触发后续活动产⽣新的⼯
作项。
6. 强制失败(SFF，force-fail)：当前正在执⾏的⼯作中⽌，⼯作项从资源的办理列表撤回，状态变为失败，不触发后续活动。
流程实例级别的异常处理
异常不仅会影响到与其关联的⼯作，往往还会影响到同⼀个流程实例⾥正在执⾏的其他⼯作甚⾄同⼀个流程定义⾥其他正在执⾏的⼯作，所以我们还需要在更⾼的⼀个级别进⾏处理。
可能的异常处理⽅式包括以下3种。
1. 继续执⾏(CWC，continue with case)：当前流程实例中其他⼯作不受影响，流程实例继续执⾏。异常在⼯作项级别已经得到完全的处
理。
2. 当前流程实例中⽌执⾏(RCC，remove current case)：当前流程实例中的部分或所有⼯作中⽌执⾏，如果所有⼯作都中⽌执⾏，那么即
流程实例中⽌执⾏。异常所影响的范围限于当前流程实例内。
3. 所有属于同⼀流程定义的流程实例都中⽌执⾏(RAC，remove all cases)：属于同⼀流程定义的流程实例中的部分或所有⼯作中⽌执⾏，
如果所有⼯作都中⽌执⾏，那么即所有流程实例都中⽌执⾏。异常影响所有属于同⼀流程定义的流程实例。
恢复动作
当异常发⽣时，执⾏过的⼯作已经产⽣了⼀定的影响，为了使流程实例能够继续执⾏或正常停⽌，必须对已执⾏⼯作所产⽣的影响进⾏消除，这是通过恢复动作完成的，该动作对流程中可补偿的⼯作进⾏补偿。
可能的恢复动作包括以下3种。
1. 什么都不做(NIL，no action)：什么都不做。
2. 回滚(RBK，rollback)：流程实例状态重置⾄异常发⽣前的⼀个回滚点。
3. 补偿(COM，compensate)：额外的补偿动作，消除异常所产⽣的影响。
对于回滚，我们需要记录⼀个回滚点，通过执⾏⽇志记录流程实例执⾏过程中的事件，当回滚动作发⽣时，我们将执⾏⽇志中回滚点后续的执⾏事件全部撤销。我们并不需要将流程实例回滚后的状态与流程实例当时位于回滚点的状态完全⼀致，我们需要的只是消除异常所产⽣的影响，所以执⾏⽇志不需要详细记录流程实例中的每⼀个执⾏事件。同时，有⼀些操作也是回滚动作⽆法恢复的，例如资源浪费的时间、已经发送的⽂档/报告等。
补偿动作相对回滚来说有很多的灵活性，我们不仅可以将发⽣过的事件撤回，还可以额外进⾏⼀些操作(例如通过异常路径继续执⾏流程实例)，来消除异常所带来的影响。
图D-6 BPMN⾥的异常流属于补偿动作
异常处理模式
对每⼀种的异常⽽⾔，都可能存在不同的处理⽅式，我们把每种针对特定异常类型可能的处理⽅式称为异常处理模式。⼀个异常处理模式包括4⽅⾯的内容:
1. 异常的类型;鞠说好看
2. 发⽣异常的活动如何处理即⼯作项级别对异常的处理;
3. 发⽣异常的流程实例以及关联流程实例如何处理即流程实例级别对异常的处理; 1. 采取何种恢复动作。
共有135种可能的异常处理模式。
⼯作执⾏失败
1. OFF-CWC-NIL
2. OFF-CWC-COM
3. OFC-CWC-NIL
4. OFC-CWC-COM
5. AFF-CWC-NIL
6. AFF-CWC-COM
7. AFC-CWC-NIL
8. AFC-CWC-COM
9. SRS-CWS-NIL
10. SRS-CWC-COM
11. SRS-CWC-RBK
12. SFF-CWC-NIL
13. SFF-CWC-COM
14. SFF-CWC-RBK
15. SFF-RCC-NIL
16. SFF-RCC-COM
17. SFF-RCC-RBK
18. SFC-CWC-NIL
19. SFC-CWC-COM
20. SFC-CWC-RBK
⼯作超时
钓鱼岛的前世今生
1. OCO-CWC-NIL
2. ORO-CWC-NIL
3. OFF-CWC-NIL
4. OFF-RCC-NIL
5. OFC-CWC-NIL
6. ACA-CWC-NIL
7. ARA-CWC-NIL
8. ARO-CWC-NIL
9. AFF-CWC-NIL
10. AFF-RCC-NIL
11. AFC-CWC-NIL
12. SCE-CWC-NIL
13. SCE-CWC-COM
14. SRS-CWC-NIL
15. SRS-CWC-COM
16. SRS-CWC-RBK
17. SRA-CWC-NIL
18. SRA-CWC-COM
19. SRA-CWC-RBK
20. SRO-CWC-NIL
21. SRO-CWC-COM
22. SRO-CWC-RBK
23. SFF-CWC-NIL
24. SFF-CWC-COM
25. SFF-CWG-RBK
26. SFF-RCC-NIL
27. SFF-RCC-COM
28. SFF-RCC-RBK
29. SFC-CWC-NIL
30. SFC-CWC-COM
资源不可⽤
1. ORO-CWC-NIL
2. OFF-CWC-NIL
3. OFF-RCC-NIL
4. OFC-CWC-NIL
5. ARO-CWC-NIL
6. ARA-CWC-NIL
7. AFF-CWC-NIL
8. AFF-RCC-N1L
9. AFC-CWC-NIL
10. SRA-CWC-NIL
11. SRA-CWC-COM
12. SRA-CWC-RBK
废墟上的鲜花
13. SRO-CWC-NIL
14. SRO-CWC-COM
15. SRO-CWC-RBK
16. SFF-CWC-NIL
17. SFF-CWC-COM
18. SFF-CWC-RBK
19. SFF-BCC-NIL
20. SFF-BCC-COM
21. SFF-RCC-RBK
22. SFF-RAC-NIL
23. SFC-CWC-NIL
24. SFC-CWC-COM
外部触发
1. OCO-CWC-NIL
2. OFF-CWC-NIL
3. OFF-RCC-NIL
4. OFC-CWC-NIL
平流层飞艇
5. ACA-CWC-NIL
6. AFF-CWC-NIL
7. AFF-RCC-NIL
8. AFC-CWC-NIL
9. SCE-CWC-NIL
10. SRS-CWC-NIL
11. SRS-CWC-COM
12. SRS-CWC-RBK
贝亲婴儿奶癣膏13. SFF-CWC-NIL
14. SFF-CWC-COM
15. SFF-CWC-RBK
16. SFF-RCC-NIL
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议