使用 WebSphere Process Server 修复流程

核心提示：WebSphere Process Server V6.1.2 支持控制流逻辑的手动修复和更改，本文描述这些修复功能，使用 WebSphere Process Server 修复流程，提供一些有用的技巧，并确定在应用它们时的一些潜在缺陷，但允许的跳转目标从应用程序角度而言可能是无效的，您需要通过研究流程模型及其意图来检

WebSphere Process Server V6.1.2 支持控制流逻辑的手动修复和更改。本文描述这些修复功能，提供一些有用的技巧，并确定在应用它们时的一些潜在缺陷。您将学习如何修复流程和动态响应建模错误处理和自动恢复机制无法解决的情况。

引言

在建模业务流程时，需要特别注意错误和异常处理。Web 服务业务流程执行语言（Web Services Business Process Execution Language，WS-BPEL）标准提供了错误处理程序和补偿处理程序，用于在您的业务流程逻辑中建模故障和异常路径。IBM® WebSphere® Integration Developer 利用了此概念，使您能够在业务流程中建模错误和补偿处理路径。即使特别小心地采取了此步骤，但在运行时仍然会出现创作时无法预见的故障情况。而且，还存在需要涉及手动修复的异常情况，例如，管理员分析并解决异常情况。WebSphere Process Server V6.1.2 支持控制流逻辑的手动修复和更改。它附带了手动修改流程实例的状态的新功能。可以使用这些新功能克服异常情况，从而修复该流程实例。

与这些强大功能相适应的是，您需要有远见和进行细心地处理。本文描述这些新的修复功能，提供一些有用的技巧，并确定在应用它们时的一些潜在缺陷。

您应很好地了解如何使用 WebSphere Integration Developer 建模业务流程，以及如何使用 WebSphere Process Server 运行和管理这些流程。您还应具备如何在 WebSphere Process Server 中执行 BPEL 流程的基础知识。

本文向您介绍如何修复流程，并专门为您动态响应建模错误处理和自动恢复机制无法解决的异常情况做准备。此类情况的示例包括：

某个单独的软件组件提供的服务在某个时段内不可用，并且服务实现必须通过手动交互接管。尽管此情况在某种程度上是可预见的，即流程建模程序可能已经实现了适当地处理该错误的错误处理程序（例如，通过向错误处理程序添加人工任务活动），但是，错误处理中这种级别的准确性和完整性无法在每种情况中正确假定。

在实际场景中，可能会发生无法正确执行少量流程实例。一般情况下，新的业务流程经过广泛的测试后才能部署到生产系统。遗憾的是，当业务流程非常庞大和复杂时，或者需要一组输入数据集时，该过程可能会失败。

本文的第一分部描述，对于新模型而言，为了从新修复功能中获得最大好处，在建模期间可以考虑哪些情况。后续部分讨论如何使长时间运行的流程在发生始料不及的错误时避免出现大的损害。最后一部分概述 WebSphere Process Server V6.1.2 中的新功能，即跳过和跳转功能，您可以通过该功能修改长时间运行流程的缺省执行行为。

本文未涵盖一般意义上的如何建模错误和补偿处理。本文还未介绍如何使用 WebSphere Process Server 的自动恢复机制，如失败事件管理器 (Failed Event Manager)、保存和保持队列处理等。要详细了解这些主题，请参阅“参考资料”部分。

示例流程

所有这些方面都通过一个处理订购请求的示例流程来说明。其总体结构如图 1 所示。

图 1. 订购流程的结构

该流程包含三个主要步骤，每个步骤都与另一个服务通信：

校准客户数据

在此第一步中，选中客户数据。因此，该流程与一个名为 Customer Registration Service 的外部服务通信。该流程检查请求者是否为已知客户。如果是，则将从注册服务中检索客户的数据。如果是新客户，则需要将客户数据输入到人工任务活动中，并将其添加到注册服务中。最后，计算客户的当前红利利率。

库存管理

订购流程现在检查是否提供了所有装运货物，并使用 Warehouse Service 完成此检查。库存中没有的货物将从其他提供商订购，该流程将等待所有请求的货物完成后才能执行。

装运

最后，装运订购的货物并向客户开发票。因此，订购请求流程与 Shipping Service 进行通信。

为重点介绍可用的流程修复选项，本文集中说明了 Align Customer Data 的步骤：假设 Customer Registration Service 当前不可用，并且对客户服务的所有调用都返回一个运行时异常。此流程修复操作现在的目的是克服此第一个步骤，避免阻止所有订购请求。

本文还假定与 Customer Registration Service 的交互可以在以后某个时间点服务可用时手动重新进行。可以跳过对客户服务的所有调用，允许继续执行实际的订单。

在创作时需要注意哪些问题

在简介中已经提到，修复流程实例与特定于建模的内容不相关，如错误和补偿处理；不过，需要强调的是，您可以独立于建模形式对所有长时间运行的流程实例使用修复功能。但是，您可以在创作时考虑某些方面，以便充分利用新功能。以下各部分将描述这些方面。

出错时仍继续

流程修复实质上是指手动干预失败的流程实例，通过此方法可以成功完成以前失败的某些工作。距离实际故障点（即，出现错误的位置）越近，执行此干预就越有效和越可行。如果错误通过多级错误处理程序传播，导致终止所有其他活动，并终止流程实例本身，则无法对其修复。这就是为什么业务流程提供了 Continue On Error 选项。在将此属性设置为 No 时，流程实例将挂起发生错误的当前执行路径，并且该错误不会被直接封闭范围或活动中的任何错误处理程序处理。发生错误的活动实例被设置为特殊状态已停止。注意，流程实例中的并行路径可以继续执行并且流程状态保持运行。还需要注意，停止的活动状态不限于基本活动：结构化活动（如序列或范围）也可以停止。

您可以在流程级别上设置 Continue On Error 属性（如图 2 中所示）。缺省值为 No。

图 2. 在流程级别上设置 Continue On Error

图片看不清楚？请点击这里查看原图（大图）。

对于以下活动类型，可以在活动级别覆盖 Continue On Error 属性（参见图 3）：即调用、Java™ 代码段和人工任务活动。您应保留缺省值 Same as Process。

图 3. 为活动设置 Continue-on-Error

图片看不清楚？请点击这里查看原图（大图）。

重要说明：如果将 Continue On Error 属性设置为 No，则对常规流程的执行在性能上没有负面影响。

授权

每当执行流程修复操作时，需要授权请求该修复操作的人员执行此操作，即，根据具体的操作，需要将该人员授权为流程管理员、范围管理员、活动管理员或系统管理员。

系统管理员是在 BPEContainer 应用程序上定义的角色。所有其他管理员特定于各个流程应用程序，它们在流程模型中定义。

流程管理员

您可以在创作时在流程的属性窗格中定义流程管理员。在 Administration 部分声明它们，如图 4 中所示。

图 4. 定义流程管理员

图片看不清楚？请点击这里查看原图（大图）。

如果未定义任何流程管理员，则流程启动者将成为流程管理员。

流程管理员允许执行以下操作：

修复流程实例的任何位置中状态为“stopped”的活动实例，例如强制完成和强制重试。

跳过活动实例。

在活动之间执行跳转。

修改全局和本地变量。

在流程实例上执行管理操作，例如，终止或删除某个流程实例。

范围管理员

范围管理员可以在创作时在范围活动的属性窗格上定义。如图 5 中所示，它在 Administration 部分上声明。

图 5. 定义范围管理员

图片看不清楚？请点击这里查看原图（大图）。

注意，范围管理员通过范围传递到其封闭范围，即封闭范围的范围管理员将成为当前范围的范围管理员。此外，流程管理员将成为范围管理员。

范围管理员允许执行以下操作：

修复处于范围内的已停止的活动实例，例如，强制重试和强制完成。

跳过包含在范围中的活动实例。

在范围中包含的活动之间执行跳转。

修改在范围或封闭范围中定义的变量。

在本文的后续部分中，我们将介绍有些修复操作可以将流程导航尚未找到的活动作为目标（参见“跳过活动实例”）。

重要说明：在本例中务必理解，只有流程导航已经找到的范围的范围管理员才允许执行修复操作。这意味着，在尚未找到在其中发生修复操作的范围时，您必须是外部封闭范围的范围管理员或者流程管理员才能执行修复操作。

活动管理员

对于某些活动类型（例如，调用活动和 Java Snippet 活动），您可以在活动的 Administration 部分定义活动管理员，如图 6 所示。

图 6. 某个活动的管理员

图片看不清楚？请点击这里查看原图（大图）。

另外，您还可以在流程级别定义缺省活动管理员（参见图 4，第二个人工任务规范）。它适用于没有明确定义管理员的流程中的所有活动。

封闭范围的流程管理员和范围管理员将自动成为此范围中包含的所有活动的活动管理员。

活动管理员允许执行以下操作：

修复处于停止状态的活动实例，例如强制重试和强制完成。

跳过活动实例。

分配管理权限的建议

为了避免流程启动者可能在未授权的情况下修复活动，我们建议至少定义一个流程管理员。由于范围管理员被继承到封闭范围中，而且这会导致附加持久性数据，因此我们建议少量而有目的地使用范围管理员。

还应向范围管理员分配流程阅读者权限；否则，将不允许范围管理员查看 BPC Explorer 中的流程实例，该权限实际上是应用跳过和跳转功能的起点。

范围管理员——示例

在我们的示例中，所有客户相关的操作都收集到名为 AlignCustomerData 的范围中，这在简介中已经说明（参见图 1）。

允许客户关系经理“Jeff”查看和修复流程中的此区域。不过，流程的其他区域与他不相关，出于安全原因，不应让他更改这些区域。这就是我们为什么将 Jeff 添加到范围 AlignCustomerData 的范围管理员角色。

保留所有活动

在导航长时间运行的流程时，并不是始终保持活动实例。如果短时间运行的活动（例如，分配活动）完全包含在一个事务中，则活动实例数据在数据库中可能不持久。

一方面，可能需要此行为，这是因为它可以节省数据库访问量，所以能够改进长时间运行流程的总体性能。而在另一方面，您拥有的历史数据越多，越可以更好地执行流程修复。例如，您可以确定所有活动实例的状态，从而确定整个流程实例的执行进度。

不过，在建模过程中，即使在导航中不需要活动数据，您仍可以决定始终保持活动数据。通过设置相应活动的 Enable persistence and queries of business relevant data（启用业务相关数据的持久性和查询）可以做到这一点，请参见图 7。

图 7. 启用业务相关数据的持久性和查询

图片看不清楚？请点击这里查看原图（大图）。

假设为您流程的关键区域中的活动设置此属性，您预期在该区域中将发生流程修复。请注意，这会影响性能，即使不需要流程修复也如此。

唯一的活动名称

仅在目标活动具有唯一的名称时才支持在两个活动之间进行跳转。在流程建模过程中命名活动时需要注意这一点（引用活动的名称而不是显示名称）。

忽略丢失的数据

WS-BPEL 实际指定在分配空数据时抛出运行时错误，例如，如果分配的源是未初始化的部分。不过，如果设置了业务流程的 Ignore missing data 属性，则会禁止这些异常。

图 8 显示了我们的示例流程启动了此属性。

正如我们在本文中介绍的那样，流程修复操作可能指示跳过长时间运行流程中的某些步骤；结果这些步骤的输出数据可能对后续步骤不可用。为了防止在以后访问数据时抛出运行时错误，最好启用此属性。

图 8. 忽略丢失的数据

图片看不清楚？请点击这里查看原图（大图）。

修复处于停止状态的活动

流程实例的任何位置都可能会发生异常。这些异常可能由业务流程逻辑中的建模或编码错误所导致（例如，访问未初始化的数据），或者由流程外部的问题所导致（例如，被调用的服务不可用）。某个活动可能在发生意外异常时而停止（因此不会处理该活动）。

在下面的情况中，我们假定设置了 Continue On Error 属性，规定在遇到未处理的错误时停止所有活动。

停止原因

流程中发生的异常可能始终与某个活动实例关联，并且可能在该实例实际实现前、实现过程中或实现之后发生，即一个实例可能在不同时间或不同的执行阶段停止。而且，当问题发生在某个活动的生命周期内时，时间或执行阶段用于确定可以执行哪些修复操作。

停止的活动实例带有另外一个属性 – 停止原因，该属性指示活动停止的阶段。我们将其分为三个执行阶段，因此有三种停止原因。

在激活活动时出现故障——停止原因：激活失败

在激活某个活动之前，必须满足特定的条件，即该活动的联接条件必须为 True。如果联接条件的评估失败，例如，在执行 Java 实现的联接条件时抛出异常，则停止原因为 ACTIVATION_FAILED。

在执行活动时出现故障——停止原因：实现失败

如果在实际实现活动的过程中发生异常，则停止原因为 IMPLEMENTATION_FAILED。

这是最常见的原因，也是多方面原因。其中包括：

赋值中的表达式访问变量的未初始化部分。

Java Snippet 中发生运行时异常。

调用外部服务返回意外错误。

人工任务的人员解析失败。

选择条件的 case 条件评估失败。

在保留活动时出现故障——停止原因：后续导航失败

在完成某个活动的实现之后，Business Flow Manager 将检索该活动的导出链接并评估这些链接上的转换条件。如果链接条件的评估失败，则活动将停止且停止原因为 FOLLOW_ON_NAVIGATION_FAILED。

修复操作

为了恢复在停止活动的流程导航，提供了以下两个修复操作：强制重试和强制完成。请注意，为了修复流程实例，可能需要更新一个或多个流程变量，以避免在应用其中某个功能之前再次发生相同的故障。

当某个活动是强制完成或强制重试时，您可以覆盖其 continue-on-error 行为。如果执行了此操作，并且活动再次失败，则该异常会传播到该流程的错误处理程序，并且该活动不会再停止。如果某个错误不在下一个封闭范围中处理，而是在其他封闭范围中处理，则此操作很有用。

强制重试

当某个活动为强制重试时，会再次运行该活动的实现。如果是调用活动或人工任务活动，则可以有选择地提供输入数据。注意，这些流程变量使用提供的输入数据进行更新。

如果用户希望重新执行某个活动（例如，如果某个调用活动由于服务不可访问而停止，但同时修复了该问题），则强制重试修复操作可能会非常有用。

强制完成

当某个活动为强制完成时，则会将该活动置于已完成 状态，并继续执行后续导航。对于调用、接收或人工任务活动，用户可以提供带强制完成请求的输出消息。它被视为活动的常规输出，并相应地更新流程变量。如果没有为调用活动或人工任务活动提供任何输出，则不会更新流程变量。

例如，管理员可以使用强制完成手动完成某个活动，并继续执行流程的预定义控制流，因为他预期重新运行该活动时，已发生的异常不会再发生。

注意，强制完成可以与跳转操作合并，请参阅“跳转到其他活动”部分以了解详细信息。

带错误强制完成

当强制完成某个活动时，可能会提供错误消息而不是输出消息。然后将该活动置于已失败 状态，并且将错误传播到下一个封闭范围的错误处理程序。如果发生意外错误，并且没有专门建模错误处理程序来处理该错误，则需要该操作。用户可以强制完成带错误的活动，以手动强制触发某个特定的错误处理程序（处理的错误与使活动实例停止的错误不同）来处理此错误。

修复操作和停止原因

对于每个停止原因，并不是允许执行所有的修复操作。活动的三个执行阶段、其停止原因以及允许的修复操作在下表中进行了总结。

表 1. 停止原因和允许的修复操作

活动的生命周期中的阶段	停止原因	允许的修复操作
联接条件评估	激活失败	强制重试
运行实际调用	实现失败	强制重试 强制完成
评估保留活动的链接的转换条件	后续导航失败	强制完成

如果该活动尚未开始，即停止原因是激活失败，则不允许强制完成此活动。在此情况下，通过激活该活动克服这些问题，同时强制完成请求在完成时解决问题非常重要。

如果已经完成该活动，但后续导航失败，则不再允许强制重试操作。这里，该问题位于以下区域，其中导航已经移动到后续活动，并且重新运行该活动的实现无助于克服此类问题。

修复处于停止状态的活动——示例

现在回到我们的示例流程。前面已经说过，我们重点介绍第一步 AlignCustomerData 范围，这在图 9 中进行了说明。该范围作为一个循环流实现。在第一步中，客户编号被复制到一个本地变量 (1)。如果客户编号不为空，即客户是已知客户，则遵循左侧的路径 (2)，并从客户注册服务中检索客户数据 (3)。对于新客户，将客户数据（如地址、银行连接等）输入到人工任务活动 ProvideCustomerData 中 (4)。接着，将这些数据插入到客户注册服务中 (5)。最后，将这两个路径合并在一起，并且此客户的当前红利在 Java snippet calculateBonus 中进行计算 (6)。

在简介部分已经提到，我们假定客户注册服务不可用并且所有调用都返回异常。结果，调用此服务的调用活动停止。

图 9. AlignCustomerData 范围的实现

图片看不清楚？请点击这里查看原图（大图）。

客户关系经理“Jeff”使用 Business Process Choreographer Explorer（简称 BPC Explorer）修复受停机影响的流程。

他打开 BPC Explorer 的 Critical Processes 视图，其中显示包含状态为已停止的活动的所有进程实例（参见图 10）。

图 10. 关键进程

图片看不清楚？请点击这里查看原图（大图）。

他调出第一个进程实例的活动实例列表，并发现 RetrieveCustomerData 活动的状态为已停止。该活动的详细视图显示在图 11 中。

Jeff 手动查看客户数据，并使用如图 11 所示的变量部分更新具有此信息的 customerData 变量。如图所示，他手动替换了已停止活动的实现。

他通过单击“Force Complete”按钮强制完成了该活动。

图 11. 已停止的活动 RetrieveCustomerData 的活动详细信息

图片看不清楚？请点击这里查看原图（大图）。

作为 BPC Explorer 的替代方法，还可以使用 Business Flow Manager API 编写一个客户机来执行修复操作，包括获取和设置变量。

更改流程的导航

在本部分中，我们将讨论用户如何影响或更改正在运行的进程实例的正常执行行为。在此上下文中共有两个主要功能。跳过和跳转。

跳过某个活动实例

假设在进程实例中不需要某个特定步骤，我们将使用一个标准的旅行预订流程作为示例进行说明。用户不需要预订旅馆，因为该旅行人员暂住在一个朋友的家中。在此情况下，较好的方法是能够跳过流程实例中的一个或多个活动。

使用 WebSphere Process Server V6.1.2，可以在每个活动执行状态中通过跳过请求来跳过所有基本活动。此请求可能对活动立即生效，例如，当该活动实际运行时，或者可以指向未到达的目标时。在后一种情况中，该活动将被标记为跳过，直到导航到达该活动为止。

重要说明：可以通过取消跳过请求取消挂起的跳过请求。

当通过请求跳过某个活动时，后续导航中的行为将与被跳过的活动的行为不同，因为其联接条件的值为 false。在这两种情况下，该活动都以已跳过 状态结束。不过，对于跳过请求，将评估并遵循所有导出链接。对于自动跳过，将作为“死路径”导航当前执行路径并且不评估链接条件。这两种情况都被视为 false。

跳过功能可以与停止的活动一起使用来修复无法预测的情况，还可以修复到目前为止没有发生异常而且流程执行路径被中断的情况，例如，被等待请求和完成的人工任务活动中断。

跳过处于活动状态的活动

当活动的实现已经启动，但在其完成之前，某个活动处于活动状态。处于活动状态的活动状态包括：正在运行、正在等待、就绪、已请求和已停止。

当对处于活动状态的活动请求跳过时，将中止该活动的实现，并且其状态将被改为已跳过。例如，如果跳过某个正在等待异步响应的调用活动，则将停止等待并将忽略以后从服务到达的响应。后续导航将继续执行，即，遵循所有导出链接并评估链接上的转换条件。

跳过未来活动

还可以跳过尚未到达的活动。当某个活动尚未到达时，其状态将为“非活动”，或者尚未创建活动实例。

跳过未来活动是指创建该活动（如果尚不存在），并将其标记为跳过，也就是设置“skipRequested”属性。当导航到达活动实例时，该活动的状态将立即被设置为跳过，并且不会运行其实现。在此之后，将取消设置“skipRequested”属性并且导航将像第一种情况中那样继续执行。取消设置“skipRequested”属性将不会再跳过该活动，如果该活动处于一个循环中或者一个循环流中将发生这种情况。

跳过处于结束状态的活动

如果已完成活动的实现，则该活动将处于结束状态。活动的结束状态包括：已完成、已终止、已跳过和已失败。当跳过某个处于结束状态的活动时，请求将指向此活动的下一个迭代，例如，如果该活动位于 while 循环中或者在循环流中。注意，没有验证是否可以到达某个活动的验证机制。因此，即使很明显不会再到达某个活动，也不会拒绝跳过请求，但该请求实际上无任何效果。对于处于非活动状态的活动，跳过请求会将当前活动实例标记为跳过。通常，如果再次到达该实例，则将创建一个继承此标记的新实例对象。然后，将不会运行该实现，但导航将像另外两种情况中那样继续执行。

取消活动实例的跳过请求

在尚未到达该活动或者该活动处于结束状态时，取消跳过请求可用于撤消跳过请求的影响。取消跳过请求用于取消设置“skipRequested”属性。

跳过某个活动实例——示例

现在再看看我们的示例流程。在上一个修复步骤中，Jeff 已使用强制完成克服了调用活动 RetrieveCustomerData 中的问题。尽管他手动查询了客户数据，但他发现最高红利利率已经分给了当前客户，于是他不让流程自己发现这种情况，而是决定跳过该流程中的相应步骤。因此，就在强制完成 RetrieveCustomerData 之前，他使用此信息更新了红利变量，并将 calculateBonus 活动标记为跳过。为执行此操作，他选择了 Process State View（如图 12 所示），单击 calculateBonus 活动，并从下拉菜单中选择 Skip Activity。务必理解的是，在强制完成 RetrieveCustomerData 之前必须请求跳过，这是因为流程导航将在强制完成调用之后立即继续执行。

图 12. 跳过活动实例“calculateBonus”

跳转到其他活动实例

在 WebSphere Process Server 6.1.2 中，现在可以手动覆盖正在运行的流程实例的实际状态。具体来说，您能够在控制流中执行跳转操作，从一个专用活动（源活动）跳转到另一个专用活动（目标活动）。只有在处于活动状态时才可以执行从某个活动实例跳出操作。跳转在语义上分为两个步骤：首先，该步骤的源活动结束，其次，跳转的目标活动执行。

跳转的活动的源可以通过三种方式结束。它们可能是已跳过、已完成或强制完成。因此共有三种可能的方式来执行跳转：跳过和跳转、强制完成和跳转、完成和跳转。注意，只有人工任务活动可以与跳转协同完成；所有其他活动类型需要强制结束。这意味着，在此情况下您还可以为此活动提供输出消息，并且在完成跳转之后该活动将处于完成状态。跳转行为对于这三种选项都是相同的。

重要说明：要在两个活动之间跳转，不要求目标活动是源活动的后续活动。您还可以执行“向后”跳转。只能从一个活动跳转到另一个活动，不支持多个源活动。跳转的目标必须是单个活动，但不必是基本活动；目标活动也可以是结构化活动。在源活动完成之后即执行跳转。

向前跳转具有以下特征：

不评估源和目标活动之间的链接上指定的任何转换条件，因此，假定在任何情况下都将执行跳转的目标。

源和目标之间的所有活动不是由工作流引擎激活的。这意味着，对于向前跳转将不执行这些活动。这还意味着，由这些活动产生的任何数据对于跳转的目标活动都不可用。因此，应注意由目标活动请求的数据。您可以手动设置变量的数据以确保能够正确执行目标。这种情况也在本文中进行了介绍（请参阅“修复处于停止状态的活动——示例”）。

向后跳转具有以下属性：

源和目标中的活动实例从数据库中删除，以便在完成跳转之后可以再次执行这些活动。

在此时间点，不涉及任何补偿。不过，如果之间的活动是一个范围活动，则补偿处理程序仍保持注册状态。

何处支持跳转？

源和目标活动必须满足特定的要求才能执行跳转。如果不能满足这些要求，将拒绝跳转请求。这些要求基于源活动的状态和流程模型的结构化组合。

为了执行跳转，跳转的源必须处于活动状态。可以执行跳转的源活动的可能状态包括：已请求、就绪、正在运行、已停止和正在等待。这些状态对于以下两种情况都有效：跳过和跳转以及强制完成和跳转。不过，由于完成和跳转仅在人工任务活动中允许，因此完成和跳转只有在已请求的状态下才能被调用。

只有在业务流程中具有唯一名称的活动才是潜在的跳转目标。不过，显示名称可以是相同的。

仅在与其他活动的完成组合时才允许跳转。跳转仅在跳过、强制完成或完成操作成功时才执行，例如，未发生任何运行时异常。

可以在序列和循环流中执行跳转，但不支持在并行流中跳转。在这两种情况中，源活动和目标活动都必须直接嵌入同一封闭结构中。既不能跳入结构化活动，也不能跳出直接封闭的结构化活动。但是可以跳过结构化活动。

不能使用附加的处理程序（即补偿处理程序、错误处理程序或撤消操作）从调用活动跳转。

当您使用 BPC Explorer 执行跳转时，将自动检查这些要求。因此，仅显示有效的跳转目标。

跳转到其他活动实例——示例

现在回到我们的示例业务流程。图 13 显示了位于人工任务活动 ProvideCustomerData 的流程实例。客户关系经理 Jeff 已经请求了此活动。Jeff 现在决定完成此活动并在 calculateBonus 继续执行，因为他知道如果注册服务不可用，后续活动 AddCustomerData 将失败。Jeff 将在以后的时间点在服务恢复工作时通过手动操作向注册中心添加新客户。

要在 BPCExplorer 中执行跳转，请完成以下步骤：

转到 Process State View 并单击活动 ProvideCustomerData。将显示一个提供不同选项的菜单。

选择 Jump to another Activity。

图 13：从活动 ProvideCustomerData 跳转到活动 calculateBonus

技巧：BPC Explorer 突出显示可以作为有效跳转目标的所有活动，并淡出其他活动。由于跳转的源包含在循环流中，因此，此循环流中直接包含的所有活动都是有效的跳转目标。由于不可能跳出结构化活动，因此淡出了循环流中未包含的活动。图 14 显示了所有可能的跳转目标。

图 14. 从活动 ProvideCustomerData 跳转的可能目标

要跳转到 calculateBonus，请左键单击相应的活动。

图 15：选择跳转的目标 calculateBonus

技巧：图 15 显示的菜单提供了应如何处理源活动的选项。用户可以完成、强制完成或跳过源活动。选项“complete”仅在跳转的源是请求的人工任务活动时才可用，否则将不显示此选项。Jeff 决定完成人工任务活动。

在下一个屏幕中，您可以编辑活动 ProvideCustomerData 的输出消息。

图 16：为使用 ProvideCustomerData 作为源活动的完成和跳转提供输出消息

输入客户数据并单击 Complete and Jump。输出消息将作为人工任务活动的输出，并且导航将在所选的目标 calculateBonus 继续执行。

手动更改导航的常见缺陷

当某个活动由于跳过请求而被跳过或忽略时，将不会运行其实现。因此，活动对流程实例和流程实例外部的整个应用程序系统的影响会消失。对于向后跳转，可能多次执行活动，这也可能对进程有影响。在执行跳过或跳转之前需要检查这些影响，以避免不良的负面影响。此外，活动执行的这些积极影响可能需要由手动操作代替实现。

对流程实例本身的影响

本地和全局变量

例如，假设有一个被跳过的分配活动。那么对该分配的本地和全局变量的所有更新都不会发生。不过，该流程中的后续步骤可能需要这些更改。可以通过 get-/set-variable API 请求或在 BPC Explorer 中更新或初始化全局和本地变量。

相关集的值

消息活动（即接收、应答、调用和拾取活动）可以使用其输入和输出消息初始化或验证相关集的值。这是一项重要功能，例如将外部请求与正确的流程实例进行关联。跳过或忽略启动相关集的活动可能至关重要，这是因为相关集可能由其他活动使用。

接收-应答对

另一个不一致的源是属于同一双向操作的接收-应答对；当只有其中一个活动运行，另一个活动由于跳过请求而被跳过或者未执行时将会出现不一致情况。当双向请求的接收活动被跳过或被忽略时，相应的应答活动也应被标记为跳过或忽略。如果以某种方式执行了应答，则应答活动会失败或停止，并显示一个错误，指示未找到相应的接收活动。如果停止，您可以强制完成该活动，但这在以后可能需要进一步手动干预。如果跳过应答活动，则请求在流程完成之前仍保持开启状态，并向调用方返回错误。应避免跳转到正在进行初始化且没有定义相关性的接收活动。

活动的多次执行

对于向后跳转，导航将在目标活动继续执行，结果可能会再次执行某些活动，这具体取决于控制流。例如，可能重新执行调用活动，并再次启动子流程。请注意，对于向后跳转，不会补偿位于源和目标之间的活动。由于可能会执行两次活动，因此您需要相应地处理它们。一种解决方案要求活动是等幂的，或者能够通过某种方式处理第二次调用。另一种解决方案是在执行跳转请求之前将该活动标记为跳过，以便不会再次执行该活动。注意：将该活动标记为跳过应在请求跳转之前执行。

跳过活动

向前跳转是指直接在目标活动继续执行导航；源和目标活动之间的所有活动均被忽略。这些活动既不会被跳过也不会在以后捕获，因此由这些活动产生的任何信息在业务流程的进一步导航过程中都不可用。如果希望其中的某个活动运行，则可以回跳到此活动并将其他不需要再次执行的活动标记为跳过。

逻辑错误跳转

跳转目标可能不是涉及业务流程逻辑的有效跳转目标。例如，在循环流中，允许在任何位置跳转。假设有一个具有互斥分支的循环流；每个分支都有一些应用于该分支中所有活动的前置条件和不变量。如果跳转请求跨过这些分支，则可能会违反这些条件，并可能会导致意外的行为和异常。因此，通常情况下，每当用户执行跳转时，他们应检查流程的业务逻辑的有效性。

对周围应用程序的影响

当忽略服务调用时，进程实例状态可能与其余的软件应用程序失去同步。例如，假设有两个长时间运行的流程，相互与多个操作通信。一个流程可能假定按一定的顺序接收请求，并可能偶然收到不需要的请求。

您可以考虑使用 SCA（服务组件体系结构）方法调用流程的合作伙伴来模拟跳过的活动。如果这些合作伙伴是其他长时间运行的流程实例，则对合作伙伴实例进行流程修复也非常有用。

结束语

流程修复对可以应用于正在运行的流程实例的一组操作进行了总结。这些操作旨在帮助您在建模时从无法预见的异常情况中恢复。流程修复操作可应用于任何长时间运行的流程实例。不过，要最有效地应用这些功能，较好的方法是在建模时考虑某些特定方面（如 continue-on-error 属性），并明智地分配管理权限。本文为您介绍了这些修复是如何执行的；即：强制完成、强制重试、跳过和跳转、在理论和示例中执行。使用这些功能可能不足以解决关键情况，并且您可能需要：更新内部流程状态，例如，更新变量内容和/或干预流程外部的整个应用程序系统。

本文说明了您在使用跳过和跳转操作时需要细心，因为这些操作会导致遗漏或重新执行流程的某些区域，从而可能导致缺少流程实例的其他区域中的信息。您还学习了，尽管对有效跳转目标有一组限制，但允许的跳转目标从应用程序角度而言可能是无效的。您需要通过研究流程模型及其意图来检测此无效性，以避免此类跳转。