我不知道如果我问正确的问题，但是这是我试图运行的方案：的BizTalk自定义适配器
多个文件（XML和一些相关文件，“附件”）必须进入BizTalk作为单个消息。我查看了现有的适配器，并没有看到现有的一次完成。为了更加准确，文件从文件系统中获取。文件不能同时找到，但是不能保证订单时一次到达一个文件。 XML（内容）文件是知道它必须具有哪些附件（其他文件是什么）的文件。
我们正在研究BizTalk 2009，我想知道是自定义适配器或其他的责任。我可以找样品吗？
谢谢。
这可能是可以做到你想使用自定义适配器，但我建议不要这样做。您可以使用编排来实现您的要求。
你在找什么就像一个车队，或者至少有一些使用的相关性。
在BizTalk中，车队是一种消息传递模式（与BizTalk功能相反），它允许单个业务流程处理消息组。
实际上，您使用接收端口上的相关性将消息按并行（您可能需要）或顺序方式分组在一起。
Stephen W. Thomas的文章[here]（http://msdn.microsoft.com/en-us/library/ms942189(BTS.10).aspx)）关于车队（这是为BT 2004，但概念仍然存在），并且网上和书籍上有很多附加信息（专业BizTalk服务器2006年对他们有一个小节）
没有关于你的情况的更多细节，很难确切知道如何建立车队，但下面是两种方法来看待（也没有机会正确使用BT2009所以可能会延长对相关场景的支持，帮助您解决问题）
灵活的相关性
如果您不了解上下文XML中列出的文件的任何内容，您可能需要一个类似于Charles Young在this后所描述的模式。
非均匀连续的护航
如果你有前手信息的一点点一种方法可能如下（基本上是一个非均匀连续的车队）：
这使得假设有一些方法可以将所有文件链接在一起，以便将它们关联起来。
创建订阅您的入站接收端口（包含文件接收位置）的单个业务流程。
此业务流程将为您的内容文件设置单个激活接收形状。
一旦内容文件启动编排，第二个相关的接收形状开始拾取与该内容文件相匹配的消息。（第二次接收可能在一个循环中以允许可变数量的文件）
然后，您将它们全部打包到设计的单个出站文件中，并在收到完整数量的文件后将其发送出去。
对我来说似乎更好的方法是使用自定义管道组件和/或自定义适配器来实现上述要求。我假设你并不需要操纵传入的文件 - 除了内容XML文件 - 或者你无法操作，因为它们是二进制格式。这需要一个自定义管道组件。
你可以做的是开发一个定制的BizTalk适配器来与文件系统交互并实现监听和循环逻辑。接下来，您可以开发一个自定义管道组件来创建一个单一的BizTalk消息，其中可能包含base64数据类型以用于二进制数据。此外，您还可以在此组件中促进消息，以启用业务流程订阅。
编排更适合于实现业务工作流场景，其中消息已经是XML格式。这似乎并非如此。无论如何，我认为至少需要一个自定义管道组件。
谢谢。这听起来像我们将不得不做的。我们将需要对涉及编排/外部服务的消息/附件进行操作。 – 2009-11-17 20:05:26
大卫的回答是正确的答案。
即使您对预期附件的内容完全不了解，也一定知道它们的名称和位置。因此，您可以使用灵活关联链接到这样的大卫的回答：
解决方案的关键是关联内置BTS.ReceivedFileName属性。
首先，创建一个自定义接收管道，使用自定义管道组件来提升接收到的消息的BTS.ReceivedFileName上下文属性。这个简单的自定义组件相当容易编写，但您可以通过使用第三方框架，如（无耻插件，这里是），我的PipelineComponentBase类或优秀的BizTalk Server Pipeline Component Wizard使它变得简单。
现在对于比较容易的部分：
请注意，您实际上需要发送消息以初始化关联。实际发送的信息无关紧要。我要做的就是通过发送管道发送消息，该管道包含一个空的管道组件。这是一个读取消息但返回null的管道组件（以便消息在到达适配器之前消失）。更复杂的解决方案是使用适配器。这是一个读取消息的适配器，但对此不做任何处理。
这两个解决方案避免了许多文件在某处的临时位置积累，只是为了初始化相关性！
David， 感谢您提供此信息。护卫队看起来很有趣，但我不确定在这种情况下它将如何工作。你看，附件是二进制文件，并且对内容XML文件一无所知。这些附件没有任何促进。也许我错过了一些东西，随时指出这一点。 10x 肖恩 – 2009-11-09 14:52:05
这显然是正确的答案。即使你对XML文件的内容一无所知，你一定知道它的名字和位置。从这里，你可以使用灵活的相关性如下： – 2010-12-18 21:15:53