DEV Community: ThaSha

RFC 7807 Error Responses in DataWeave: One Transform for All 14 Endpoints

ThaSha — Sun, 12 Apr 2026 05:42:27 +0000

Our API had 14 endpoints and 14 different error response formats. The mobile team spent 3 days writing separate error parsers for each one. I standardized everything to RFC 7807 with one DataWeave transform.

TL;DR

RFC 7807 defines a standard error format: type, title, status, detail, timestamp
One DataWeave error mapping lookup replaces 14 inconsistent formats
The default clause on the lookup is critical — unmapped errors return null without it
application/problem+json MIME type supported since Mule 4.4

The Problem: 14 Endpoints, 14 Error Formats

// Endpoint A
{"error": "not found"}

// Endpoint B
{"message": "Resource missing", "code": 404}

// Endpoint C
{"errors": [{"field": "email", "issue": "invalid"}]}

The mobile team needed a different error parser for each endpoint. 3 days of defensive parsing just to show error messages.

The Solution: RFC 7807 Error Envelope

%dw 2.0
output application/json
var errorMapping = {
    "HTTP:BAD_REQUEST": { status: 400, title: "Bad Request", "type": "client-error" },
    "HTTP:UNAUTHORIZED": { status: 401, title: "Unauthorized", "type": "authentication" },
    "HTTP:NOT_FOUND": { status: 404, title: "Not Found", "type": "not-found" },
    "HTTP:TIMEOUT": { status: 504, title: "Gateway Timeout", "type": "timeout" }
}
var errorInfo = errorMapping[payload.error.errorType.identifier] default { status: 500, title: "Internal Server Error", "type": "server-error" }
---
{
  "type": "https://api.example.com/errors/$(errorInfo.'type')",
  title: "errorInfo.title,"
  status: errorInfo.status,
  detail: payload.error.description,
  timestamp: now()
}

Every error, every endpoint, same format. The mobile team wrote 1 parser.

100 production-ready DataWeave patterns with tests: mulesoft-cookbook on GitHub

The Error Mapping Lookup

The errorMapping object maps Mule error type identifiers to HTTP semantics:

var errorInfo = errorMapping[payload.error.errorType.identifier]
  default { status: 500, title: "Internal Server Error", "type": "server-error" }

errorType.identifier comes from Mule's error object — values like "HTTP:BAD_REQUEST", "HTTP:NOT_FOUND", "VALIDATION:INVALID_PAYLOAD".

The lookup errorMapping["HTTP:NOT_FOUND"] returns the mapped status and title. If the error type isn't in the mapping, default provides a 500 fallback.

Trap: Missing default Clause

Without default:

var errorInfo = errorMapping[payload.error.errorType.identifier]

An unmapped error type (like "CUSTOM:BUSINESS_RULE") returns null. Your response:

{"type": null, "title": null, "status": null, "detail": "Business rule violated"}

Technically valid JSON. Completely useless to the client. The mobile app shows "null" as the error title.

I hit this in production when a custom connector threw "CUSTOM:RATE_EXCEEDED" — an error type I hadn't mapped. The API returned a null-filled error response. The mobile app crashed trying to display null.title.

Rule: Always use default on error mapping lookups. The default should be a valid 500 response, not null.

The Reserved Word Trap

errorInfo.'type'   // Works — quoted field access
errorInfo.type     // Parse error — "type" is reserved in DataWeave

type is a reserved keyword. When your error mapping uses type as a field name, you must access it with quotes: errorInfo.'type'. Without quotes, DataWeave throws a parse error.

I spent 20 minutes on this. The error message says "unexpected token" — it doesn't mention that type is reserved.

RFC 7807 Fields

Field	Required	Purpose
type	Yes	URI identifying the error category
title	Yes	Human-readable error title
status	Yes	HTTP status code
detail	Yes	Specific error description
instance	No	URI of the failing request
timestamp	No	When the error occurred
correlationId	No	Request trace ID

What I Do Now

Every API project gets the error envelope pattern in the global error handler
default on every mapping lookup — no exceptions
Quoted access for type field
I add correlationId from the Mule correlation ID for trace support
Content-Type: application/problem+json (supported since Mule 4.4)

100 patterns with MUnit tests: github.com/shakarbisetty/mulesoft-cookbook

60-second video walkthroughs: youtube.com/@SanThaParv

DataWeave partition() for Bulk API Responses: Stop Returning Silent 200 OKs

ThaSha — Sun, 05 Apr 2026 21:26:44 +0000

Our bulk import API returned 200 OK on every request. Nobody noticed that 40% of records were failing silently for 3 days.

TL;DR

partition() from dw::core::Arrays splits an array into success/failure groups in one pass
Build summary (total, succeeded, failed, successRate) + per-record results + error extraction
Empty batch trap: successCount / total * 100 divides by zero on empty arrays
The caller needs to know EXACTLY what failed and why — not just "200 OK"

The Problem: Silent Bulk Failures

We had a bulk import API. Clients sent 5,000-10,000 records per batch. The API processed each record individually — some succeeded, some failed (duplicate keys, invalid formats, missing fields).

The old response:

{"status": "OK", "message": "Batch processed"}

That's it. No per-record status. No failure count. No error details. The client had no idea which records failed. They found out 3 days later when reconciliation showed missing data.

The Solution: partition() + Summary Builder

%dw 2.0
import partition from dw::core::Arrays
output application/json
var parts = payload partition (item) -> item.status == "SUCCESS"
var successCount = sizeOf(parts.success)
var total = sizeOf(payload)
---
{
  summary: {
    total: total,
    successful: successCount,
    failed: total - successCount,
    successRate: (successCount / total * 100) as String ++ "%"
  },
  results: payload map {
    id: $.id,
    status: $.status,
    (error: $.error) if $.status == "FAILED"
  }
}

100 production-ready DataWeave patterns with tests: mulesoft-cookbook on GitHub

How partition() Works

partition() takes an array and a predicate. Returns an object with two keys:

success: all items where the predicate returned true
failure: all items where it returned false

import partition from dw::core::Arrays
---
[1, 2, 3, 4, 5] partition (n) -> n > 3
// {success: [4, 5], failure: [1, 2, 3]}

One pass. No need to filter twice. Cleaner than separate filter calls for success and failure.

The Conditional Key Trick

results: payload map {
  id: $.id,
  status: $.status,
  (error: $.error) if $.status == "FAILED"
}

The (error: $.error) if $.status == "FAILED" syntax conditionally includes the error field. Successful records have no error key — it's absent, not null. Clean API response.

Trap: Divide by Zero on Empty Batch

A health check sent an empty array to our bulk endpoint. total = 0. The successRate calculation: 0 / 0 * 100. Runtime error: "Cannot divide by zero."

CloudHub showed a 500 error. The health check saw "API is down." The API was fine — it just crashed on empty input.

The fix:

successRate: if (total > 0) ((successCount / total * 100) as String ++ "%") else "N/A"

One guard. I now add this to every bulk response builder. Empty batches are valid input — your API should handle them gracefully.

What the Caller Gets

Before (useless):

{"status": "OK", "message": "Batch processed"}

After (actionable):

{
  "summary": {
    "total": 5,
    "successful": 3,
    "failed": 2,
    "successRate": "60.0%"
  },
  "results": [
    {"id": "R1", "status": "SUCCESS"},
    {"id": "R2", "status": "FAILED", "error": "Duplicate key"},
    {"id": "R3", "status": "SUCCESS"},
    {"id": "R4", "status": "SUCCESS"},
    {"id": "R5", "status": "FAILED", "error": "Invalid format"}
  ]
}

The caller knows: 60% success rate. R2 failed on duplicate key. R5 failed on format. They can retry just the 2 failures instead of resending all 5.

What I Do Now

Every bulk API I build includes:

partition() for success/failure split
Summary with counts + percentage
Per-record results with conditional error field
Empty-batch guard on all division operations
The errors array as a convenience extraction for clients that only want failures

100 patterns with MUnit tests: github.com/shakarbisetty/mulesoft-cookbook

60-second video walkthroughs: youtube.com/@SanThaParv

Parsing LLM Responses in DataWeave: 3 Layers of Defense Against Markdown Fences

ThaSha — Sun, 05 Apr 2026 20:12:23 +0000

I connected MuleSoft to GPT-4o last quarter for a support ticket classifier. The prompt builder worked (I covered that in a previous post). The LLM call worked. Then the response came back and my parser crashed.

The LLM was supposed to return clean JSON. Instead it returned: "Here is my analysis:\n

json\n{\"ranking\": [\"TK-101\"]}\n

\nLet me know if you need anything else."

Markdown fences. Preamble text. Trailing conversation. My read() call choked on "Here is my analysis" — not valid JSON.

TL;DR

LLMs wrap JSON responses in markdown fences — your parser must extract the JSON first
try() from dw::Runtime catches parse failures gracefully — without it, one malformed response crashes your flow
Always validate required keys after parsing — LLMs hallucinate extra fields and omit required ones
The regex for fence extraction: raw match /(?s)(?:json)?\s*(\{.*?\})\s*/
Test with 5 response variants: clean JSON, fenced JSON, fenced without language tag, no fences, broken JSON

The Problem: LLMs Don't Return Clean JSON

You ask GPT-4o to return JSON. Sometimes it does:

{"ranking": ["TK-101", "TK-098"], "summary": "Timeout is critical."}

But often it adds commentary:

Here is my analysis:

json
{"ranking": ["TK-101"], "summary": "Timeout is critical."}

Let me know if you need anything else.

plaintext

That's not valid JSON. read(raw, "application/json") throws. Your Mule flow crashes. 50,000 LLM responses per day = 50,000 potential crashes.

The Solution: 3-Layer Defense in DataWeave

%dw 2.0
import try from dw::Runtime
output application/json
var raw = payload.rawResponse
var fenceMatch = raw match /(?s)```

(?:json)?\s*(\{.*?\})\s*

```/
var jsonStr = if (fenceMatch[1]?) fenceMatch[1] else raw
var parsed = try(() -> read(jsonStr, "application/json"))
var keys = if (parsed.success) (parsed.result pluck $$) else []
var missing = payload.requiredKeys filter (k) -> !(keys contains k)
---
{
  parsed: if (parsed.success) parsed.result else null,
  valid: parsed.success and isEmpty(missing),
  missingKeys: missing
}

100 production-ready DataWeave patterns with tests: mulesoft-cookbook on GitHub

Layer 1: Regex Fence Extraction

var fenceMatch = raw match /(?s)```

(?:json)?\s*(\{.*?\})\s*

```/
var jsonStr = if (fenceMatch[1]?) fenceMatch[1] else raw

The regex matches content between markdown fences. (?s) enables dotall mode so . matches newlines. (?:json)? handles both

`json` and bare

``. The captured group({.*?})` extracts just the JSON object.

If no fences found (fenceMatch[1]? is false), fall back to parsing the raw string directly. This handles the case where the LLM returns clean JSON without fences.

Layer 2: try() Wraps the Parse


dataweave
var parsed = try(() -> read(jsonStr, "application/json"))

try() from dw::Runtime is the critical piece. Without it, read() on invalid JSON throws an exception and crashes the flow. With try(), you get:

Success: {success: true, result: {...parsed object...}}
Failure: {success: false, error: {...error details...}}

Your flow continues either way. Log the error, route to a dead-letter queue, retry with a different prompt — your choice. But the flow never crashes.

The trap: If you don't check parsed.success before accessing parsed.result, you get null on failure. Downstream code that expects an object gets null instead. Always check the success flag.

Layer 3: Required Key Validation


dataweave
var keys = if (parsed.success) (parsed.result pluck $$) else []
var missing = payload.requiredKeys filter (k) -> !(keys contains k)

LLMs hallucinate. You asked for ranking and summary. The LLM returned ranking, analysis, and confidence — but not summary. The JSON is valid but missing a required field.

pluck $$ extracts all keys from the parsed object. filter checks each required key against the actual keys. missing tells you exactly which keys the LLM omitted.

The 5 Response Variants to Test

I test every LLM parser against these variants:

Variant	Example	What Breaks
Clean JSON	`{"ranking": [...], "summary": "..."}`	Nothing — baseline
Fenced with language	```

json\n{...}\n

| `read()` without fence extraction | | Fenced without language |

\n{...}\n

``| Regex that requiresjsonafter fence | | No fences, with preamble |Here is my analysis: {"ranking": [...]}| Naiveread()on full string | | Broken JSON |{"ranking": ["TK-101"(truncated) | Any parser withouttry()` |

I hit all 5 in production within the first week. The same model, same prompt, same temperature — 5 different formats across 50,000 responses.

Trap: The Regex Doesn't Handle Nested Objects Well

The regex \{.*?\} uses non-greedy matching. It works for flat JSON objects. But if your LLM returns nested objects:


json
{"analyses": [{"ticketId": "TK-101", "action": "increase pool"}], "summary": "..."}

The non-greedy .*? stops at the first } — inside the nested array. You get a partial JSON parse.

For production, I switched to finding the matching closing brace by counting open/close braces, not regex. But the regex works for 90% of LLM responses where the top-level structure is flat.

Performance

The parser handles 50,000 LLM responses per day. Average parse time: 2ms per response. The regex is the slowest part — try() and read() are fast because they're native DataWeave functions.

Zero flow crashes since deploying the 3-layer approach. Before it, we had 3-5 crashes per day from malformed LLM responses.

What I Do Now

Every LLM integration gets this parser as the first step after the API call
Failed parses go to a dead-letter queue with the raw response for debugging
Missing key reports go to a monitoring dashboard — tracks LLM reliability over time
I test with all 5 variants before any production deployment

100 patterns with MUnit tests: github.com/shakarbisetty/mulesoft-cookbook

60-second video walkthroughs: youtube.com/@SanThaParv

Building LLM Prompts From Enterprise Data in DataWeave: 2 Traps That Garbled My AI Output

ThaSha — Sun, 05 Apr 2026 18:53:50 +0000

I connected a MuleSoft API to an LLM last quarter for a support ticket classifier. The API call was easy — the MuleSoft AI Connector handles that. Building the prompt payload from enterprise data? That's where I spent 2 hours debugging escape sequences.

TL;DR

DataWeave transforms ticket data into structured LLM prompt payloads (system + user roles)
joinBy "\n" produces literal backslash-n in JSON — not actual newlines. The LLM sees one continuous line.
No token estimation → prompt consumes most of the context window → truncated response
The pattern builds system role, user role, model config, and structured response format in 12 lines

The Pattern: Enterprise Data to LLM Prompt

%dw 2.0
output application/json
var systemPrompt = "You are an enterprise support analyst."
var lines = payload.ticketHistory map (t) -> "- [$(t.priority upper)] $(t.id): $(t.subject)"
var userPrompt = "Analyze tickets for $(payload.customer.name):\n" ++ (lines joinBy "\n")
---
{
  model: payload.model,
  max_tokens: payload.maxTokens,
  messages: [
    {role: "system", content: systemPrompt},
    {role: "user", content: userPrompt}
  ]
}

Input: customer object + ticket array + model config.
Output: ready-to-send LLM payload with system instructions and contextual user prompt.

100 production-ready DataWeave patterns with tests: mulesoft-cookbook on GitHub

Trap 1: joinBy "\n" Is Literal, Not a Newline

The prompt looks correct in the DataWeave Playground:

- [HIGH] TK-101: API timeout
- [MEDIUM] TK-098: OAuth refresh failing
- [LOW] TK-095: Batch stuck at 80 pct

But the actual JSON sent to the LLM contains:

"content": "- [HIGH] TK-101: API timeout\n- [MEDIUM] TK-098: OAuth refresh failing\n- [LOW] TK-095: Batch stuck at 80 pct"

Literal \n characters. Not newlines. The LLM sees one continuous string and its analysis is garbled — it can't distinguish between tickets.

I spent 2 hours wondering why the classification was wrong before I checked the raw HTTP request body.

The fix: Use an actual newline in a variable, or use template literals that preserve whitespace.

Trap 2: No Token Estimation

I injected 200 ticket summaries into one prompt. Each summary is ~20 tokens. That's 4,000 tokens just for the ticket list. max_tokens was set to 500 for the response.

The model's context window was 4,096 tokens. Prompt + response budget = 4,500 tokens. Didn't fit. The response was truncated mid-sentence.

The fix: Estimate prompt tokens before setting max_tokens:

var estimatedPromptTokens = sizeOf(userPrompt) / 4
var safeMaxTokens = 4096 - estimatedPromptTokens - 100

When to Use This Pattern

Use it when	Alternatives
MuleSoft AI Connector integration	Direct API call with HTTP requester
Structured enterprise data → LLM prompt	Hardcoded prompts (won't scale)
Dynamic context injection (tickets, customer data)	Static system prompts
Multiple LLM providers (swap model field)	Provider-specific SDK

100 patterns with MUnit tests: github.com/shakarbisetty/mulesoft-cookbook

60-second video walkthroughs: youtube.com/@SanThaParv

DataWeave Runtime Type Detection: Auto-Discover Schema Mismatches Before They Break Production

ThaSha — Sun, 05 Apr 2026 17:37:34 +0000

I built a schema discovery function for a 6-system integration last year. Each source sent different types for the same fields. One function auto-detects types at runtime and builds a complete schema.

TL;DR

describeType function uses is operator chain to detect String, Number, Boolean, Array, Object, Null at runtime
Run against sample records from each source to discover type mismatches before writing transforms
Order of is checks matters — always check Array before Object
Null handling needs explicit check — don't rely on catch-all else

The Problem: 6 Sources, 6 Different Types

We integrated with 6 systems. All sent the same logical data — customer fields. But the actual types varied:

Field	Source A	Source B	Source C
age	Number `30`	String `"30"`	null
active	Boolean `true`	String `"true"`	Number `1`
tags	Array `["admin"]`	String `"admin"`	null

Writing transforms that assumed consistent types would silently produce wrong output.

The Solution: Runtime Type Detection

%dw 2.0
output application/json
fun describeType(value) =
  if (value is String) "String"
  else if (value is Number) "Number"
  else if (value is Boolean) "Boolean"
  else if (value is Array) "Array"
  else if (value is Object) "Object"
  else if (value is Null) "Null"
  else "Unknown"
---
{schema: payload.fields map (f) -> ({
  key: f.key,
  type: describeType(f.value),
  nullable: f.value is Null,
  (example: f.value) if (f.value is String or f.value is Number),
  (itemCount: sizeOf(f.value)) if (f.value is Array)
})}

Feed it any payload. Get back a schema with field names, detected types, nullability, and examples.

100 production-ready DataWeave patterns with tests: mulesoft-cookbook on GitHub

Trap 1: Order of `is` Checks Matters

Check Array BEFORE Object. In some DataWeave versions, [] is Object can return true before the Array check runs. Your schema shows "Object" for fields that are actually Arrays.

I hit this in production — an array field got classified as Object. The downstream parser expected an Array, got the string "Object", and silently skipped the field. 200 records processed with missing tags.

Rule: Most specific types first: Null → Boolean → Number → String → Array → Object → Unknown.

Trap 2: Null Falls Through

If your catch-all else returns "Unknown", null values get classified as "Unknown" instead of "Null". Always check is Null explicitly — don't rely on the else clause.

The Preflight Process

I run this on every new integration now:

Sample 100 records from each source system
Run describeType on every field
Compare schemas across sources — flag any field where types differ
Write transforms with explicit type handling for mismatched fields

On the 6-system project, this found 4 fields with type mismatches across 2 sources. Saved 3 days of debugging that would have happened after deployment.

100 patterns with MUnit tests: github.com/shakarbisetty/mulesoft-cookbook

60-second video walkthroughs: youtube.com/@SanThaParv

Recursive PII Masking in DataWeave: One Function for Any Depth (and the Null Trap)

ThaSha — Sun, 05 Apr 2026 16:20:33 +0000

A compliance audit found SSN values 4 levels deep in our API responses last year. One recursive function masks everything. Then null values in production crashed 400 responses.

TL;DR

Recursive maskPII function dispatches on type: Object → check fields, Array → recurse, Primitive → pass through
Works at any nesting depth with one function call: maskPII(payload)
Null values crash it — add explicit null handling before the Object case
No hardcoded paths needed — the function finds PII fields at any level

The Problem: PII at Unknown Depth

Our org chart API returns hierarchical data:

{
  "company": "Acme Corp",
  "ceo": {
    "name": "Alice Chen", "ssn": "123-45-6789", "email": "alice@acme.com",
    "reports": [
      {
        "name": "Bob Martinez", "ssn": "234-56-7890", "email": "bob@acme.com",
        "reports": [
          {"name": "Carol Nguyen", "ssn": "345-67-8901"}
        ]
      }
    ]
  }
}

SSN at level 1 (CEO), level 2 (VP), level 3 (Director). The compliance requirement: mask ALL of them. The depth varies per org — some go 6 levels.

The Recursive Solution

%dw 2.0
output application/json
fun maskSsn(s: String): String = "***-**-" ++ s[-4 to -1]
fun maskEmail(e: String): String = do { var parts = e splitBy "@" --- parts[0][0] ++ "****@" ++ parts[1] }
fun maskPII(data: Any): Any =
    data match {
        case obj is Object -> obj mapObject (value, key) ->
            if ((key as String) == "ssn") {(key): maskSsn(value as String)}
            else if ((key as String) == "email") {(key): maskEmail(value as String)}
            else {(key): maskPII(value)}
        case arr is Array -> arr map maskPII($)
        else -> data
    }
---
maskPII(payload)

Type dispatch: Objects get field-level checking. Arrays recurse into each element. Strings, numbers, booleans pass through unchanged.

One call — maskPII(payload) — handles any depth.

100 production-ready DataWeave patterns with tests: mulesoft-cookbook on GitHub

The Null Trap

Production payloads had null values at level 3 — a manager with no email. The data match block dispatched null to... somewhere unexpected. It tried mapObject on null. Crash. 400 API responses failed.

The fix: add explicit null handling.

fun maskPII(data: Any): Any =
    data match {
        case is Null -> null
        case obj is Object -> obj mapObject ...
        case arr is Array -> arr map maskPII($)
        else -> data
    }

case is Null -> null catches null before it reaches the Object handler. Now null passes through unchanged.

Testing Recursive Functions

I test with these edge cases now:

Empty object {} at each level
Empty array [] at each level
null at each level
Mixed types in arrays: ["text", 42, null, {"key": "value"}]
Maximum expected depth (6 levels for our org chart)

5 minutes of setup in the DataWeave Playground. Prevented every recursive bug since.

100 patterns with MUnit tests: github.com/shakarbisetty/mulesoft-cookbook

60-second video walkthroughs: youtube.com/@SanThaParv

DataWeave match/case: Replace If/Else Chains and Avoid the Missing Else Crash

ThaSha — Sun, 05 Apr 2026 15:02:08 +0000

I replaced a 40-line if/else chain with 4 match/case lines last month. Then I forgot the else clause and 3,000 production events backed up.

TL;DR

match/case replaces nested if/else with value matching, guard conditions, and type dispatch
Missing else clause causes runtime errors on unmatched values — unlike switch/default, there's no implicit fallthrough
event.type fails — type is a reserved word in DataWeave, use event."type" with quotes
Guard conditions (case t if t startsWith "payment.") handle wildcard matching

The Problem: Growing If/Else Chains

We had an event routing flow. Orders, payments, user actions — each type needed a different processing queue:

if (event."type" == "order.created") { category: "ORDER", action: "PROCESS" }
else if (event."type" == "order.cancelled") { category: "ORDER", action: "REFUND" }
else if (event."type" == "payment.received") { category: "PAYMENT", action: "RECONCILE" }
else if (event."type" == "payment.refunded") { category: "PAYMENT", action: "RECONCILE" }
else if (event."type" == "user.login") { category: "CUSTOMER", action: "SYNC" }
else if (event."type" == "user.logout") { category: "CUSTOMER", action: "SYNC" }
else if (event."type" == "user.signup") { category: "CUSTOMER", action: "ONBOARD" }
else { category: "SYSTEM", action: "LOG" }

40 lines. Growing every sprint. Hard to read. Repetitive.

The Fix: match/case

%dw 2.0
output application/json
fun routeEvent(event: Object): Object =
    event."type" match {
        case "order.created" -> ({ category: "ORDER", action: "PROCESS", priority: "NORMAL" })
        case "order.cancelled" -> ({ category: "ORDER", action: "REFUND", priority: "HIGH" })
        case eventType if eventType startsWith "payment." -> ({ category: "PAYMENT", action: "RECONCILE", priority: "HIGH" })
        else -> ({ category: "SYSTEM", action: "LOG", priority: "LOW" })
    }
---
payload.events map (event) -> routeEvent(event)

4 cases. Value matching for exact types. Guard condition for the payment prefix. Else for everything unexpected.

100 production-ready DataWeave patterns with tests: mulesoft-cookbook on GitHub

Trap 1: The Missing Else Clause

I deployed my first version without else. For 3 weeks, every event was a known type. Then an "inventory.updated" event arrived — a type I hadn't handled.

Runtime error. 3,000 events backed up in the queue before monitoring caught it.

DataWeave's match/case does NOT have implicit fallthrough. Without else, an unmatched value throws an exception. Unlike JavaScript's switch where falling through is the default, DataWeave requires explicit handling of every possible value.

Rule: every match block needs an else clause. No exceptions.

Trap 2: Reserved Word Field Access

event.type    // PARSE ERROR — "type" is a reserved word
event."type"  // works — quoted field name

DataWeave reserves type as a keyword. When your JSON has a type field (which is extremely common in event-driven architectures), you must quote it in the selector. I spent 20 minutes debugging this the first time.

Other reserved words that break field selectors: match, case, if, else, do, fun, var, type, input, output.

Guard Conditions: Pattern Matching with Logic

The case eventType if eventType startsWith "payment." syntax combines pattern matching with boolean guards:

event."type" match {
    case t if t startsWith "order." -> handleOrder(t)
    case t if t matches /user\.(.*)/ -> handleUser(t)
    case t if sizeOf(t) > 50 -> handleLongType(t)
    else -> handleUnknown()
}

You can use any boolean expression after if. The bound variable t holds the matched value for use in both the guard and the result.

What I Do Now

Every match block has an else clause before deployment
Reserved word fields always use quoted selectors
New event types go into the match block proactively — I review dead-letter queue weekly
Code reviews flag match without else as a blocking issue

100 patterns with MUnit tests: github.com/shakarbisetty/mulesoft-cookbook

60-second video walkthroughs: youtube.com/@SanThaParv

Multi-Level GroupBy in DataWeave: 2 Traps That Break Your Nested Aggregations

ThaSha — Sun, 05 Apr 2026 13:42:40 +0000

I spent 2 days building a 3-level sales report in DataWeave. Region to country to product, with revenue totals at every level. The code was 10 lines. The debugging was 2 days. Two traps that nobody warns you about.

TL;DR

Nested groupBy creates hierarchical structures from flat data — 3 levels in 10 lines
Every groupBy returns an Object — you MUST use mapObject at every level, never map
sum() on an empty group returns null not 0 — your dashboard shows "null" for revenue
Handles 50,000 records in under 2 seconds

The Problem: Flat Data to Tree Structure

We had 50,000 order records:

[
  {"region": "North America", "country": "USA", "product": "Laptop", "revenue": 45000},
  {"region": "North America", "country": "USA", "product": "Monitor", "revenue": 12000},
  {"region": "Europe", "country": "UK", "product": "Laptop", "revenue": 22000},
  {"region": "Europe", "country": "Germany", "product": "Monitor", "revenue": 9500}
]

The dashboard needed a tree: Region → Country → Product → totals.

The 10-Line Solution

%dw 2.0
output application/json
---
payload groupBy $.region mapObject (regionItems, region) -> ({
    (region): regionItems groupBy $.country mapObject (countryItems, country) -> ({
        (country): countryItems groupBy $.product mapObject (productItems, product) -> ({
            (product): {
                totalRevenue: sum(productItems.revenue),
                count: sizeOf(productItems)
            })
        })
    })
})

100 production-ready DataWeave patterns with tests: mulesoft-cookbook on GitHub

Trap 1: Cannot Coerce Object to Array

My first version used map at level 2:

regionItems groupBy $.country map (countryItems) -> ...

Error: "Cannot coerce :object to :array"

groupBy ALWAYS returns an Object. map expects an Array. This error appears at EVERY level where you use map instead of mapObject. I hit it 3 times — once at each level.

The rule: After groupBy, always mapObject. Never map. Three levels = three mapObject calls.

Trap 2: sum() Returns Null on Empty Groups

A region had no records for one product category. sum([]) returns null, not 0. The dashboard showed "null" in the revenue column.

The finance team reported it as a data quality issue. The fix:

totalRevenue: sum(productItems.revenue) default 0

Add default 0 to every aggregation function. sizeOf correctly returns 0 for empty arrays, but sum, avg, min, max all return null.

Performance

I tested with 50,000 records across 8 regions, 23 countries, and 400 products. Processing time: under 2 seconds on a 0.1 vCore CloudHub worker.

Each groupBy is O(n) and the data set shrinks at each level. The total is still O(n), not O(n^3). The 10-line DataWeave replaced a 200-line Java implementation that took 3 developers a week.

When to Use Multi-Level GroupBy

Use it when	Don't use it when
Building hierarchical reports from flat data	Data is already nested
Dashboard APIs needing tree structures	Output needs to stay flat
Pivot-table style aggregation	Only one grouping dimension
3+ dimensions of analysis	Simple count/sum without hierarchy

100 patterns with MUnit tests: github.com/shakarbisetty/mulesoft-cookbook

60-second video walkthroughs: youtube.com/@SanThaParv

The DataWeave <~ Operator: How Angle Brackets in Customer Notes Broke 200 Orders

ThaSha — Sun, 05 Apr 2026 12:29:41 +0000

A customer typed "" in their notes field. It broke 200 XML orders and I spent 3 hours finding a one-line fix.

TL;DR

User-generated text with angle brackets (<, >) breaks XML output — the parser treats them as tags
The <~ metadata operator with {cdata: true} wraps content in CDATA sections
CDATA preserves angle brackets as literal text: <![CDATA[text with <VIP>]]>
The <~ operator requires DataWeave 2.5 (Mule 4.5+)
JSON output silently ignores cdata metadata — no error, no effect

The Problem: Valid JSON, Invalid XML

We had a Mule flow converting customer orders from JSON to XML for an ERP. Worked for 6 months. Then 200 orders got rejected.

The customer's notes field:

{
  "customer": {
    "name": "Alice Chen",
    "email": "alice@example.com",
    "notes": "Preferred customer since 2020 <VIP>"
  },
  "orderId": "ORD-12345"
}

The DataWeave transform:

%dw 2.0
output application/xml
---
order @(id: payload.orderId): {
    customer @(class: "Person", source: "CRM"): {
        name: payload.customer.name,
        email: payload.customer.email,
        notes: payload.customer.notes
    }
}

Output XML:

<order id="ORD-12345">
  <customer class="Person" source="CRM">
    <name>Alice Chen</name>
    <notes>Preferred customer since 2020 <VIP></notes>
  </customer>
</order>

The <VIP> in the notes became an XML opening tag. No closing </VIP> tag. Invalid XML. The ERP rejected the entire batch.

100 production-ready DataWeave patterns with tests: mulesoft-cookbook on GitHub

The Fix: The <~ Metadata Operator

%dw 2.0
output application/xml
---
order @(id: payload.orderId): {
    customer @(class: "Person", source: "CRM"): {
        name: payload.customer.name,
        email: payload.customer.email,
        notes: payload.customer.notes <~ {cdata: true}
    }
}

Output:

<order id="ORD-12345">
  <customer class="Person" source="CRM">
    <name>Alice Chen</name>
    <notes><![CDATA[Preferred customer since 2020 <VIP>]]></notes>
  </customer>
</order>

The <~ operator attaches metadata to a value without changing its type. {cdata: true} tells the XML writer to wrap the content in a CDATA section. Angle brackets preserved. Valid XML.

The @() Syntax for XML Attributes

The @() syntax adds XML attributes to elements:

customer @(class: "Person", source: "CRM"): { ... }

Produces: <customer class="Person" source="CRM">. Attributes come from your data, not hardcoded in the schema.

Trap 1: <~ Only Works for XML Output

I tried using <~ {cdata: true} on a JSON API response. Nothing happened. No error. No warning. The output was identical with and without the <~.

The cdata metadata is only read by the XML writer. JSON, CSV, and other formats ignore it silently.

Trap 2: Requires DataWeave 2.5

The <~ operator was introduced in DataWeave 2.5 (Mule 4.5+). On older runtimes, it throws a parse error.

Before <~, the approach was:

notes: payload.customer.notes as String {class: "cdata"}

This works on older runtimes but also coerces the type. <~ is cleaner because it only attaches metadata — the value type stays unchanged.

What I Do Now

Any field going to XML that could contain user-generated content gets <~ {cdata: true}:

Customer notes
Product descriptions
Address fields (street addresses with unit symbols like #)
Comment fields from ticketing systems

I also run a pre-transformation check: scan text fields for <, >, &. If found, log a warning and ensure CDATA wrapping is active.

100 patterns with MUnit tests: github.com/shakarbisetty/mulesoft-cookbook

60-second video walkthroughs: youtube.com/@SanThaParv

DataWeave 2.5 Generics: How Call-Site Type Parameters Caught 3 Production Bugs

ThaSha — Sun, 05 Apr 2026 11:12:42 +0000

I maintained a shared DataWeave utility library across 12 Mule apps for 2 years. Functions like topN, pipe, and safeGet. All untyped. All accepting Any. All silently producing wrong output when called with wrong types.

Last quarter I rewrote them with DataWeave 2.5 call-site generics. Three production bugs surfaced on the first compile.

TL;DR

DataWeave 2.5 adds Java/TypeScript-style call-site type parameters: fun topN<T>(...)
The compiler validates T at every call site — type mismatches become compile errors, not runtime surprises
Requires Mule 4.5+ — older runtimes throw parse errors on <T> syntax
I caught 3 bugs that had been producing wrong output for 4 months

The Problem: Untyped Utility Functions

My library had functions like this:

fun topN(items, n, comp) = (items orderBy -comp($))[0 to (n - 1)]

Takes anything. Returns anything. Works on Arrays of Numbers, Strings, Objects. But there's no type checking at the call site.

If someone calls topN(arrayOfStrings, 3, (s) -> s) expecting numeric sorting, they get alphabetical sorting. No error. No warning. Wrong data.

The Fix: Call-Site Generics

DataWeave 2.5 introduced type parameters at the call site:

fun topN<T>(items: Array<T>, n: Number, comp: (T) -> Comparable): Array<T> =
    (items orderBy -comp($))[0 to (n - 1)]

Now calling it:

topN<Number>(payload.numbers, 3, (n) -> n)

The compiler checks that payload.numbers is Array<Number>. If it's Array<String>, you get a compile error. Not a runtime surprise 4 months later.

100 production-ready DataWeave patterns with tests: mulesoft-cookbook on GitHub

The pipe Function: Type-Safe Composition

The pipe function chains transformations:

fun pipe<T>(value: T, fns: Array<(T) -> T>): T =
    fns reduce (fn, acc = value) -> fn(acc)

Usage:

pipe<Array<Number>>(payload.numbers, [
  (arr) -> arr distinctBy $,
  (arr) -> arr orderBy $
])

Every function in the array must accept and return Array<Number>. If one function returns a different shape, the compiler catches it.

Before generics, a function that returned Array<Object> instead of Array<Number> would silently change the data shape downstream. With <T> enforced, every step in the chain must maintain the type contract.

The 3 Bugs Generics Caught

Bug 1: Wrong sort order for 4 months. A flow passed Array<Object> (customer records) to topN expecting Array<Number>. The comparator extracted a String field instead of Number. Sorting was alphabetical, not by magnitude. "Customer #9" ranked above "Customer #10" because "9" > "1" in string comparison.

Bug 2: Shape mismatch in pipe chain. Step 1 in a pipe chain returned Array<Object> but step 2 expected Array<Number>. The output was nested objects where flat numbers were expected. Downstream calculations used the nested objects as numbers — JavaScript-style coercion produced non-obvious wrong values.

Bug 3: Comparator type confusion. A topN call used (r) -> r.score where r.score was a String "95" not Number 95. The ordering was lexicographic: "87" > "100" because "8" > "1". Top 3 by score returned the wrong 3 records.

The Trap: Runtime Version Incompatibility

This requires DataWeave 2.5 (Mule 4.5+). The <T> syntax doesn't parse on older runtimes.

If your team runs mixed Mule versions — some apps on 4.5, some on 4.4 — a shared module with generics compiles on one server and crashes on another.

I version-gate my modules now:

modules/utils-v25.dwl — generics, for Mule 4.5+ apps
modules/utils.dwl — no generics, backward compatible

The 4.4 apps use the untyped version until they're upgraded. Not ideal, but better than breaking production.

When to Use Generics

Use generics when	Don't bother when
Shared utility functions used across 3+ apps	One-off inline transforms
Functions that accept multiple types (topN, pipe, map wrappers)	Functions with a single known input type
Your team is on Mule 4.5+	Mixed runtime versions with no upgrade path

100 patterns with MUnit tests: github.com/shakarbisetty/mulesoft-cookbook

60-second video walkthroughs: youtube.com/@SanThaParv

Config-Driven DataWeave Mapping: The Null Trap Nobody Warns You About

ThaSha — Sun, 05 Apr 2026 03:12:32 +0000

I had 12 tenants sending the same data in 12 different field names. Instead of writing 12 transforms, I built one config-driven mapper. It worked great — until tenant 8's schema drifted and 3,400 records silently filled with nulls.

TL;DR

Config-driven mapping lets you add tenants without code changes — one JSON config per client
The core is 5 lines of DataWeave using dynamic key expressions
The trap: if a config field references a source column that doesn't exist, you get null — silently
The fix: validate config against actual record keys before mapping
Went from 2-day onboarding to 30 minutes per new client

The Problem: 12 Tenants, 12 Schemas

All 12 clients sent the same logical data: customer ID, customer name, order amount. But the field names were different:

Client	Customer ID	Customer Name	Order Amount
Acme Corp	cust_id	cust_name	order_amt
Globex Inc	customer_number	customer_name	amount
Initech	id	name	total

Writing 12 separate DataWeave transforms meant every output schema change required updating 12 files. Deployment coordination across 12 configs was a disaster.

The Solution: 5 Lines of Config-Driven Mapping

%dw 2.0
output application/json
var config = payload.mappingConfig
---
payload.sourceData map (record) -> ({
  (config map (field) -> ({
    (field.target): record[field.source]
  }))
})

The mapping config is a JSON array:

[
  {"source": "cust_id", "target": "customerId"},
  {"source": "cust_name", "target": "customerName"},
  {"source": "order_amt", "target": "orderAmount"}
]

New tenant? Create a config file with their field names. Zero code deployment.

100 production-ready DataWeave patterns with tests: mulesoft-cookbook on GitHub

The Trap: Silent Nulls From Missing Fields

Tenant 8's source system renamed cust_id to customer_id in a schema update. Our config still said cust_id.

record["cust_id"] on a record that has customer_id returns null. Not an error. Not a warning. Just null.

3,400 records went through with customerId: null. The downstream CRM accepted them — null is valid JSON. I caught it 4 days later when the CRM team asked why customer names were missing.

The Fix: Config Validation Before Mapping

Add 3 lines before the mapping:

var sourceKeys = keysOf(payload.sourceData[0])
var configSources = config map (field) -> field.source
var missing = configSources -- sourceKeys
---
if (sizeOf(missing) > 0)
  error("Config references fields not in source: " ++ (missing joinBy ", "))
else
  payload.sourceData map (record) -> ({
    (config map (field) -> ({
      (field.target): record[field.source]
    }))
  })

Now the flow fails fast with: "Config references fields not in source: cust_id". Clear. Actionable. Catches the mismatch before it produces 10,000 records with null fields.

The Dynamic Key Expression Trap

The parentheses in (field.target): value are critical:

// CORRECT — dynamic key from variable
(field.target): record[field.source]

// WRONG — literal string "field.target" as key
field.target: record[field.source]

Without parentheses, DataWeave treats field.target as a literal key name. Your output has {"field.target": "C-100"} instead of {"customerId": "C-100"}.

This is the single most common mistake when building dynamic mappings. The parentheses syntax (expression): value evaluates the expression and uses the result as the key.

What I Do Now

Every config-driven transform gets a validation step that runs before the mapping
Config files are versioned alongside source system API versions
I log the config-to-schema diff on every run — catches drift before it causes nulls
New tenant onboarding takes 30 minutes instead of 2 days

100 patterns with MUnit tests: github.com/shakarbisetty/mulesoft-cookbook

60-second video walkthroughs: youtube.com/@SanThaParv

DataWeave Custom Functions: The Module Trap That Wastes Hours

ThaSha — Sat, 04 Apr 2026 04:20:01 +0000

TL;DR

Your fun declaration works inline but breaks with "Unable to resolve reference" when moved to a .dwl module
Module files cannot contain output or --- — delete those lines and it works
The error message lies — it says "resolve reference" not "invalid module structure"
Recursive custom functions like hand-rolled pow will stack overflow in production
Higher-order functions taking lambdas need explicit type annotations or imports fail silently

I had 4 Mule flows computing the same pricing logic last year. Discounts, tax rounding, shipping thresholds. The functions worked perfectly inline in each flow. Copy-paste across 4 flows. Classic duplication.

So on a Friday afternoon, I did the obvious refactor: extract the functions into a shared .dwl module file. Import once, use everywhere.

It broke immediately. 2 hours of debugging a misleading error message.

The Working Inline Code

Here's what I had in each flow, working perfectly:

%dw 2.0
output application/json
fun roundTo(num: Number, places: Number): Number = (num * pow(10, places) as Number) / pow(10, places)
fun pow(base: Number, exp: Number): Number = if (exp <= 0) 1 else base * pow(base, exp - 1)
fun applyDiscount(price: Number, discountFn: (Number) -> Number): Number = discountFn(price)
var discount = (p: Number) -> if (p > 500) p * 0.9 else p
---
payload.products map (p) -> ({
  name: p.name,
  originalPrice: p.price,
  discounted: roundTo(applyDiscount(p.price, discount), 2),
  tax: roundTo(applyDiscount(p.price, discount) * payload.taxRate, 2),
  freeShipping: p.price >= payload.freeShippingThreshold
})

Three custom functions: roundTo for decimal precision, pow as a recursive helper, and applyDiscount — a higher-order function that takes a lambda for the discount strategy. Clean input/output:

{
  "products": [
    {"name": "Laptop Pro", "price": 1299.99},
    {"name": "Standing Desk", "price": 799},
    {"name": "Wireless Mouse", "price": 29.99},
    {"name": "Office Chair", "price": 449}
  ],
  "taxRate": 0.0875,
  "freeShippingThreshold": 100
}

Output: each product with computed discount, tax, and shipping flag. No issues.

100 production-ready DataWeave patterns with tests: mulesoft-cookbook on GitHub

Trap 1: The Module Structure Constraint

I copied the entire script into src/main/resources/modules/pricing.dwl. Imported it:

import * from modules::pricing

Error: "Unable to resolve reference of pricing"

The function was right there. The path was correct. I checked classpath, file encoding, permissions. Nothing worked.

The problem: my module file still had output application/json and the --- separator from the inline script. Module files cannot contain these. DataWeave modules only allow:

fun declarations
var declarations
type definitions
namespace definitions

No output. No ---. No body expression.

The correct module file:

fun roundTo(num: Number, places: Number): Number = (num * pow(10, places) as Number) / pow(10, places)
fun pow(base: Number, exp: Number): Number = if (exp <= 0) 1 else base * pow(base, exp - 1)
fun applyDiscount(price: Number, discountFn: (Number) -> Number): Number = discountFn(price)
var discount = (p: Number) -> if (p > 500) p * 0.9 else p

Delete %dw 2.0, delete output application/json, delete ---, delete the body. Keep only declarations.

Trap 2: Recursive Functions Without Depth Limits

The pow function is recursive:

fun pow(base: Number, exp: Number): Number = if (exp <= 0) 1 else base * pow(base, exp - 1)

In testing with exponent 2 or 3, it works. In production, a pricing rule with exponent 500 hits the call stack limit. DataWeave doesn't have tail-call optimization for this pattern.

The fix: use dw::util::Math functions instead of hand-rolling recursion for anything that touches production data. Built-in functions handle edge cases you haven't thought of.

Trap 3: Higher-Order Function Type Errors

applyDiscount takes a lambda parameter:

fun applyDiscount(price: Number, discountFn: (Number) -> Number): Number = discountFn(price)

If someone imports this and passes the wrong function signature — say a function that takes two arguments — the error is cryptic. DataWeave checks types at the call site, but the error message references the module internals, not the caller's mistake.

Always type-annotate function parameters explicitly. (Number) -> Number tells the caller exactly what shape of lambda to pass.

What Module Files Can and Cannot Contain

Allowed in modules	NOT allowed in modules
`fun` declarations	`output` directive
`var` declarations	`---` separator
`type` definitions	Body expressions
`namespace` definitions	`%dw 2.0` header

This constraint exists because modules are imported, not executed. They provide definitions for other scripts to use. They don't produce output themselves.

What I Do Now

Before deploying any shared .dwl module, I run a 30-second check:

Does the file contain output? Remove it.
Does the file contain ---? Remove it.
Does any function use recursion? Replace with built-in.
Are all function parameters type-annotated? If not, add types.

Would have saved me those 2 Friday hours.

100 patterns with MUnit tests: github.com/shakarbisetty/mulesoft-cookbook

60-second video walkthroughs: youtube.com/@SanThaParv

DEV Community: ThaSha

RFC 7807 Error Responses in DataWeave: One Transform for All 14 Endpoints

The Problem: 14 Endpoints, 14 Error Formats

The Solution: RFC 7807 Error Envelope

The Error Mapping Lookup

Trap: Missing default Clause

The Reserved Word Trap

RFC 7807 Fields

What I Do Now

DataWeave partition() for Bulk API Responses: Stop Returning Silent 200 OKs

The Problem: Silent Bulk Failures

The Solution: partition() + Summary Builder

How partition() Works

The Conditional Key Trick

Trap: Divide by Zero on Empty Batch

What the Caller Gets

What I Do Now

Parsing LLM Responses in DataWeave: 3 Layers of Defense Against Markdown Fences

The Problem: LLMs Don't Return Clean JSON

The Solution: 3-Layer Defense in DataWeave

Layer 1: Regex Fence Extraction

Layer 2: try() Wraps the Parse

Layer 3: Required Key Validation

The 5 Response Variants to Test

Trap: The Regex Doesn't Handle Nested Objects Well

Performance

What I Do Now

Building LLM Prompts From Enterprise Data in DataWeave: 2 Traps That Garbled My AI Output

The Pattern: Enterprise Data to LLM Prompt

Trap 1: joinBy "\n" Is Literal, Not a Newline

Trap 2: No Token Estimation

When to Use This Pattern

DataWeave Runtime Type Detection: Auto-Discover Schema Mismatches Before They Break Production

The Problem: 6 Sources, 6 Different Types

The Solution: Runtime Type Detection

Trap 1: Order of is Checks Matters

Trap 2: Null Falls Through

The Preflight Process

Recursive PII Masking in DataWeave: One Function for Any Depth (and the Null Trap)

The Problem: PII at Unknown Depth

The Recursive Solution

The Null Trap

Testing Recursive Functions

DataWeave match/case: Replace If/Else Chains and Avoid the Missing Else Crash

The Problem: Growing If/Else Chains

The Fix: match/case

Trap 1: The Missing Else Clause

Trap 2: Reserved Word Field Access

Guard Conditions: Pattern Matching with Logic

What I Do Now

Multi-Level GroupBy in DataWeave: 2 Traps That Break Your Nested Aggregations

The Problem: Flat Data to Tree Structure

The 10-Line Solution

Trap 1: Cannot Coerce Object to Array

Trap 2: sum() Returns Null on Empty Groups

Performance

When to Use Multi-Level GroupBy

The DataWeave <~ Operator: How Angle Brackets in Customer Notes Broke 200 Orders

The Problem: Valid JSON, Invalid XML

The Fix: The <~ Metadata Operator

The @() Syntax for XML Attributes

Trap 1: <~ Only Works for XML Output

Trap 2: Requires DataWeave 2.5

What I Do Now

DataWeave 2.5 Generics: How Call-Site Type Parameters Caught 3 Production Bugs

The Problem: Untyped Utility Functions

The Fix: Call-Site Generics

The pipe Function: Type-Safe Composition

The 3 Bugs Generics Caught

The Trap: Runtime Version Incompatibility

When to Use Generics

Config-Driven DataWeave Mapping: The Null Trap Nobody Warns You About

The Problem: 12 Tenants, 12 Schemas

The Solution: 5 Lines of Config-Driven Mapping

The Trap: Silent Nulls From Missing Fields

The Fix: Config Validation Before Mapping

The Dynamic Key Expression Trap

What I Do Now

DataWeave Custom Functions: The Module Trap That Wastes Hours

The Working Inline Code

Trap 1: Order of `is` Checks Matters