BizTalk 自定义适配器
我不确定我是否提出了正确的问题，但这就是我正在尝试运行的场景：
多个文件（XML 和一些相关文件，“附件”）必须作为单个消息进入 BizTalk。我已经研究了现有的适配器，但没有发现现有的适配器已经完成了。更准确地说，文件是从文件系统中获取的。当不能保证顺序时，文件不会同时找到，而是一次到达一个。 XML（内容）文件是一种知道它必须具有哪些附件（还有哪些其他文件）的文件。
我们正在研究 BizTalk 2009，我想知道是自定义适配器的责任还是其他什么。我是否可以寻找样品。
谢谢。
I am not sure if I ask the right question, but this is the scenario I am trying to run:
Multiple files (XML and a few related files, "attachments") have to get into BizTalk as a single message. I have looked into existing adapters, and don't see that done with existing once. To be more accurate, files are taken from file system. Files are not found at the same time, but arrive one at a time, when order is not ensured. XML (content) file is the one that knows what attachments it has to have (what other files).
We are looking into BizTalk 2009 and I was wondering would be that responsibility of a custom Adaptor, or something else. And were I could look for samples.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
使用自定义适配器可能可以完成您想要的操作，但我建议不要这样做。您可以使用编排来实现您的需求。
您正在寻找的就像一个车队，或者至少是一些相关性的使用。
在 BizTalk 中，车队是一种消息传递模式（与 BizTalk 功能相反），它允许通过单个编排处理消息组。
您本质上是在接收端口上使用相关性以并行（您可能想要的）或顺序方式将消息分组在一起。
[此处](http:/ 有一篇文章/msdn.microsoft.com/en-us/library/ms942189(BTS.10\).aspx），作者：Stephen W. Thomas 关于车队（适用于 BT 2004，但概念仍然有效），并且有一个网络和书籍上有很多附加信息（Professional BizTalk Server 2006 有一个关于它们的小节）
如果没有有关您的场景的更多详细信息，很难确切地知道如何构建车队，但下面是两种可以查看的方法（另外，我还没有机会正确使用 BT2009，因此可能会有对相关场景的扩展支持来帮助您）。
灵活关联
如果您对上下文 XML 中列出的文件一无所知，您可能需要一种类似于 Charles Young 在 这篇文章。
非均匀顺序护航
如果您事先确实有一点信息，一种方法可能如下（基本上是非均匀顺序护航）：
这假设存在某种链接方式所有文件放在一起，以便您可以将它们关联起来。
创建订阅您的入站接收端口（其中包含文件接收位置）的单个编排。
此编排将具有为您的内容文件设置的单个激活接收形状。
一旦内容文件启动编排，第二个相关接收形状就会开始拾取与该内容文件匹配的消息。 （第二次接收可能处于循环中，以允许可变数量的文件）
然后将它们全部打包到设计的单个出站文件中，并在收到完整数量的文件后将它们发送出去。
It is probably possible to do what you want using a custom adapter, though I'd recommend against it. You can achieve what you require using orchestration.
What you are looking for is likey a convoy, or at the least some use of correlation.
In BizTalk a convoy is a messaging pattern (as opposed a BizTalk feature) that allows groups of messages to be processed by a single orchestration.
You essentially use correlation on a receive port to group messages together in either a parallel (what you probably want) or sequential fashion.
There is an article [here](http://msdn.microsoft.com/en-us/library/ms942189(BTS.10\).aspx) by Stephen W. Thomas about convoys (it is for BT 2004 but the concepts still hold) and there is a lot of additional information on the web and in books (Professional BizTalk server 2006 has a subsection on them)
Without more details on your scenario it is hard to know exactly how the convoy would be built but below are two approaches to look at (also, I've not had a chance to properly use BT2009 so there may be extended support for correlation scenarios that help you out).
Flexible Correlation
If you don't know anything about the files listed in the context XML you will probably need a pattern like the one described by Charles Young in this post.
Non-uniform sequential convoy
If you do have a little bit of info before hand one way might be as follows (basically a Non-uniform sequential convoy):
This makes the assumption that there is some way of linking all the files together so you can correlate them.
Create a single orchestration that subscribes to you inbound receive port (which contains the file receive location).
This orchestration will have a single activation receive shape that is set up for your content file.
Once the orchestration is started by a content file a second correlated receive shape starts picking up the messages that match that content file. (this second receive could possible be in a loop to allow for variable numbers of files)
You then pack them all together into a single outbound file of your design and send them out once the full number of files has been received.
在我看来，更好的方法是结合自定义管道组件和/或自定义适配器来实现上述要求。我假设您并不真正需要操作传入的文件（内容 XML 文件除外），或者您不能操作，因为它们是二进制格式。这需要一个自定义管道组件。
您可以做的是开发自定义 BizTalk 适配器来与文件系统交互并实现侦听和循环逻辑。接下来，您可以开发自定义管道组件来创建单个 BizTalk 消息，其中可能包含用于二进制数据的 base64 数据类型。此外，您还可以直接在此组件中提升消息以启用编排订阅。
编排更适合实现消息已经采用 XML 格式的业务工作流场景。事实似乎并非如此。无论如何，我认为至少需要一个自定义管道组件。
Seems to me a better approach would be to implement the above requirements with a combination of a custom pipeline component and/or a custom adapter. I assume you do not really need to manipulate the incoming files - except for the content XML file - or that you couldn't since they are in binary format. This calls for a custom pipeline component.
What you can do is develop a custom BizTalk adapter to interact with the file system and to implement the listening and looping logic. Next you can develop a custom pipeline component to create a single BizTalk message perhaps with base64 data type in it for binary data. Additionally you could also promote messages right in this component to enable orchestration subscriptions.
Orchestrations are more suited for implementing business work-flow scenarios where the messages are already in XML format. This do not appear to be the case. In any case I think at the very least a custom pipeline component would be needed.
大卫的答案是正确的答案。
即使您对预期附件的内容一无所知，您也肯定知道它们的名称和位置。因此，您可以使用大卫答案中链接的灵活关联，如下所示：
解决方案的关键是关联内置的 BTS.ReceivedFileName 属性。
首先，创建一个自定义接收管道，其中包含一个自定义管道组件，该组件可提升所接收消息的 BTS.ReceivedFileName 上下文属性。这个简单的自定义组件相当容易编写，但您可以通过使用第三方框架使其变得简单，例如（这里是无耻的插件）我的PipelineComponentBase 类或优秀的 BizTalk Server 管道组件向导。
现在是简单的部分：
请注意，您实际上需要发送一条消息才能初始化关联。您实际发送什么消息并不重要。我要做的就是通过包含空管道组件的发送管道发送消息。这是一个管道组件，它读取消息但返回 null（以便消息在到达适配器之前消失得无影无踪）。更复杂的解决方案是使用 null 适配器。这是一个读取消息但不执行任何操作的适配器。
这两种解决方案避免了在某个临时位置累积许多文件，只是为了初始化关联！
David's answer is the correct answer.
Even in cases where you don't know absolutely nothing about the contents of the expected attachments, surely you know their names and locations. Therefore you can use the Flexible Correlation linked to in david's answer like this:
The key to the solution is to correlate on the builtin BTS.ReceivedFileName property.
First, create a custom receive pipeline, with a custom pipeline component that promotes the BTS.ReceivedFileName context property of the received messages. This simple custom component is fairly easy to write but you can make it straightforward by using third-party frameworks such as, (shameless plug, here) my PipelineComponentBase class or the excellent BizTalk Server Pipeline Component Wizard.
Now for the easy part:
Notice that you actually need to send a message in order to initialize the correlation. It does not matter what message you send actually. What I'd do is send the message through a send pipeline that contains an empty pipeline component. That is a pipeline component that reads the message but return null (so that the message vanishes into thin air before it reaches the adapter). A more elaborate solution would be to use a null adapter. That is an adapter that reads the message but does not do anything about it.
These two solutions avoid having many files accumulate in a temporary location somewhere, just for the sake of initializing a correlation!