DataWeave · 9 min read

DataWeave functions you need for the MuleSoft certification exam

By the MulePrep team · Updated June 2026

The DataWeave functions you most need for the MuleSoft certification exam are map, filter, mapObject, pluck, reduce, groupBy, and orderBy, plus the ++ operator. This is an exam-framed cheat sheet: each function gets a tiny input-to-output example and the specific trap the exam tends to set. The skill being tested is not writing DataWeave from scratch - it is reading a snippet and predicting exactly what it returns.

Why DataWeave matters on the exam

DataWeave 2.0 is the transformation language built into Mule 4. Every time a flow reshapes data - rename a field, filter a list, turn XML into JSON, aggregate orders by customer - it runs DataWeave, usually inside a Transform Message component. Because transformation is so central to integration work, the MuleSoft Certified Developer - Level 1 exam (the Mule Dev 201 track) leans on it heavily.

The questions rarely ask you to author a transformation. Instead they show you a short script and four candidate outputs, and you choose the one it actually produces. That means the core skill is tracing input to output by hand. If you can read a lambda, know whether a function returns an array or an object, and remember the argument order, most DataWeave questions become straightforward.

This guide is a DataWeave 2.0 cheat sheet built around that skill. For each function you get the shortest example that proves the behaviour, plus the mistake the exam is hoping you make. All snippets assume a header like %dw 2.0 with output application/json; only the transformation line is shown to keep things tight.

map - transform each item of an array into a new array

map walks an array and applies a lambda to every element, returning a new array of the same length. The lambda receives two values: (item, index). You use item most of the time; index is there when you need the position.

[1, 2, 3] map ((item) -> item + 1)
// => [2, 3, 4]

Each element is incremented and a new three-element array comes back. The input is never mutated - DataWeave is functional, so map always produces a fresh value.

The trap

The exam likes to omit the parentheses around the lambda parameters or reorder them. Remember the order is (item, index), item first. A snippet that reads map ((value, index) -> ...) still works - the first parameter is just renamed - but if a question relies on index, make sure you are reading the second parameter, not the first.

filter - keep only the array items that match a condition

filter also iterates an array, but instead of transforming each item it keeps the ones for which the lambda returns true and drops the rest. The result is a new array that is the same length or shorter.

[1, 2, 3, 4] filter ((item) -> item > 2)
// => [3, 4]

Only 3 and 4 satisfy item > 2, so they survive. filter never changes the values it keeps - that is map's job. Pairing them is common: filter first to narrow the list, then map to reshape what remains.

The trap

Watch for predicates that are easy to misread, such as item mod 2 == 0 (keep even numbers) versus item mod 2 == 1 (keep odd). The exam counts on a quick glance returning the wrong half. Evaluate the condition for each element explicitly rather than trusting your first instinct.

mapObject vs map - mapObject transforms each key:value of an object

This is the distinction the exam tests most often. map is for arrays and returns an array. mapObject is for objects and returns an object. They are not interchangeable, and confusing them is the single most common DataWeave mistake.

mapObject iterates the entries of an object. Its lambda receives (value, key, index) - note that value comes first, the opposite of what some people assume. Whatever object you return for each entry is merged into the final result.

{ a: 1, b: 2 } mapObject ((value, key) -> { (key): value + 1 })
// => { a: 2, b: 3 }

Here each value is incremented while the keys stay the same. The (key) syntax with parentheses is required: it tells DataWeave to evaluate key as a dynamic key name rather than using the literal string "key".

The trap

A question shows map applied to an object, or mapObject applied to an array, and offers an output that looks plausible. The correct answer is often that the types do not line up. Anchor on this: object in, object out means mapObject; array in, array out means map.

pluck - turn an object into an array by iterating its key/value/index

pluck is the bridge from object to array. Where mapObject takes an object and returns an object, pluck takes an object and returns an array. Its lambda receives (value, key, index) - the same arguments as mapObject - and collects whatever you return into a list.

{ a: 1, b: 2 } pluck ((value, key, index) -> key)
// => ["a", "b"]

Returning key gives you the object's keys as an array. Return value instead and you get [1, 2]. This matters because most array functions - map, filter, orderBy - cannot operate on an object directly, so pluck is how you get an object's contents into a form you can iterate.

The trap

Confusing the argument order. For both pluck and mapObject the lambda is (value, key, index), with value first - but for map it is (item, index). The exam mixes these to see whether you return the key when you meant the value, or vice versa.

reduce - collapse an array to a single value with an accumulator

reduce folds an entire array down to one result by carrying an accumulator across each step. Its lambda receives (item, accumulator) - item first, accumulator second. Getting that order wrong is the heart of most reduce questions.

[1, 2, 3] reduce ((item, acc) -> acc + item)
// => 6

With no seed value, the accumulator starts as the first element (1), and the lambda runs from the second element onward: 1 + 2 = 3, then 3 + 3 = 6. You can provide an explicit seed by writing acc = 0 in the lambda signature, which is required when the array might be empty or when the accumulator type differs from the element type.

The trap

Two things. First, the seed: without one, the first element is consumed as the starting accumulator, not passed to the lambda as item. Second, the argument order is (item, acc) - the opposite of the convention in some other languages, where the accumulator comes first. Read the signature carefully before computing.

groupBy and orderBy - group and sort collections

These two reshape collections without changing the underlying values.

groupBy

groupBy takes an array and returns an object whose keys are the grouping criterion and whose values are arrays of the matching elements.

[1, 2, 3, 4] groupBy ((item) -> item mod 2)
// => { "1": [1, 3], "0": [2, 4] }

The critical detail: the keys are strings, even though item mod 2 produces numbers. DataWeave object keys are always strings, so a question that offers { 1: [...] } with a numeric key is wrong on a technicality. Note the "1" group can appear before "0" because grouping follows the order in which each key is first encountered.

orderBy

orderBy sorts an array by the value the lambda returns, ascending by default.

[3, 1, 2] orderBy ((item) -> item)
// => [1, 2, 3]

To sort descending, you reverse the result, since orderBy itself only sorts ascending. When sorting objects, you return the field to sort on, for example orderBy ((item) -> item.age).

The ++ operator - concatenate arrays / combine objects

++ joins two values of the same kind. For arrays it concatenates them in order:

[1, 2] ++ [3]
// => [1, 2, 3]

For objects it merges the key-value pairs of both into one object:

{ a: 1 } ++ { b: 2 }
// => { a: 1, b: 2 }

The trap

When two objects share a key, ++ does not overwrite - it keeps both pairs:

{ a: 1 } ++ { a: 2 }
// => { a: 1, a: 2 }

DataWeave objects can legally hold repeated keys, and ++ simply concatenates the pairs rather than deduplicating them. A later single-value selector such as .a returns the first match, so the second pair is easy to forget is even there. The exam exploits this by offering { a: 2 } (overwrite) as the tempting wrong answer. Both keys are retained.