这个博客描述了如何在拆分器场景中配置异常处理。它描述了一些使用不同异常处理配置的示例场景中的拆分器。

在许多云集成场景中，云服务器平台，使用拆分器模式将大消息拆分为更小的部分。然后在云集成中处理较小的块。在这种情况下，可能会发生多个错误，这些错误可以用不同的方法处理。本博客给出了一些一般性建议，并介绍了一些示例场景中可用的选项。

一般性建议

对于使用具有异常处理的拆分器，有一些重要的建议：

中定义的异常处理拆分器优先于异常子流程中定义的结束事件，以继续下一次拆分。这意味着只有在未设置Stop on Exception的情况下才执行下一次剥离。如果设置了Stop on Exception，则下一次剥离将不再独立于异常子流程中使用的结束事件执行。由于这种运行时行为，我们建议仅使用以下组合：

将异常停止与错误结束事件结合起来

如果在拆分器中设置异常停止标志，请使用"不使用异常子进程"，或者如果需要特定的错误处理，请将异常子进程配置为以错误结束事件结束。

使用在这种组合中，什么叫大数据分析，消息结束事件可能会导致意外的行为，因为结束事件只与单个拆分相关，而与整个拆分处理无关。这意味着，整个拆分处理将停止。

如果没有使用聚集，则处理将以完成的消息结束，即使由于拆分处理停止而没有执行或尝试执行所有拆分。如果使用聚集，则只会完成单个拆分，但不会再执行下一个拆分处理。处理将继续进行已在聚集中执行的拆分。消息的最终状态将取决于进一步的消息处理。

由于这种运行时行为，我们建议在设置了停止异常时始终使用错误结束事件。

在使用消息结束事件时不要设置停止异常

如果没有在拆分器中设置停止异常标志，请使用无异常子流程，或者，如果需要特定的错误处理，请将异常子流程配置为以消息结束事件结束。

在这种组合中，使用错误结束事件可能会导致意外行为，因为结束事件仅与单个拆分相关，不适用于整体拆分处理：整体拆分处理将继续。

如果不使用聚集，则处理将以失败消息结束，但下一个拆分仍将执行，因为拆分器中未设置Stop on Exception。如果使用聚集步骤，则只有单个拆分将结束，51返利，但整个处理将继续。最终消息状态将取决于进一步的消息处理。

由于这种运行时行为，我们建议在未设置Stop on Exception时始终使用消息结束事件。

在单独的本地进程中处理单个拆分（拆分器和聚集之间或拆分器之后，如果未使用聚集）。执行所以，您可以使用此本地进程中的异常子进程为拆分处理中发生的错误配置专用异常处理。

将拆分器与收集步骤一起使用时，还应遵循以下建议。

如果在异常子进程中处理拆分错误并使用收集步骤在Splitter之后，创建一个有效的XML来传递给Gather步骤。否则，由于格式错误，收集步骤可能会因错误而停止，整个消息处理将以失败状态结束。

在收集步骤中使用相同或不同格式的组合XML时，避免在异常子流程中配置拆分器-收集场景而不进行错误处理。否则，收集步骤可能会因错误而停止，因为异常发生时的负载格式错误（错误的XML或根本没有XML），整个消息处理将以失败状态结束。

让我们讨论如何在一些示例场景中遵循建议。首先，我向您展示一些使用拆分器但不使用聚集的示例场景。根据场景的总体用例，存在具有不同异常处理的不同场景。接下来，我将描述使用拆分器和聚集的示例场景中的具体建议。

不带聚集的拆分器场景

以下场景是使用拆分器的简单示例场景，在拆分器之后不带聚集步骤。

场景1：不带聚集的拆分器，在异常情况下停止

场景：

如果您希望的话停止完整的消息处理如果在处理其中一个拆分时出错，最简单的方法是使用拆分器中的stop on Exception选项进行配置：

在这个示例场景中，SOAP适配器接收到一个批量消息，然后将该消息拆分为单个块。单个块的处理在单独的本地进程中完成。在示例场景中，只有一个请求-应答调用获取额外的数据。然后将单个拆分发送到接收器。

注意以下要点：

在这种情况下，没有配置异常子进程。如果您需要在异常子流程中配置特定的异常处理，并且希望使用stop-on-exception停止整个处理，请遵循场景2中的建议。

如果消息处理过程中发生错误，大数据的内容，则处理将停止，消息将处于失败状态。如果某些拆分在错误发生之前已成功执行，则它们的数据已发送到接收器，不可能回滚已执行的调用。这意味着，原始消息的一部分已经发送给了接收方，有些没有。

发送方系统通常会返回失败状态并重新发送消息（如果配置为重试）。当发送方系统重新发送消息时，整个消息将再次执行。