在Power Automate中处理第三方系统推送的XML报文，核心思路是先利用平台自带的操作把原始文本转成结构化对象，再通过XPath定位具体节点。许多接口回调、旧版ERP导出依然采用XML格式，掌握解析方法能省去大量人工整理工作。
一、Power Automate解析XML的基础原理
Power Automate并没有把XML当作普通字符串来切割，而是在底层借助.NET的XML文档模型。当你使用“分析XML”这个内置动作时，它实际上会调用XmlDocument的LoadXml方法，将文本加载为可寻址的树状结构。每个元素、属性都成为树中的一个节点，之后就能用XPath语法去精确选取。
为什么不能直接用字符串函数？假设报文里出现<price>19.9</price>，用indexOf加substring或许能抠出数值，可一旦报文多了命名空间，或者元素顺序变动，文本截取就会失效。而XPath以节点路径为准，与排版无关。理解这一点，才能避免在复杂流程里写出脆弱的表达式。
1.1 分析XML动作的配置
在流程设计器中搜索“分析XML”，把动态内容里的原始报文填入“内容”框。该动作输出的是一个名为Body的对象，后续所有XPath都基于它。如果原始数据来自HTTP请求的响应，记得先把响应体用string()函数确保是文本，否则可能传入二进制导致报错。
下面是一段在“分析XML”之前做预处理的表达式示例，用于去掉报文头部的声明，防止某些连接器识别异常：
<?xml version="1.0" encoding="UTF-8"?> <order> <id>10086</id> <amount>299.00</amount> </order>
二、使用XPath提取节点数据
解析完成后，最常用的就是“从XML获取节点”或直接在动态表达式里写xpath()。比如要拿订单号，表达式可以写成xpath(outputs('分析XML'), '//id/text()')。注意Power Automate的xpath函数返回的是数组，即使只有一个匹配项也要取第一个元素。
当XML带有命名空间，例如<ns:order xmlns:ns="http://ipipp.com/schema">，直接写//order会落空。必须在xpath中声明前缀映射，或使用local-name()函数忽略前缀。实际项目中推荐用local-name，减少维护成本。
2.1 代码示例：提取多个字段
以下表达式展示了如何同时取出id与amount，并转为数字写入变量：
// 假设分析XML的输出名为 XmlOutput
var id = xpath(outputs('XmlOutput'), '//*[local-name()="id"]/text()')[0];
var amount = parseFloat(xpath(outputs('XmlOutput'), '//*[local-name()="amount"]/text()')[0]);
// id 为 '10086'，amount 为 299
在界面化操作中，你也可以用“初始化变量”配合动态内容里的XPath结果，但复杂逻辑建议直接用表达式，可读性更高。如果节点不存在，xpath返回空数组，用?.[0]或coalesce处理能避免流程中断。
2.2 循环处理重复子节点
订单报文常包含明细列表，此时用XPath选中集合后接“应用到每一个”。例如选取所有<item>节点：
// 选中所有 item 节点
var items = xpath(outputs('XmlOutput'), '//*[local-name()="item"]');
// 在 Power Automate 的循环中，items 会作为数组传入
在循环内部再针对单个节点取子元素，如名称、数量。这种分层读取方式比一次性拼大表达式更利于排查错误，也方便在每一步加条件判断过滤无效数据。
三、常见误区与避坑建议
第一个误区是忽视编码。XML声明里的encoding如果和实际不符，分析XML动作会抛出乱码异常。遇到中文内容，确认源系统输出的是UTF-8且无BOM头。第二个误区是在表达式里手写完整命名空间URI，一旦对方升级schema，流程就会静默失败。
另一个容易踩的坑是把XML当作JSON来用点号取值。XML必须经过分析动作，不能对原始字符串用?['id']。若流程中同时有JSON与XML，建议在变量名上区分清楚，比如xmlBody与jsonBody，降低协作时的理解成本。
3.1 与字符串处理的对比
下表列出标准解析与文本截取在不同场景下的表现：
| 场景 | 分析XML+XPath | 字符串函数 |
|---|---|---|
| 元素顺序变化 | 正常取值 | 可能取错 |
| 带命名空间 | 需local-name或映射 | 极易失败 |
| 特殊字符转义 | 自动处理 | 需手动替换 |
从维护角度看，标准解析前期稍费事，后期更稳。字符串方案仅适合一次性临时流程。
四、将解析结果写入业务系统
拿到干净的数据后，常见动作是写入Dataverse表或发送审批邮件。以Dataverse为例，在“添加新行”里把amount映射为小数列，id映射为文本主键。如果XML里日期是字符串，用formatDateTime转换，避免时区偏移。
对于大批量明细，建议在循环内使用并行分支或批量创建自定义连接器，减少API调用次数。同时开启运行历史里的“数据只包含关键字段”，既保护敏感信息也加快日志加载。整套下来，从接收到XML到业务落库可以做到完全无人干预。
4.1 完整流程片段示例
下面给出一个精简的伪流程表达式组合，展示端到端思路：
// 1. HTTP 触发拿到 rawXml
// 2. 分析XML: outputs('ParseXml')
// 3. 取订单号
var orderId = xpath(outputs('ParseXml'), '//*[local-name()="id"]/text()')[0];
// 4. 取明细并循环创建
var details = xpath(outputs('ParseXml'), '//*[local-name()="item"]');
// 对每个 detail 再解析子节点后调用 Dataverse 新增行
只要源报文结构稳定，上述模式可直接套用。若结构常变，可考虑在前面加一个Schema校验动作，提前拦截异常格式，让自动化流程更健壮。
Power_AutomateXML解析自动化流程修改时间：2026-08-09 03:00:32