Skip to main content

mapping

Executes a Bloblang mapping on messages, creating a new document that replaces (or filters) the original message.

When to Use

Use mapping processor when you need to:

  • Transform JSON structure — reshape, rename, or compute fields
  • Filter messages — drop events based on conditions
  • Enrich data — add computed fields, timestamps, or metadata
  • Redact sensitive data — mask PII fields before forwarding

Don't use this if:

  • You're making minor changes to a large document — use mutation (more efficient)
  • You need to call an external API for enrichment — use http processor
  • You want to aggregate multiple messages — use group_by

Common Patterns

Reshape Document

pipeline:
processors:
- mapping: |
root.user_id = this.user.id
root.event = this.action.type
root.timestamp = now()

Filter by Condition

pipeline:
processors:
- mapping: |
root = if this.level == "ERROR" || this.level == "WARN" {
this
} else {
deleted()
}

Redact PII

pipeline:
processors:
- mapping: |
root = this
root.email = this.email.split("@").index(1) # Keep domain only
root.ip = "xxx.xxx.xxx." + this.ip.split(".").index(3)
Learn More

See the full Bloblang guide for the complete transformation language reference.


# Config fields, showing default values
label: ""
mapping: "" # No default (required)

Bloblang is a powerful language that enables a wide range of mapping, transformation and filtering tasks. For more information check out the docs.

If your mapping is large and you'd prefer for it to live in a separate file then you can execute a mapping directly from a file with the expression from "<path>", where the path must be absolute, or relative from the location that Expanso Edge is executed from.

Input Document Immutability

Mapping operates by creating an entirely new object during assignments, this has the advantage of treating the original referenced document as immutable and therefore queryable at any stage of your mapping. For example, with the following mapping:

root.id = this.id
root.invitees = this.invitees.filter(i -> i.mood >= 0.5)
root.rejected = this.invitees.filter(i -> i.mood < 0.5)

Notice that we mutate the value of invitees in the resulting document by filtering out objects with a lower mood. However, even after doing so we're still able to reference the unchanged original contents of this value from the input document in order to populate a second field. Within this mapping we also have the flexibility to reference the mutable mapped document by using the keyword root (i.e. root.invitees) on the right-hand side instead.

Mapping documents is advantageous in situations where the result is a document with a dramatically different shape to the input document, since we are effectively rebuilding the document in its entirety and might as well keep a reference to the unchanged input document throughout. However, in situations where we are only performing minor alterations to the input document, the rest of which is unchanged, it might be more efficient to use the mutation processor instead.

Error Handling

Bloblang mappings can fail, in which case the message remains unchanged, errors are logged, and the message is flagged as having failed, allowing you to use processor error handling patterns.

However, Bloblang itself also provides powerful ways of ensuring your mappings do not fail by specifying desired fallback behaviour, which you can read about in this section.

Examples

Given JSON documents containing an array of fans:

{
"id":"foo",
"description":"a show about foo",
"fans":[
{"name":"bev","obsession":0.57},
{"name":"grace","obsession":0.21},
{"name":"ali","obsession":0.89},
{"name":"vic","obsession":0.43}
]
}

We can reduce the documents down to just the ID and only those fans with an obsession score above 0.5, giving us:

{
"id":"foo",
"fans":[
{"name":"bev","obsession":0.57},
{"name":"ali","obsession":0.89}
]
}

With the following config:

pipeline:
processors:
- mapping: |
root.id = this.id
root.fans = this.fans.filter(fan -> fan.obsession > 0.5)