简介和动机

通用拆分器和迭代拆分器是IFlow（集成流）中最常用的流步骤之一。它通过将非常大的传入XML有效负载分割成更小的块以供进一步处理，有助于减少IFlow的内存占用。在流模式下，拆分器不创建内部DOM，大数据是数据，甚至在到达负载末尾之前就开始生成块。这意味着拆分器本身的内存占用非常小。

请记住：一般拆分器保留到第一个拆分点的所有节点，而迭代拆分器只提取拆分点的节点。

在本博客中，我将解释迭代/常规拆分器的选项"Stop on Exception"。

选项"Stop on Exception"

在下面的场景中，集成过程包含一个内容修饰符，它在消息体中有一个XML负载。有效负载被发送到子进程"GS\u Router"。

让我们以下面的有效负载为例：

子进程"GS\u Router"中的常规拆分器使用XPath表达式"//z"将此有效负载拆分为六个块，这些块由"Send"步骤发送到Receiver2。一旦整个负载被拆分，没有任何异常，IFlow以状态COMPLETED结束。

为了模拟异常，我们可以在子进程的路由器中定义一个条件表达式//z[@id="3〃]。在这种情况下，第三次拆分将导致"错误结束事件"。接下来会发生什么取决于我们如何设置拆分器选项"异常时停止"。

如果设置了此选项，则拆分器在第三次拆分后停止，自助建站服务，IFlow以失败状态结束。3个文件由Receiver2创建。如果未设置此选项，物联网产品，拆分器将继续拆分，Receiver2将获得所有6个块。在这里，IFlow以失败状态结束。

在下一个场景中，我将所有步骤移到主集成过程中。

如果路由器保持在默认路径上，Receiver1将获得与Receiver2相同的块数。在我们的示例负载中，淘客佣金，Receiver1和Receiver2都创建了6个文件。

如果路由器有一个条件表达式，导致在第三次拆分后出现"错误结束事件"，那么这里的行为也取决于是否设置了拆分器选项"在异常时停止"。

如果设置了此选项，则拆分器在第三次拆分和IFlow之后停止以失败状态结束。Receiver2创建了3个文件。Receiver1只创建了2个文件。如果未设置"Stop on Exception"选项，则拆分器将继续拆分，物联网技术应用，Receiver2将获得所有6个块。IFlow以失败状态结束，Receiver1只创建5个文件。

我们注意到Receiver1总是比Receiver2少创建1个文件。什么文件丢失了？为什么？

为了回答这个问题，我们通过一个异常子进程来扩展集成过程。

如果我们运行这个场景，Receiver3总是会得到下面的块

那就是Receiver1丢失的文件！这是第三个块，引发了异常。

在博客的末尾，我将告诉您如何在SFTP接收器中使用拆分器时创建唯一的文件名。

在下面的屏幕截图中，我们看到SFTP接收器的目标：

如果选择"追加时间戳"，您可以为每个文件名添加时间戳。但是，拆分器生成的块太快，因此此功能的时间分辨率不够。

要获得真正唯一的文件名，可以使用变量${exchangeId}作为文件名的一部分。

另外${属性.索引}可用于按顺序对块进行编号。

进一步阅读

了解更多配置关于分路器的建议也可以查看以下博客：

在本地流程中使用分路器流步骤迭代/通用拆分器的"分组"选项新拆分器版本1.2的性能一般使用并行处理和迭代拆分器带异常处理的通用和迭代拆分器的使用