Visual Editors

Some node windows offer visual editors next to the code editors:

• Data Mapper - builds a SpEL record field by field, for example the value of a Variable.
• Condition Builder - builds a boolean SpEL expression from a list of conditions, for example in a Filter or a Choice.
• JSON schema builder - defines the fields of a Key-Value Store namespace as a table instead of JSON Schema text.

The Data Mapper and the Condition Builder are generators: they show the SpEL they produce, and Apply writes it into the field the editor was opened from. The result is an ordinary SpEL expression, so you can keep editing it in the code editor, and the scenario does not depend on the editor that produced it.

Enabling the Data Mapper and the Condition Builder

Both editors are opened with a button with a magic-wand icon at the right end of an expression field. Its tooltip reads Open Data Mapper or Open Condition Builder. The button is shown only in edit mode, and only when the node.showFieldExpressionBuilder user setting is on. The setting is on by default; you can switch it off for yourself on the Designer's /__settings page, and the choice is stored in your browser.

Data Mapper

Where it appears

Node / parameter	What the Data Mapper edits
Variable - Expression	the whole expression, as a record
HTTP enricher - Body, HTTP Callback - Body, Event Generator - value, Topic sink - Value (raw editor), Key-Value Store - Value	the parameter, as a record. When the parameter's type is known (for example from a topic or namespace schema), its fields are preloaded and cannot be renamed, added or removed
Sinks whose fields are separate parameters (for example a Response or Topic sink with the raw editor off), OpenAPI, Lookup and ML enrichers	all SpEL parameters of the node at once; each parameter is one target field and its fields are fixed. Apply writes each mapped field back into its own parameter

The window

The Data Mapper opens in its own window, on top of the node window.

• Context Variables (left) - the variables available at this node, as a tree. Use Search… to filter it. The upload icon (Load context from JSON sample) lets you paste a JSON object whose top-level keys are variable names, to browse sample values.
• Target Record (right) - the fields of the record being built, with an N / M mapped counter. A green dot marks a mapped field, a red dot a field whose expression has a validation error.
• Expression (bottom) - the SpEL the mapping produces, with a copy button.
• Apply (footer) - writes the expression into the field and closes the window.

Mapping fields

• Drag a variable or one of its fields from Context Variables onto a target field to map it. Dropping onto an unnamed field also names it. Dropping onto the empty area below the fields adds a new field. Dropping a record adds a nested record with all of its fields mapped.
• Click a target field to expand it: there you can change its name and type, and write its expression in a SpEL editor with autocompletion. While a field is expanded, clicking a leaf in Context Variables maps it to that field.
• Add default value - adds a fallback used when the expression returns null. It is written with the Elvis operator: expression ?: default.
• Auto-map - fills fields that are still empty, or hold only a literal such as 0, '', true or null, with the context field of the same name. Names are compared ignoring case, _ and spaces.
• Null-safe (on by default) - expressions inserted by dragging, clicking or Auto-map use null-safe navigation, for example #input?.customer?.id instead of #input.customer.id.
• Use the arrows on a field to move it up or down, and the bin icon to remove it.

When the record's fields are not fixed by a schema, you can also define them:

• Add Field - adds an empty field. Add field under a nested record adds a field to it.
• From Schema - pick a Kafka topic with a defined schema to load its fields.
• From Sample - paste a JSON object to create fields with types guessed from the values. Replace all replaces the current fields, Merge (add missing) only adds fields with new names.

Field types

A field's type is one of String, Integer, Long, Float, Double, Boolean, BigDecimal, List, ZonedDateTime, LocalDate, LocalDateTime, LocalTime, Instant, Duration, Period, OffsetDateTime or Any, or Record for a nested record. The type is not written into the expression. The Data Mapper uses it to:

• report Type mismatch when the expression returns another type (numeric types are treated as compatible),
• convert a dragged or clicked source of another type, for example Long to Instant with #DATE.toInstant(...), or an untyped value to Integer with ?.toIntegerOrNull ?: 0.

A field of type Any takes the type returned by its expression. A nested record can be turned into a plain expression with Switch to expression; Build Record turns a field typed as a map back into a nested record. List fields hold an expression; the Data Mapper does not edit list elements one by one.

Generated SpEL

The Data Mapper writes a record literal, one field per line, nested records indented:

{
  customerId: #input?.customer?.id,
  amount: #input?.amount ?: 0,
  address: {
    city: #input?.address?.city,
    zip: null
  }
}

A field without an expression is written as null. The field name is written as-is, without quotes.

Limitations

• The Data Mapper reads the current value back only if it is a record literal { ... }. For any other expression, a list literal such as {1, 2} included, it starts with no fields, and Apply replaces the expression. The same happens for an expression written in the SpEL Template or JSON Template editor.
• A record without fields is written as {:}, the empty record ({} is the empty list in SpEL).
• Fields read back get their type from the schema, if there is one; otherwise they start as Any and take the type returned by their expression.

Condition Builder

Where it appears

Node	Field
Filter	Condition
Choice	the condition of each outgoing branch. Not available when branches are matched by value (Switch expression with Cases)
Decision Table	Match condition; #ROW is listed first among the variables

Building a condition

The Condition Builder opens as a dialog.

• Context Variables (left) - double-click a variable or drag it to insert it into the focused operand.
• Conditions - each row has a left operand, an operator and, for most operators, a right operand. Both operands are SpEL expressions with autocompletion and validation. Add condition adds a row; rows with an empty left operand are ignored.
• Combine with: - shown when there are two or more rows: AND (&&) or OR (||). One combinator applies to all rows; there are no nested groups.
• Expression preview - the generated SpEL. Apply writes it into the field.

Operator	Generated SpEL
is true	left
is false	!left
equals / not equals	left == right / left != right
less than / less than or equal	left < right / left <= right
greater than / greater than or equal	left > right / left >= right
is null / is not null	left == null / left != null
matches (regex)	left matches 'pattern'
not matches (regex)	!(left matches 'pattern')

For the regex operators the right side is the pattern itself, written without quotes; the builder adds them. Each condition goes on its own line, for example:

#input.amount > 1000
&& #input.country != 'PL'

Limitations

• An existing expression is split into rows at the top-level && or ||. A part that is not one of the comparisons above becomes an is true row containing that part.
• All rows are joined by the same && or ||. An expression that mixes them, such as (#a || #b) && #c, is shown as rows joined by the outer one, with the inner part in a single row; the parentheses that keep its meaning are written back.
• If the expression cannot be parsed, the dialog shows Expression too complex to visualize — editing will replace it, and Apply overwrites the expression.

JSON schema builder

The JSON schema builder is used in the Key-Value Store node window, when you create a namespace (Create new namespace) or change one (Edit schema). It defines the value schema of the namespace.

Switch between the Table and JSON views at the top:

• Table - one row per field: Field name, Type, and Req. (required) when the Designer can read the namespace metadata. More options adds Description and Default value. Add field adds a row.
• JSON - the same schema as JSON Schema text.

Type	JSON Schema
String	{"type": "string"}
Integer	{"type": "integer"}
Long	{"type": "integer", "format": "int64"}
Double	{"type": "number", "format": "double"}
BigDecimal	{"type": "number"}
Boolean	{"type": "boolean"}

The builder handles flat schemas only: an object with properties, without nested objects and without $ref, anyOf, oneOf, allOf or not. Switching such a schema to the Table view shows Schema is too complex to display in table mode. Edit JSON directly. The namespace is saved from the table rows, so parts of the schema the table cannot show are not saved.

Request-Response input and output schemas are not edited with this builder; they are written as JSON, see Defining input and output.