DEV Community: Shakar Bisetty

Use host.docker.internal to reach local Ollama from Mule

Shakar Bisetty — Sun, 13 Sep 2026 14:58:47 +0000

Problem

The flow failed with a connection refused error when the configuration used http://localhost:11434/v1 as the base URL. The MuleSoft Inference Connector enables text generation workflows docs.

Input

{
  "prompt": "Reply with exactly one word: pong"
}

Working configuration

<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesoft.org/schema/mule/core"
      xmlns:http="http://www.mulesoft.org/schema/mule/http"
      xmlns:ms-inference="http://www.mulesoft.org/schema/mule/ms-inference"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="
        http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
        http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
        http://www.mulesoft.org/schema/mule/ms-inference http://www.mulesoft.org/schema/mule/ms-inference/current/mule-ms-inference.xsd">

  <http:listener-config name="http-listener-config">
    <http:listener-connection host="0.0.0.0" port="8081" />
  </http:listener-config>

  <ms-inference:text-generation-config name="ollama-openai-compatible">
    <ms-inference:openai-compatible-connection
        openAICompatibleModelName="qwen2.5:14b"
        openAICompatibleURL="http://host.docker.internal:11434/v1"
        apiKey="ollama"
        maxTokens="16"
        temperature="0"
        topP="1"
        timeout="120" />
  </ms-inference:text-generation-config>

  <flow name="ask">
    <http:listener config-ref="http-listener-config" path="/ask" />
    <ms-inference:chat-answer-prompt config-ref="ollama-openai-compatible">
      <ms-inference:prompt>#[payload.prompt]</ms-inference:prompt>
    </ms-inference:chat-answer-prompt>
  </flow>
</mule>

Output

{"response": {"response": "Pong"}, "status": 200}

The response field contains the model output, and status shows 200.

The trap

Using http://localhost:11434/v1 as the base URL causes a connection refused error.

What I do now

I configure openAICompatibleURL to http://host.docker.internal:11434/v1 in the connector configuration.

Runs shown: Mule 4 Community kernel 4.12.0

104 DataWeave patterns + 8 Exchange modules with 208 MUnit tests: github.com/shakarbisetty/mulesoft-cookbook | 60-second walkthroughs: youtube.com/@SanThaParv

Partition once versus filter twice for bulk email validation

Shakar Bisetty — Thu, 10 Sep 2026 03:23:34 +0000

The decision

The partition function separates the array into the elements that satisfy the condition from those that do not docs. The filter function iterates over an array and applies an expression that returns matching values docs. Both scripts compute the task to split payload.records into accepted ids and rejected records with a reason, plus a retry count, by an email match.

First approach

The partition once approach uses the import line import * from dw::core::Arrays.

%dw 2.0
import * from dw::core::Arrays
output application/json
var split = payload.records partition (r) ->
    (r.email default "") matches /.+@.+\..+/
---
{
  accepted: split.success map (r) -> r.id,
  rejected: split.failure map (r) -> {
    id: r.id,
    reason: "missing or invalid email"
  },
  retryCount: sizeOf(split.failure)
}

Second approach

The filter twice approach requires no import.

%dw 2.0
output application/json
var valid = payload.records filter ((r) -> (r.email default "") matches /.+@.+\..+/)
var invalid = payload.records filter ((r) -> not ((r.email default "") matches /.+@.+\..+/))
---
{
  accepted: valid map (r) -> r.id,
  rejected: invalid map (r) -> {
    id: r.id,
    reason: "missing or invalid email"
  },
  retryCount: sizeOf(invalid)
}

Same input, same output

{
  "records": [
    { "id": "ORD-1001", "email": "ana@example.com" },
    { "id": "ORD-1002", "email": "bad-address" },
    { "id": "ORD-1003", "email": "raj@example.org" },
    { "id": "ORD-1004" },
    { "id": "ORD-1005", "email": "mei@example.net" }
  ]
}

Both scripts print the same output for this input.

{
  "accepted": [
    "ORD-1001",
    "ORD-1003",
    "ORD-1005"
  ],
  "rejected": [
    {
      "id": "ORD-1002",
      "reason": "missing or invalid email"
    },
    {
      "id": "ORD-1004",
      "reason": "missing or invalid email"
    }
  ],
  "retryCount": 2
}

Measured

Input	Records	Script	Runs	Min ms	Median ms	Max ms	Source
small	5	partition once	10	77	84	94	verified in sandbox
large	50000	partition once	10	378	383	388	verified in sandbox
small	5	filter twice	10	52	55.5	62	verified in sandbox
large	50000	filter twice	10	319	326.5	335	verified in sandbox
small	5	baseline	10	50	51.5	60	verified in sandbox
large	50000	baseline	10	143	147	154	verified in sandbox

Script	Input traversals	Imports	Lines	Source
partition once	1	import * from dw::core::Arrays	14	verified in sandbox
filter twice	2	none	13	verified in sandbox
baseline	1	none	4	verified in sandbox

At 5 records the timing ranges did not overlap and partition once measured 77 to 94 ms while filter twice measured 52 to 62 ms.
At 50000 records the timing ranges did not overlap and partition once measured 378 to 388 ms while filter twice measured 319 to 335 ms.

When I choose which

At 5 records the timing ranges do not overlap. At 50000 records the timing ranges do not overlap. I choose filter twice because it carried the lower median at both record counts and its two traversals avoid the import line. See how to partition bulk records into accepted and rejected lists Partition bulk records into accepted and rejected lists.

Runs shown: DataWeave CLI 2.12.2

104 DataWeave patterns + 8 Exchange modules with 208 MUnit tests: github.com/shakarbisetty/mulesoft-cookbook | 60-second walkthroughs: youtube.com/@SanThaParv

dw-validation-utils: 12 DataWeave validation functions, sandbox-verified reference

Shakar Bisetty — Wed, 09 Sep 2026 22:09:56 +0000

Problem

Validate incoming data before processing. docs
12 reusable validation functions for DataWeave 2.x — field validation, pattern matching, and bulk payload validation. docs

The table

Function	Signature	Returns / behaviour	Source
`isRequired`	`fun isRequired(val: Any, fieldName: String): Object =`	returns `name` as `{ valid: false, field: "name", error: "name must not be empty" }`, `email` as `{ valid: false, field: "email", error: "email is required" }`, `tags` as `{ valid: false, field: "tags", error: "tags must not be empty" }`, and `status` as `{ valid: true }`	verified in sandbox
`minLength`	`fun minLength(s: String, min: Number, fieldName: String = "field"): Object =`	returns `valid` as `false`, `field` as `"field"`, and `error` as `"field must be at least 5 characters"` for a string shorter than the limit without a custom field name	verified in sandbox
`maxLength`	`fun maxLength(s: String, max: Number, fieldName: String = "field"): Object =`	returns `valid` as `false`, `field` as `"name"`, and `error` as `"name must not exceed 10 characters"` when the input exceeds the limit	verified in sandbox
`inRange`	`fun inRange(n: Number, min: Number, max: Number, fieldName: String = "field"): Object =`	returns `inside` as `{ valid: true }`, `boundary` as `{ valid: true }`, and `outside` as `{ valid: false, field: "age", error: "age must be between 10 and 100" }`	verified in sandbox
`matchesPattern`	`fun matchesPattern(s: String, regex: String, fieldName: String = "field"): Object =`	returns `validMatch` as `{ valid: true }` and `invalidMatch` as `{ valid: false, field: "invalidCode", error: "invalidCode does not match required pattern" }`	verified in sandbox
`isValidDate`	`fun isValidDate(s: String, fmt: String, fieldName: String = "field"): Object =`	returns `validCheck` as `{ valid: true }` and `invalidCheck` as `{ valid: false, field: "invalidDate", error: "invalidDate is not a valid date (expected format: yyyy-MM-dd)" }`	verified in sandbox
`isOneOf`	`fun isOneOf(val: Any, allowed: Array, fieldName: String = "field"): Object =`	returns `valid` as `false`, `field` as `"status"`, and `error` as `"status must be one of: ACTIVE, INACTIVE, PENDING"` when the value falls outside the set	verified in sandbox
`isUUID`	`fun isUUID(s: String): Boolean =`	returns `valid` as `true`, `nil` as `true`, and `invalid` as `false` for the respective inputs	verified in sandbox
`isURL`	`fun isURL(s: String): Boolean =`	returns `validUrl` as `true` and `invalidWord` as `false` for the respective inputs	verified in sandbox
`isPhone`	`fun isPhone(s: String): Boolean =`	returns `e164` as `true` and `sixteenDigits` as `false` for the respective inputs	verified in sandbox
`validateAll`	`fun validateAll(obj: Object, rules: Object): Object = do {`	returns `valid` as `false` and `errors` as `[{ valid: false, field: "email", error: "email is required" }]` when rules fail	verified in sandbox
`hasRequiredFields`	`fun hasRequiredFields(obj: Object, fields: Array<String>): Object = do {`	returns `valid` as `false`, `missing` as `["email", "phone"]`, and `error` as `"Missing required fields: email, phone"` when fields are absent	verified in sandbox

How to read it

I check the Function column for the exact module export name and verify the Signature column matches my runtime DataWeave version. I read the Returns / behaviour column to confirm whether the call yields a Boolean or an Object containing valid, field, and error keys, noting that minLength defaults the field name to "field". I always place import modules::ValidationUtils at the top of my script before referencing any exported function.

Traps

Missing import causes the runtime to fail with Unable to resolve reference of ValidationUtils::isRequired when the script executes without the module declaration.

What I do now

I load the module at the top of every DataWeave file and pass payload fields directly into the validation functions or wrap them in validateAll for bulk checks. I parse the returned Object to extract the valid flag and route flows based on whether errors contains entries.

Runs shown: DataWeave CLI 2.12.2

104 DataWeave patterns + 8 Exchange modules with 208 MUnit tests: github.com/shakarbisetty/mulesoft-cookbook | 60-second walkthroughs: youtube.com/@SanThaParv

RFC 7807 Error Envelope with DataWeave Try Function

Shakar Bisetty — Wed, 09 Sep 2026 15:16:31 +0000

Problem

My script failed when try lacked an explicit import from dw::Runtime. The runtime reported Unable to resolve reference of: try during execution. The documentation describes try as a function that returns a Result object for handling errors docs.

Input

{
  "order": { "id": "ORD-2001", "total": "12.5O" }
}

Working configuration

%dw 2.0
// try() lives in dw::Runtime — not imported by default
import try from dw::Runtime
// RFC 7807 media type is accepted as-is by the JSON writer
output application/problem+json
var attempt = try(() -> payload.order.total as Number)
---
if (attempt.success) { total: attempt.result }
else {
  "type": "https://example.com/problems/invalid-total",
  "title": "Invalid order total",
  "status": 400,
  "detail": attempt.error.message,
  "instance": "/orders/" ++ payload.order.id,
  "errorKind": attempt.error.kind
}

Output

{
  "type": "https://example.com/problems/invalid-total",
  "title": "Invalid order total",
  "status": 400,
  "detail": "Cannot coerce String (12.5O) to Number",
  "instance": "/orders/ORD-2001",
  "errorKind": "InvalidNumberException"
}

The detail field contains the string Cannot coerce String (12.5O) to Number. The errorKind field holds the value InvalidNumberException.

The trap

The missing import causes a resolution failure when the script executes. Running fail_noimport.dwl produces an exit code of 255 and reports Unable to resolve reference of: try.

What I do now

I always add import try from dw::Runtime at the top of every script that uses the function. I verify the import exists before running the transformation to prevent resolution errors.

Runs shown: DataWeave CLI 2.12.2

104 DataWeave patterns + 8 Exchange modules with 208 MUnit tests: github.com/shakarbisetty/mulesoft-cookbook | 60-second walkthroughs: youtube.com/@SanThaParv

Partition bulk records into accepted and rejected lists

Shakar Bisetty — Wed, 09 Sep 2026 15:13:29 +0000

Problem

My DataWeave script threw an unresolved reference error when calling partition without an explicit import. The Arrays module must be imported to your DataWeave code by adding the line import * from dw::core::Arrays to the header of your DataWeave script docs.

Input

{
  "records": [
    { "id": "ORD-1001", "email": "ana@example.com" },
    { "id": "ORD-1002", "email": "bad-address" },
    { "id": "ORD-1003", "email": "raj@example.org" },
    { "id": "ORD-1004" },
    { "id": "ORD-1005", "email": "mei@example.net" }
  ]
}

Working configuration

%dw 2.0
// partition() lives in dw::core::Arrays — not imported by default
import * from dw::core::Arrays
output application/json
// keys are ALWAYS success/failure — re-map them to domain names
var split = payload.records partition (r) ->
    (r.email default "") matches /.+@.+\..+/
---
{
  accepted: split.success map (r) -> r.id,
  rejected: split.failure map (r) -> {
    id: r.id,
    reason: "missing or invalid email"
  },
  retryCount: sizeOf(split.failure)
}

Output

{
  "accepted": [
    "ORD-1001",
    "ORD-1003",
    "ORD-1005"
  ],
  "rejected": [
    {
      "id": "ORD-1002",
      "reason": "missing or invalid email"
    },
    {
      "id": "ORD-1004",
      "reason": "missing or invalid email"
    }
  ],
  "retryCount": 2
}

The accepted array contains IDs from records with valid emails, while the rejected array holds objects for records missing or invalidating email addresses. The retryCount field reports the size of the failure partition as two.

The trap

The trap is an unresolved reference error when calling partition without importing the Arrays module.

What I do now

I add import * from dw::core::Arrays to the DataWeave header before using partition. I map the success and failure keys to domain names like accepted and rejected. I calculate retry counts using sizeOf on the failure partition.

Runs shown: DataWeave CLI 2.12.2

104 DataWeave patterns + 8 Exchange modules with 208 MUnit tests: github.com/shakarbisetty/mulesoft-cookbook | 60-second walkthroughs: youtube.com/@SanThaParv

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

Shakar Bisetty — 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

Shakar Bisetty — 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

Shakar Bisetty — 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 requires `json` after fence
No fences, with preamble	`Here is my analysis: {"ranking": [...]}`	Naive `read()` on full string
Broken JSON	`{"ranking": ["TK-101"` (truncated)	Any parser without `try()`

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

Shakar Bisetty — 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

Shakar Bisetty — 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)

Shakar Bisetty — 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

Shakar Bisetty — 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

DEV Community: Shakar Bisetty

Use host.docker.internal to reach local Ollama from Mule

Problem

Input

Working configuration

Output

The trap

What I do now

Partition once versus filter twice for bulk email validation

The decision

First approach

Second approach

Same input, same output

Measured

When I choose which

dw-validation-utils: 12 DataWeave validation functions, sandbox-verified reference

Problem

The table

How to read it

Traps

What I do now

RFC 7807 Error Envelope with DataWeave Try Function

Problem

Input

Working configuration

Output

The trap

What I do now

Partition bulk records into accepted and rejected lists

Problem

Input

Working configuration

Output

The trap

What I do now

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: Order of `is` Checks Matters