在我的场景中，我有一个管道，它 (1) 解密然后 (2) 在接收端口上反汇编一个平面文件。
我的要求是捕获文件，并将其放在 (1) 和 (2) 之间的本地文件共享中。
我最初的方法是在它们之间引入一个存档组件，但我遇到了这个问题。存档组件使用对存储的直接访问来转储文件。这本质上是一种糟糕的方法，根据 BizTalk 原则，这是发送端口/发送适配器的功能。因此，例如，如果归档目标是 FTP 主机，则归档组件是无用的。
于是想到了两个想法：
A）以某种方式配置归档组件以使用发送端口（如果可能的话）
B) 放弃归档组件的想法，只使用 BizTalk 的原生功能如下：
- 使用仅解密管道接收文件
- 使用发送端口将文件发送到临时本地存储
-订阅接收端口以将文件发送到存档
- 使用 Disassemble 管道从本地存储中提取文件（第二个接收端口）
- 使用编排处理来自第二个接收端口的文件。
选项 B) 有什么问题吗？
如果不是，那么即使使用存档组件又有什么意义呢？
如果您使用的是本机 Biztalk功能，则设置订阅消息类型的发送端口以进行存档就足够了。
如果您使用的是BizTalk ESB 工具包，则很难拆分消息以进行归档，因为您是在管道上下文中执行的。在您的行程中使用编排将允许您拆分消息，但这当然需要行程离开管道并将消息放在消息框上。仅进行简单的消息存档可能会使此解决方案过度杀伤。
您可以使用自定义管道组件，如下所示。它是一个可以重复使用的管道组件，在 BizTalk ESB 工具包场景中工作（如果您想要原始消息非常方便，因为它已被转换），作为文件存档或 SQL 存档，并且适用于入站和出站管道场景。
您将只负责维护旧的/不需要的消息以避免膨胀。
其他选项还包括
C) 有一个归档发送端口和一个环回发送端口订阅接收端口，环回发送端口将在接收端具有平面文件反编译器。
D) 有一个存档发送端口和一个订阅接收端口的编排。在 Orchestration 中调用 dissemble 管道。
我们已经将这两种场景用于不同的解决方案。