BizTalk Server 通过已部署的XSD架构解析XML消息，接收管道验证后生成IBaseMessage对象并写入MessageType等上下文属性；映射在接收端口出站或发送端口执行，严格按源/目标架构匹配，依赖MessageType值，不改变上下文需配合属性提升。
BizTalk Server 处理和映射 XML 消息的核心机制围绕“消息生命周期”展开：从接收、解析、转换到路由与发送，XML 消息始终以结构化、可识别的架构（Schema）为基础。映射不是孤立操作，而是嵌入在端口配置与消息流中的关键转换环节。
XML 消息如何被 BizTalk 识别和加载
BizTalk 不直接处理原始 XML 字节流，而是依赖已部署的XML 架构（XSD）来验证和解析消息。当消息进入接收管道时：
- 如果启用了验证（如在 XMLReceive 管道中），BizTalk 会用对应架构校验 XML 结构、命名空间、元素类型等；不通过则抛出错误或转入失败端口。
- 成功解析后，消息被提升为BizTalk 消息对象（IBaseMessage），其主体部分作为 XML 流挂载，上下文（Context）中自动写入架构类型（http://schemas.microsoft.com/BizTalk/2003/system-properties#MessageType）等关键属性。
- 消息体本身仍为 XML，但 BizTalk 内部通过 XmlReader 流式访问，避免整包加载——这对大消息性能至关重要。
映射（Map）在何处生效、如何匹配
映射是 XSLT 转换逻辑的可视化封装（.btm 文件），它只在明确配置的位置触发，且严格按源/目标架构匹配：
- 接收端口出站映射：适用于请求-响应模式。例如，客户发来采购订单（PO.xsd），你希望直接返回格式化后的确认（ACK.xsd），无需业务流程，就在接收端口“出站映射”中指定 PO → ACK 的映射。
- 发送端口映射：当消息被发送端口订阅到后，在进入发送管道前执行。常用于将内部统一格式（如 CanonicalOrder.xsd）转为合作伙伴特定格式（PartnerInvoice.xsd）。
- 匹配依据是消息上下文中的 MessageType 属性值，必须与映射定义的源架构完全一致（含命名空间和版本）。多个映射可共存于同一端口，但每个映射的源架构不能重复。
映射执行的关键细节
映射看似图形化拖拽，但底层行为影响实际效果：
- 映射运行在内存中，输入和输出都需完整加载为 XML DOM（除非启用流式映射优化，但标准 Map 不支持）。因此，10 MB 的 XML 输入经复杂映射后可能占用百 MB 内存。
- 映射可调用自定义脚本函数（C# 或 XSLT 扩展），但需确保函数无副作用、线程安全，并部署到 GAC 或 BizTalk 应用程序目录。
- 映射不改变消息上下文属性；若需设置路由字段（如 PartnerID），须配合 属性提升（Property Promotion）——在架构中将元素标记为 promoted field，或在管道中用自定义组件写入上下文。
常见问题与规避建议
实际部署中，XML 映射失败往往源于隐性不匹配：
- 命名空间差异：源 XML 带默认命名空间（xmlns="..."），而架构未设 targetNamespace，会导致 MessageType 不匹配。解决方法：架构中声明相同 targetNamespace，或在接收管道中用“命名空间修正”组件预处理。
- 空元素/缺失节点：XSLT 默认跳过空值，可能导致目标文档结构断裂。建议在映射中显式设置“Suppress Empty Nodes”为 False，并用“Value Mapping”+“String Concatenate”兜底。
- 字符编码问题：接收管道若未正确识别 UTF-8 BOM 或声明，XML 解析可能乱码。推荐在 XMLReceive 管道中启用“Detect Encoding From Byte Order Marks”并固定 Encoding 属性为 UTF-8。
