BizTalk Server以XML消息为核心，通过“接收→解析→路由→转换→发送”流程处理，依赖命名空间与根元素组合唯一标识消息类型，由接收管道解析并提取上下文属性，经MessageBox基于订阅匹配路由，转换与编排严格依赖已部署Schema和Map。
BizTalk Server 把 XML 消息当作核心数据单元来处理，整个流程围绕“接收 → 解析 → 路由 → 转换 → 发送”展开，不是靠硬编码，而是靠配置驱动和消息元数据（比如命名空间 + 根元素）来识别和分发。
消息类型由命名空间和根元素共同决定
BizTalk 不看文件名或内容语义，只认 目标命名空间#根元素名称 这个组合。例如：http://schemas.example.com/invoice#Invoice 和http://schemas.example.com/invoice#Order 是两种不同消息类型；
即使结构一样，换一个命名空间，也算新类型。这直接影响后续的订阅匹配和映射选择。
接收管道负责解析和标准化
XML 消息进来时，先走接收管道（如 XMLReceive）：
- 解析原始字节流，转成 BizTalk 内部 XML 格式
- 验证是否符合已部署的 Schema（可选）
- 提取消息上下文属性（比如
MessageType、ReceivedFileName） - 若含默认命名空间或无命名空间，需在 Schema 中显式声明
elementFormDefault="qualified"或用自定义组件预处理，否则可能解析失败或类型不匹配
MessageBox 是消息路由中枢
所有合法消息都会持久化进 SQL Server 的 MessageBox 数据库。业务流程（Orchestration）或发送端口通过“订阅”表达诉求，比如：
- 订阅
MessageType == "http://schemas.example.com/invoice#Invoice" - 订阅
BTS.ReceivePortName == "Invoicing_ReceivePort"
引擎自动匹配、投递，无需手动查找或轮询。
转换和编排依赖 Schema 与 Map
- Schema 定义结构（XSD），必须提前部署，是类型识别和验证的基础
- Map（XSLT）完成字段级映射，比如把
Invoice/TotalAmount拆成Receipt/GrandTotal和Receipt/CurrencyCode - 编排中可调用多个 Map，也可用 Expression Shape 直接构造 XML 片段，但推荐用 Map 保证可维护性
基本上就这些。关键不在写代码，而在准确定义 Schema、配对好订阅条件、选对管道组件——错一处，消息就卡住或路由偏移。
