BizTalk存档管道组件考虑事项

在我的场景中，我有一个管道（1）解密，然后（2）在接收端口上反汇编平面文件

我的要求是捕获文件，并将其放在（1）和（2）之间的本地文件共享上

我最初的方法是在它们之间引入一个归档组件，但我遇到了这个问题。存档组件使用对存储的直接访问来转储文件。这实际上是一种糟糕的方法，根据BizTalk原则，这是发送端口/发送适配器的功能。因此，例如，如果存档目标是FTP主机，则存档组件是无用的

因此，我想到了两个想法：

A） 以某种方式将存档组件配置为使用发送端口（如果可能的话）

B） 放弃归档组件的想法，只需使用BizTalk的本机功能，如下所示：

-使用仅解密管道接收文件

-使用发送端口将文件发送到临时本地存储

-订阅接收端口以将文件发送到存档

-使用反汇编管道（第二个接收端口）从本地存储中提取文件

-使用业务流程处理来自第二个接收端口的文件

选项B是否存在任何问题

---

如果没有，那么使用归档组件还有什么意义呢？

其他选项也包括

C） 有一个存档发送端口和一个环回发送端口订阅接收端口，环回发送端口将在接收端口上有平面文件分解器

D） 具有存档发送端口和订阅接收端口的业务流程。调用编排中的分解管道

---

我们已将这两种方案用于不同的解决方案。

如果您使用的是本机Biztalk功能，设置订阅要存档的消息类型的发送端口就足够了

如果您使用的是BizTalk ESB Toolkit，则很难分割消息进行归档，因为您是在管道上下文中执行的。在行程中使用编排将允许您拆分消息，但这当然需要行程离开管道并将消息放到消息框中。仅做简单的消息存档可能会使此解决方案变得过于简单

您可以使用自定义管道组件，如下面的组件。它是一个可以重用的管道组件，在BizTalk ESB工具包场景中工作（如果您想将消息转换为原始消息，则非常方便），可以作为文件存档或SQL存档，并在入站和出站管道场景中工作

---

您将只负责维护旧邮件/不需要的邮件，以避免邮件膨胀。

非常好的选择。这是一个关于如何做的示例（D）