BizTalk 2013 在源文件完成之前启动消息处理？答案

【问题标题】：BizTalk 2013 Start Message Processing Before Source File Finishes?BizTalk 2013 在源文件完成之前启动消息处理？
【发布时间】：2014-01-21 21:29:45
【问题描述】：

我们有一个大而复杂的文件，需要很长时间才能反汇编（比如一个小时）。如果我们可以在消息离开接收管道时分拆消息并在文件完成之前立即开始他们的行程，那将是很棒的。我可以说这不是简单，但有可能吗？

【问题讨论】：

【解决方案1】：

不是开箱即用的。管道反汇编是事务性的，因此，如您所见，整个交换被分批并立即提交到 MessageBox。

这里有一些选项：

如果您收到一个平面文件，其中每行都是一条消息，请使用 SSIS 将其加载到表中，然后使用 SQL 适配器，通过一次轮询约 10 条消息来排出消息。
如果您正在接收复杂的平面文件或 Xml，您可以将 XmlDasm 或 FFDasm 包装在自定义反汇编程序组件中，但不是将分批的消息返回到 MessageBox，而是将它们推送到其他地方。 A）如果不需要订单，文件系统很容易。 B) MSMQ 将保持消息在文件中出现的顺序。

在传入文件有 100k 到 400k 记录的情况下，我都使用了这两种方法，它确实提供了更易于管理的性能配置文件。

【讨论】：

非常有帮助，谢谢——我们有一个非常复杂的 FF 格式，因此在反汇编程序之前将其拆分并不容易。你知道是否有可能在反汇编程序或（甚至更好的）管道中将单独的反汇编消息推送到不同的接收端口或某个地方，此时它变成离散消息？
那么你需要选项#2。您可以从这里开始：msdn.microsoft.com/en-us/library/aa560024.aspx。这真的很容易。在您的 GetNext 实现中，继续调用 base.GetNext 并将返回的消息发送到其他地方、文件、MSMQ 等。
谢谢大家！任何人都可以将这样做与使用可恢复交换处理进行比较吗？
RIP 在基本反汇编程序方面的工作方式基本相同，这意味着它会在出现可恢复的错误后继续进行分批。抱歉，我不记得你是如何在包装反汇编器中检测到这一点的，但它应该很容易测试。