Mule 4中的DataWeave 2.0 XML转换究竟怎么用

Mule 4彻底将DataWeave升级到了2.0版本，这一代脚本语言做了很多破坏性变更，其中对XML的支持逻辑和1.0时代完全不同。很多人一开始只把它当作字段提取工具来用，感觉无非是把payload里的值抽出来重新拼装，但真到了要把JSON转成XML、把XML转成JSON、或者在XML结构中处理属性与命名空间时，才发现DataWeave 2.0的转换规则比自己预想得复杂得多。

从本质上讲，DataWeave 2.0对XML的处理依赖一个内置的XML Reader和一个XML Writer，二者各自拥有一套参数控制解析与输出的行为。如果只停留在

例>这种简单映射的层面，可以完全不关心这些底层机制。可一旦遇到类似这样的情况——上游REST接口返回一段JSON，下游传统系统只接受特定结构的XML报文——就必须同时搞清楚JSON的字段结构、XML包含的嵌套层级、以及节点上需要携带的属性信息。下面通过一个具体的转换案例来拆解整个处理过程。

DataWeave 2.0中的XML基础数据结构

DataWeave 2.0内部使用一种名为Value的数据类型体系，XML在这种体系里可以被拆解为对象、数组、字符串、数字、布尔值和null的排列组合。这与JSON有着天然的对偶关系，看起来似乎可以直接把JSON对象输出成XML。实际操作时会发现一个关键区别：XML里节点既可能携带属性（attribute），也可能包含子元素（element），而JSON只有字段名和值的概念。因此DataWeave 2.0专门设计了一套符号约定来解决这种不对称性。

在XML Writer处理输出时，属性节点的key以@符号开头，文本值则直接以字符串形式表达。例如需要生成一个<order>节点，其id属性为1001、内部文本为ABC，对应的DataWeave表达式可以写成：

<![CDATA[
%dw 2.0
output application/xml
---
{
    order: {
        @id: 1001,
        text: "ABC"
    }
}
]]>

这里的text是DataWeave中的保留关键字，专门用来表示节点内直接内嵌的文本内容。如果不写text而直接写order: { @id: 1001 }，生成的XML中order节点会是一个只有属性没有文本的空节点。很多人第一次转换时到处找不到文本内容为什么丢了，大部分就是这个细节没有意识到。

同时，如果source JSON中本来就有一个字段名叫text或@something，在转换过程中必须用key函数做一次key改写，否则DataWeave会把字段名误判为特殊语法。这个容易踩，下面会专门讲。

JSON到XML转换：一次完整的订单报文构建

假设现有这样一个上游JSON响应，代表一张订单及其明细行：

<![CDATA[
{
  "orderNumber": "SO-2025-001",
  "customer": {
    "name": "张三",
    "level": "VIP"
  },
  "lines": [
    { "sku": "A100", "qty": 2, "price": 199.00 },
    { "sku": "B200", "qty": 1, "price": 399.00 }
  ]
}
]]>

下游要求接收的XML结构如下，orderLines下需要有一个line元素数组，每个line元素都携带lineNo属性：

<![CDATA[
<order orderNo="SO-2025-001">
    <customer>
        <name>张三</name>
        <level>VIP</level>
    </customer>
    <orderLines>
        <line lineNo="1">
            <sku>A100</sku>
            <qty>2</qty>
            <amount>398.00</amount>
        </line>
    </orderLines>
</order>
]]>

直接写一个DataWeave 2.0脚本可以一次性完成这些操作：属性节点的提取、数组到重复元素的转换、以及新计算字段的生成。代码如下：

<![CDATA[
%dw 2.0
output application/xml
---
{
    order: {
        @orderNo: payload.orderNumber,
        customer: {
            name: payload.customer.name,
            level: payload.customer.level
        },
        orderLines: {
            line: payload.lines map ((item, index) -> {
                @lineNo: index + 1,
                sku: item.sku,
                qty: item.qty,
                amount: item.qty * item.price
            })
        }
    }
}
]]>

这段脚本里值得注意的点有几个。其一是@orderNo与@lineNo直接构造属性，不需要额外声明，语法与函数调用不同，它更像是一个带标记的对象key。其二是payload.lines map这个操作会把数组映射成一个对象数组，而DataWeave的XML Writer检测到输出对象数组中每个元素的key都是line时，会针对每个key生成独立的XML元素。最终展示出的结果就是多个<line>兄弟节点并列在<orderLines>内部。

还有一点微妙的地方：如果payload.lines本身只有一个元素，它不会自动包成数组。Mule 4读取JSON数组时正常会保留数组结构，但如果这个JSON来自某些旧系统的REST接口且字段偶尔可能是单对象，稳妥的做法是先用dw::core::Arrays::toArray或if (payload.lines is Array)做一次防御。否则脚本运行时会在map操作上直接抛Expected Array but got Object的异常。

如果不想在每条线路里写防御逻辑，也可以将lines的解析封装成独立函数，用递归来处理。DataWeave 2.0支持fun关键字以及局部变量定义，这让复杂转换的代码组织更加接近传统编程范式：

<![CDATA[
%dw 2.0
output application/xml
fun toLine(item, index) = {
    @lineNo: index + 1,
    sku: item.sku,
    qty: item.qty,
    amount: item.qty * item.price
}
---
{
    order: {
        @orderNo: payload.orderNumber,
        customer: {
            name: payload.customer.name,
            level: payload.customer.level
        },
        orderLines: {
            line: (payload.lines default []) map toLine($, $$)
        }
    }
}
]]>
</script>

这里default []语法会在lines字段为null或缺失时提供一个空数组，map操作自然执行零次，返回一个空数组交给XML Writer。Writer遇到空数组时不会输出任何<line>节点，但<orderLines>父节点仍然会保留，这是默认行为。若想连父节点也一并省略，需要再加一个条件判断来动态决定是否输出该字段，而不是让脚本输出null值。

XML Reader参数与复杂嵌套结构的处理

与输出端相对，输入端的XML Reader负责把收到的XML负载解析成DataWeave内部的对象。XML加载到Mule里后，默认的解析方式会保留命名空间、注释、以及元素的顺序吗？答案是否定的。默认情况下，DataWeave 2.0的XML Reader会把注释剥离，忽略元素顺序，并将命名空间丢进一个单独的^namespaces元数据字段中。

当XML的标签带有前缀时，直接按原始标签名去取字段会有问题。例如输入<ns0:order xmlns:ns0="http://test">，在DataWeave视角里这个对象的key是ns0.order，而不是order。同时如果脚本最终重新输出XML，命名空间前缀名还可能被重新定义。可以使用如下方式拿到嵌套很深的值：

<![CDATA[
%dw 2.0
output application/xml
---
{
    result: {
        number: payload.ns0.order.ns0.docNumber,
        company: payload.ns0.order.ns0.company.text
    }
}
]]>

在处理嵌套结构时，递归函数也是一种高效手段。比如要读取一个部门层级不明的XML结构，并把每个部门的@deptId收集成一个数组，可以定义一个递归函数遍历所有子节点。DataWeave 2.0的递归不要求尾递归优化，常规业务XML层级不会深到导致栈溢出，这种写法在实际项目中非常实用。

同时需要记住，output application/xml不负责美化输出格式，它默认的output模式是compact。如果需要缩进格式好看一点，可以使用output application/xml indent=true或者通过Writer参数配置。在Mule 4的Transform Message组件里可以直接改Output标签，把这个参数下拉调整。若要完全自定义XML声明头，例如加上standalone="yes"，可以借助write(payload, "application/xml", { "xml:standalone": "yes" })这类动态writer参数来覆盖默认模板。

常见转换误区与最佳实践

很多人写DataWeave XML转换时，最容易忽略的是CDATA片段。默认的XML Writer并不会自动为文本节点生成CDATA，而是做正常的转义输出。如果下游系统要求特定字段必须保持CDATA包裹，需要在payload里传递一个专门的对象结构，例如{ "$CDATA": "内容" }。这个语法和普通文本节点不同，它会在输出时生成<![CDATA[内容]]>。

空元素也是一个高频坑。DataWeave里如果把一个字段值设为空字符串""，输出XML会变成<sku></sku>，看起来是自闭合或开闭成对。若想完全省略该元素，需要在外层做条件判断。更麻烦的情况是JSON输入里存在null值，默认Writer会为该节点生成一个空的自闭合标签。这在很多对格式严格校验的场景里直接被拒绝。为了避免这种输出，可以在转换脚本中统一处理null：

<![CDATA[
%dw 2.0
output application/xml
fun skipNull(v) = if (v == null) "" else v
---
{
    order: {
        @orderNo: skipNull(payload.orderNumber),
        remark: skipNull(payload.remark)
    }
}
]]>

这么写只能保留空标签但无法隐藏节点，若想彻底隐藏，就得在输出之前过滤去对应的key。DataWeave 2.0的filterObject函数可以帮忙评估对象中的每个value，把null字段从对象中剔除。例如：

<![CDATA[
%dw 2.0
output application/xml
var withoutNulls = payload filterObject (value, key, index) -> value != null
---
{
    order: {
        @orderNo: withoutNulls.orderNumber,
        remark: withoutNulls.remark
    }
}
]]>

需要留意的是，这段脚本里的filterObject只能针对当前层级。对于嵌套对象，需要写一个递归式过滤函数，才能让深层字段中的null也被去除。在实践中更推荐另写一个fun cleanData(data)函数，对任意输入值做递归处理，遇到对象就继续遍历、遇到数组就继续map、遇到null则丢弃，这样一层层清理干净后再去做XML输出。

此外，在Mule 4应用内调试XML转换时，不要只依赖Error Handler里显示的异常堆栈。XML转换失败时很多报错信息只会模糊地提示Unexpected character或Invalid input，这时可以把临时payload直接用Logger组件以application/json格式打印出来观察解析后的对象结构，再对照原始XML逐行检查。更好的做法是给Transform Message组件起独立名称，并在MUnit测试里针对不同样例payload进行输出断言，这样也能防止后续改动代码时不小心破坏原有转换规则。

DataWeave 2.0的XML转换能力并不仅限于简单字段映射，借助属性标记、递归函数、Writer参数和正确的大数据输入防御策略，足以应对企业集成中大多数与XML对接的复杂场景。碰到特殊格式要求时，先认真阅读目标系统的XML Schema，再回到DataWeave脚本里做针对性适配，往往比反复猜测输出结果更有效率。

Mule 4DataWeave_2.0XML转换修改时间：2026-08-12 05:56:39