BizTalk 动态反汇编程序问题 - 正文部分为 NULL答案

【问题标题】：BizTalk Dynamic Disassembler Problems - The body part is NULLBizTalk 动态反汇编程序问题 - 正文部分为 NULL
【发布时间】：2013-12-31 22:39:53
【问题描述】：

我从这里的解决方案开始http://social.technet.microsoft.com/wiki/contents/articles/20547.biztalk-server-dynamic-schema-resolver-real-scenario.aspx 除了发送端口之外，它完全符合我的场景，但这不是必需的。我需要接收端口来选择文件并应用架构进行反汇编。从他们的编排中进行映射，其中一些是自定义的，等等。

我已经完成了教程中的所有操作，但我不断收到以下错误。 “执行接收管道失败...正文部分为NULL”

我没有从教程中得到但不认为它们应该成为问题的东西是：

我创建了一个新的解决方案和项目来制作 custompipeline 组件（参考图 19）和 dll 文件。意味着它在它自己的命名空间上。然而，从教程看来，他们在主要的 biztalk 解决方案（即具有管道和编排的解决方案）中创建了项目，因此命名空间具有“TechNetWiki.SchemaResolver”。在里面。我应该让 custompipeline 组件具有我的主要解决方案的命名空间吗？我认为这应该无关紧要，因为我应该能够在其他解决方案中使用这个组件，因为它对与 biztalk 应用程序关联的业务规则是通用的。
我没有的另一部分是“THEN Action”下的图 15，他们将其设置为他们想要反汇编到的目标模式，但随后他们将 #Src1 放在“http://TechNetWiki.SchemaResolver.Schemas.SRC1_FF#Src1”的末尾”。 #Src1 有什么用？

【问题讨论】：

标签： c# biztalk business-rules biztalk-schemas

【解决方案1】：

在您链接到的示例中，管道组件的探测方法将文件名中的前 4 个字符推送到输入消息中，然后将其传递给规则引擎。它与示例中的“SRC1”匹配的那 4 个字符。

string srcFileName = pInMsg.Context.Read("ReceivedFileName", "http://schemas.microsoft.com/BizTalk/2003/file-properties This link is external to TechNet Wiki. It will open in a new window. ").ToString();
srcFileName = Path.GetFileName(srcFileName);

//Substring the first four digits to take source code to use to call BRE API
string customerCode = srcFileName.Substring(0, 4);

//create an instance of the XML object
XmlDocument xmlDoc = new XmlDocument();
xmlDoc.LoadXml(string.Format(@"<ns0:Root xmlns:ns0='http://TechNetWiki.SchemaResolver.Schemas.SchemaResolverBRE This link is external to TechNet Wiki. It will open in a new window. '>
    <SrcCode>{0}</SrcCode>
    <MessageType></MessageType>
    </ns0:Root>", customerCode));
//retreive source code in case in our cache dictionary
if (cachedSources.ContainsKey(customerCode))
{
   messageType = cachedSources[customerCode];
}
else
{
TypedXmlDocument typedXmlDocument = new TypedXmlDocument("TechNetWiki.SchemaResolver.Schemas.SchemaResolverBRE", xmlDoc);
Microsoft.RuleEngine.Policy policy = new Microsoft.RuleEngine.Policy("SchemaResolverPolicy");
                    policy.Execute(typedXmlDocument);

所以匹配规则是基于文件名的前 4 个字符。如果不匹配，则探测器返回 false - 即无法识别。

最后一部分是消息类型被推送到返回的消息中——这个is made up of 命名空间和带有# 分隔符的根模式节点——所以你的#src1 是根节点。

【讨论】：

感谢杰森的回复。不幸的是，它似乎没有奏效。我的文件名规则正确，#src1 指的是我的根目录，而不是我想反汇编到的模式。奇怪的是，规则没有被采纳。看起来很简单。
您是否尝试过使用调试器连接到管道组件？在探针方法上设置一个断点，看看发生了什么。应该能够解决问题。

【解决方案2】：

你需要在课堂附近实现IProbeMessage 我忘了在文章的代码中添加 IProbeMessage。现在更新了。但它在示例源代码中
Src1 是架构的根节点名称。我在文章中提到消息类型是 TargetNamespace#Root

我建议下载示例代码

希望对你有帮助

【讨论】：