Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
适用于:Azure 逻辑应用(标准)
在企业集成方案中(例如企业到企业(B2B)或 BizTalk 迁移中,可能需要分析 XML 文档。 Azure Logic Apps 中的标准逻辑应用工作流可以使用名为 Parse XML with schema 的操作来解析 XML,该操作需要一个 XSD 架构。
例如,假设你定期以 XML 格式接收客户订单或发票。 假设你必须直接在 Azure Logic Apps 的工作流设计器中访问单个 XML 元素。
限制
消耗逻辑应用资源和工作流不支持此操作。
先决条件
Azure 帐户和订阅。 获取 Azure 帐户。
标准逻辑应用工作流以触发器开始,这样您就可以将解析 XML(具有架构)操作添加到您的工作流中。
用于定义和存储项目(如贸易合作伙伴、协议、证书和其他项目)的 集成帐户资源 ,用于企业集成和 B2B 工作流。 此资源必须满足以下要求:
与逻辑应用资源所在的同一个 Azure 订阅相关联。
与计划使用“使用架构解析 XML”操作的逻辑应用资源位于同一 Azure 区域或位置。
如果使用标准型逻辑应用资源和工作流,则可以根据以下情况将集成帐户链接到逻辑应用资源并且/或者直接将 XSD 架构上传到逻辑应用资源:
如果你已经有一个包含所需工件或想要使用的工件的集成帐户,可以将该集成帐户链接到多个标准逻辑应用资源,在这些资源中使用这些工件。 无需将 XSD 架构上传到每个单独的逻辑应用。 有关详细信息,请参阅 将逻辑应用资源链接到集成帐户。
如果您没有集成帐户,或者只计划在同一个逻辑应用资源中的多个工作流中使用现有工件,则可以使用 Azure 门户或 Visual Studio Code 直接将架构添加到逻辑应用资源中。
如果你没有集成帐户,或者你不需要集成帐户,可以使用上传选项。 否则,请使用链接选项。 无论哪种方式,你都可以在同一逻辑应用资源中跨所有子工作流使用这些工件。
要与“使用架构分析 XML”操作一起使用的 XSD 架构。 请确保此架构包含根元素,如以下示例所示:
<xs:element name="Root"> <....> </xs:element>
添加“解析具有架构的 XML”操作
在 Azure 门户中,打开设计器中的标准逻辑应用和工作流。
如果你有一个没有触发器的空白工作流,请按照以下常规步骤添加所需的任何触发器。 否则,继续执行下一步。
此示例使用请求触发器。
在要添加使用架构分析 XML操作的工作流步骤中,按照以下常规步骤来添加名为使用架构分析 XML的操作。
在 “内容” 框中,指定要解析的 XML 内容,使用在 HTTP 请求中接收到的任何 XML 数据。
若要从工作流中的先前操作中选择输出,请在“使用架构解析 XML”操作中,选择“内容”框内,并选择动态内容列表选项(即带有闪电图标的)。
从动态内容列表中,选择要分析的内容的令牌。
此示例从触发器中选择“Body”标记。
从源列表中选择上传 XSD 架构的位置,即LogicApp资源或IntegrationAccount。
从“名称”列表中选择你的 XSD 架构。
完成后,保存工作流。
现在,您已完成“解析 XML 并使用模式”操作的设置。 在实际应用中,你可能需要将已分析的数据存储在业务线 (LOB) 应用(如 Salesforce)中。 若要将已分析的输出发送到 Salesforce,请添加 Salesforce 操作。
若要测试分析操作,请触发并运行工作流。 例如,对于“请求”触发器(Request trigger),将请求发送至该触发器的终结点 URL。
触发工作流后,“使用架构解析 XML”操作会运行,并且当 XML 内容可供解析时也会运行。
高级参数
下表描述了此操作中可用的高级参数:
| 参数 | 价值 | 说明 |
|---|---|---|
| DTD 处理 |
-
忽略 解析 - 禁止 |
指定如何处理 XML 文档类型定义 (DTD)。 |
| 规范化 XML | “否”或“是” | 是否规范化 XML 内容。 |
| 忽略空格? | “否”或“是” | 是要分析还是忽略无意义的空白字符,例如 XML 文档中的空格、制表符和空白行。 |
| 忽略 XML 处理指令? | “否”或“是” | 是要遵循还是忽略 XML 处理指令。 |
| 忽略 XML 属性 | “否”或“是” | 是要写入还是忽略 XML 属性。 |
| 使用完全限定的名称? | “否”或“是” | 是要使用更简单的本地名称还是完全限定的 XML 名称。 |
| 根节点限定名称 | <root-node-qualified-name> | 如果架构包含多个未引用的元素定义,则使用根节点的限定名称。 |
故障排查
本部分介绍可能会遇到的问题,以及解决这些问题的可能解决方案或解决方法。
不保留 XML 元素顺序
如果 XML 包含以混合顺序出现的重复元素,则解析具有架构的 XML操作可能不会保留原始顺序,而是按名称的字母顺序对这些元素进行分组。
此行为是预期的,因为使用架构解析 XML 操作将 XML 转换为 JSON。 此格式没有办法表示具有不同类型的项的单个有序列表。 相反,操作会根据名称按字母顺序对元素进行分组。
例如,假设具有以下名称的项目按以下特定顺序排列:A、、BB、 A:
之前
<Items>
<A>1</A>
<B>2</B>
<A>3</A>
<B>4</B>
</Items>
在作分析 XML 后,生成的 JSON 按名称对这些项进行分组和重新排序,如下所示:A、、AB和B:
之后
{
"A": ["1", "3"],
"B": ["2", "4"]
}
具有架构的解析 XML 操作没有用于保留混合重复元素顺序的任何设置。 此限制导致将 XML 转换为 JSON。
以下列表介绍了修复或解决此问题的选项:
如果控制架构,请设计架构,以便只有一个重复列表,而无需多个重复元素类型。
例如,与其单独重复
A和B,不如使用一个重复的包装元素,例如Item。 然后,每个项目指示是否表示A或B。 然后,系统可以将所有项保留在单个有序列表中,并保留原始顺序。 此选项最适合长期可预测的行为。如果原始顺序是必需的或关键,请不要分析 XML。
- 避免将 XML 分解为 JSON。
- 处理整个 XML 文档。
- 将 XML 文档保持不变地传递,或使用基于 XML 的工具(如 XSLT)转换其内容。
请记住此限制。
如果无法更改架构或工作流,请记住以下事项:
- 混合重复元素按元素名称分组,丢失原始顺序。
- 请在设计下游逻辑时考虑此行为。