Docs / dflux EdgeGuard
ContactGet started

Transformation engine

Transformation rules rewrite traffic in flight. They run in two phases — before forwarding to a producer (request phase) and before answering the consumer (response phase) — and cover headers, body fields, and Diameter AVPs.

Two phases, one rule format

Each transformation rule declares a phase of request or response. The request-phase filter runs inside the request filter chain, before routing. The response-phase filter runs in the response stage, before the answer reaches the consumer.

Both phases use the same rule schema. The difference is when the rule fires and what it can see — request phase has the inbound request, response phase has the producer's answer.

What rules can do

Each rule names a single action and supplies its parameters in a config object. The actions group by what they touch:

  • Headers: header_set, header_add, header_remove, header_rewrite (regex pattern and replacement).
  • Body fields: body_field_set, body_field_remove, body_field_mask (full, partial, or hash), body_field_map (value lookup table). Body fields are addressed by JSON Pointer path.
  • Response only: status_rewrite (remap a status code) and error_normalize (rewrite a 3GPP ProblemDetails body).
  • Diameter AVPs: avp_set, avp_add, avp_remove, avp_rewrite, avp_mask, addressed by AVP code and vendor id.

See Transformation schema for the full config field list per action.

Rule ordering inside a phase

Within a phase, rules are sorted by priority ascending at filter-build time — lowest value runs first. Two rules with the same priority sort by name for determinism.

Priority is per phase
Priorities don't span phases — a rule with priority 10 in the request phase has no relationship to a rule with priority 10 in the response phase.

Match conditions

A rule with an empty condition block applies to every message in its phase. A populated condition runs the rule only when every set field matches. It embeds the same flat common-condition fields as policy rules (path_patterns, methods, source_nf_types, target_nf_types, snssais, AVP matchers, …) plus transform-specific header_match, body_field_match, and status_codes.

Use match conditions to scope rules tightly. A rule that strips a sensitive header should typically match only the path patterns or NF types where that header appears.

Example: mask GPSI on inbound

A request-phase rule that masks the gpsi field in the body before the request reaches the producer:

JSON

Failure semantics

Transformation is mutate-only: the filter never blocks a message because a rule failed. Whatever the phase, a rule that errors is logged and skipped, and the message continues with whatever changes earlier rules applied.

  • Request phase: the request-phase filter always allows the request through. A bad action (for example a body action whose field path does not resolve) is logged and skipped; if the body cannot be re-serialized after edits, it is left unchanged.
  • Response phase (SBI): a rule that errors is logged and skipped, and the producer's answer is forwarded to the consumer.
  • Response phase (Diameter): AVP-action errors are logged; the answer is sent to the consumer with whatever AVP edits succeeded.

Because transformation failures surface as structured logs rather than blocked traffic, watch the decision logs (and the transformation metrics) for a rule that starts erroring after a deploy. See Request pipeline for how the filter chain handles allow/deny decisions overall.