17370845950

Envelope必须设为true，否则XML Disassembler不识别信封；Body XPath须指向包裹多条消息的父节点（如/OrderBatch/body）；多类型消息靠MessageType匹配，无需Schema内显式定义；SQL适配器Debatching依赖FOR XML的根容器结构。

Envelope必须设为true，否则XML Disassembler根本不识别

这是最常踩的坑：光有带结构的XML，但没在Schema的节点上把Envelope属性设为Yes，整个消息会被当作普通XML原样传入MessageBox，不会拆包。BizTalk不靠文件名或内容猜信封，只认这个硬开关。

• 在VS BizTalk Schema Editor中右键根节点 → “Properties” → 找到Envelope → 设为True
• 如果用XSD手动编辑，确认里有bts:Envelope="yes"（命名空间需引用xmlns:bts="http://schemas.microsoft.com/BizTalk/2003"）
• 不设这个，哪怕XPath写得再准，Debatching也完全不触发

Body XPath决定拆哪一层，且必须指向“容器记录”，不是根节点

很多人误以为Body XPath该填/Envelope或/root，结果一个消息都拆不出来。它真正的作用是告诉XML Disassembler：“从这个节点开始，下面每个同级子节点都算一条独立消息”。所以它必须指向一个**包裹多条消息的父记录**（比如或），而不是整个信封根。

• 例如信封结构是
  ...
  ......，则Body XPath应设为/OrderBatch/body
• 该路径必须在设计时静态存在；运行时不能动态计算
• 路径错误的典型表现：接收端只收到1条消息，内容是完整信封XML —— 说明Disassembler根本没进拆包逻辑

多类型消息共存时，不用为每种类型建单独记录，Schema匹配靠MessageType

你不需要在Envelope Schema里显式拖出RootA和RootB两个子记录来“容纳”不同类型消息。XML Disassembler只关心拆出来的每个片段的RootName + Namespace是否能匹配已部署的某个Schema的MessageType（即TargetNamespace#RootNodeName）。只要对应Schema已部署，类型自动识别。

• 信封内可以混着和，只要这两个Namespace+Root名在GAC或BizTalkMgmtDb里有对应Schema即可
• 用代替具体子记录完全可行，甚至更灵活；关键不是结构，而是拆出来那段XML能

  

  否被归类
• 常见错误：只部署了Envelope Schema，忘了部署PurchaseOrder.xsd和Invoice.xsd → 拆出的消息变成UnknownMessage，进Failed Suspended队列

SQL Receive Adapter自带Debatching，但依赖FOR XML输出格式

当用SQL Receive Adapter拉取多行数据时，它默认会把结果集拼成单个XML发给Pipeline。这时能否Debatch，不取决于你有没有配Envelope Schema，而取决于SQL语句返回的XML是否满足信封结构要求 —— 即必须有明确的“外层包装”和“内层重复项”。

• 正确写法：SELECT * FROM Orders FOR XML AUTO, ELEMENTS, ROOT('Orders') → 生成......，此时配合Body XPath = '/Orders'就能拆
• 错误写法：SELECT * FROM Orders FOR XML RAW('Order'), ELEMENTS → 生成......，没有根容器，XML Disassembler无法判定“哪里开始拆”，必须手动包一层
• Adapter本身不做结构校验，只负责把XML吐进Pipeline；拆不拆、怎么拆，全由你配的Envelope Schema和Pipeline里的XML Disassembler决定

信封不是语法糖，是BizTalk消息生命周期的分水岭：它决定了消息何时从“一个整体”变成“多个可并行处理的实例”。漏掉Envelope="yes"，或写错Body XPath，等于没装引信——后面所有路由、升职、Orchestration都无从谈起。