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

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:

1. Sample 100 records from each source system
2. Run describeType on every field
3. Compare schemas across sources — flag any field where types differ
4. 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