Enterprise traffic management is no longer just load-balancing rules. Inside the same platform, traffic routing, health checking, log enrichment, GTM decisions, security scoring, captcha policy, ACL and access context all run together. The problem is that most products manage these modules with separate expression languages, separate variable names and separate error behaviors.
That fragmentation forces operators to switch mental context constantly. The same value is written differently in one module versus another — client country, source IP, request path, JWT claim or WAAP score are all handled by separate logic in each place. The result is higher learning cost, multiplied rule duplication and longer debug cycles.
More dangerous is when the same business rule is interpreted differently across modules. If the health-check condition diverges from the routing condition, the system can mark a service healthy while a separate logic path drops traffic to that same service. When the log side records the same context incompletely, post-incident investigation suffers as well.
The right approach is to make a single expression language the shared decision layer. That language should define functions, variables, type checking and usage scope centrally, so that every module consumes the same expression tree within its own operational context.
The TR7 FX Engine meets this need: it unifies decision logic scattered across modules under a single expression language, a single variable catalog and a pre-registration validation model.
Instead of splitting decision logic into separate per-module syntaxes, TR7 compiles and evaluates everything through a shared FX expression tree.
The FX engine exposes 41 built-in functions and 173 variables organized in 14 groups. Connection, HTTP headers, body, SSL, timers, statistics, WAAP and AAM contexts are all selected from the same catalog.
Functions that can be handled natively run directly as a high-performance sample-fetch and converter chain. For example, a JSON field from the request body can be read, normalized with a text transformer and bound to a single expression result.
Functions requiring XML XPath, complex JWT queries or custom processing are emitted as Lua-based actions. The FX language stays unified; the runtime path is chosen based on what the function needs.
Traffic rules, health checks, log formats, GTM triggers, captcha policy and ACL all share the same function and variable model. This commonality reduces the need for operators to learn a new decision language for each module.
The FX Expression and Variable Engine turns platform-wide variables and functions into a schema-driven, validatable and compilable model.
The FX variable catalog is organized into connection, HTTP headers, body, client, request line, response line, SSL, statistics, timer, tracking, WAAP, AAM, VarBuilder and other groups. Operators select source IP, destination port, request path, response status, SNI, certificate details, WAAP score, AAM user role or custom variables from the same model. This prevents the same context from being written under different names in different modules, making rule language more consistent, more readable and less error-prone.
The function catalog covers converter, math, XML, JSON, JWT, IP, string, hash, FIX, MQTT, map/list, parameter and conditional selection groups. JSONQUERY, XMLQUERY, JWTHEADER, JWTPAYLOAD, PARAM, DIGEST, LOWERCASE, STRREPLACEALL, MAP_STR, LIST_REG and TERNARY can all be composed within a single expression. Operators use the same FX model for simple text transformations and for deep body field queries alike, moving rule authoring away from ad-hoc coding toward manageable policy definition.
Variables and functions with native support compile directly into a sample-fetch and converter chain. This path is suited to frequently needed decisions such as header reads, path matching, text transformation, map lookups and certain body queries. Because no intermediate interpretation layer is involved, performance remains predictable. Traffic rules are translated to the platform's most efficient execution path whenever possible.
Controls that cannot be expressed through the native chain run as Lua actions. XML XPath queries, custom JWT checks and complex conditional processing are all supported this way. The expression language does not change from the operator's perspective — the system selects the correct execution path in the background. This separation combines a performant native path and a flexible Lua path in a single FX experience.
Every function argument is defined with a type — integer, string, jsonPath, xmlPath, hash or smartInput. The UI and management layer validate these types at save time. Wrong argument type, missing parameter or incompatible nested usage is caught before reaching the runtime, reducing unexpected rule failures in production traffic.
Each variable carries metadata describing which modules, condition types and traffic phases it can be used in. Some variables are valid only in the response phase; others appear only in log templates or specific condition types. The UI uses this information to present context-appropriate options to the operator, preventing invalid variables from being placed in the wrong position.
The VarBuilder group enables operators to produce custom variables that are computed at runtime. A value is calculated through an FX expression, stored within the transaction scope and reused in subsequent rules. This model reduces the need to rewrite the same calculation in multiple places. In complex flows, decision logic becomes more modular and traceable.
The FX console draws function, variable, argument and scope information from the central schema. As the operator types a function name or variable, the appropriate options are suggested; arguments that accept empty values and functions requiring parentheses are guided correctly by the UI. This reduces the learning curve for new users and allows experienced operators to author rules faster. Expressions become more correct before they even reach the save step.
The FX engine is designed with validation, scope enforcement, audit, performance and edge-case behavior in mind — not just the expression authoring experience.
The expected argument list and types for each function are kept in the central definition. Both the UI and the management layer check this information independently. As a result, invalid expressions are rejected not just on screen but also at the point of save.
Some variables are meaningful only in the response phase. These variables are flagged in metadata and blocked from use in request-phase conditions. This distinction reduces runtime errors caused by phase mismatches.
Some variables are kept in the system for backward compatibility or internal use but are not exposed in the UI. This allows the platform to continue running older expressions while presenting operators with a clean and accurate variable list. The visible catalog and internal use are kept separate.
Functions such as XMLQUERY, XMLPATHTYPE and XMLPATHEXISTS depend on Lua converter components. These components are loaded when the service starts and are consumed by the relevant FX functions. Missing converter states should be caught during deployment and health-check processes.
Every expression tree should be traceable with a change history. Who changed which expression and when is critical information for operations and security reviews. These records provide rollback capability and accountability tracking, especially for rules that affect traffic behavior.
STRREPLACEALL and certain regex-based checks can produce high processing cost if written carelessly. Backtracking-heavy patterns can pose both security and performance risks. The UI should warn operators in these cases and encourage safer pattern authoring.
SaaS teams can use the same FX expression — such as `$.status == "OK"` in the response body — in both the health check and the traffic routing rule. Because the same service state is not written differently in each module, operational consistency improves.
SOC teams can add user email address, role or tenant information to the log format via JWTPAYLOAD. Incident investigation goes beyond raw IP and URL data, making user context visible in every log entry.
Global service teams can evaluate country, ASN or latency data through FX expressions when selecting a DNS response. The same logic can be reused in a traffic routing rule whenever needed.
E-commerce teams can shift a defined percentage of traffic to a new variant based on a hash derived from the user identifier. Distribution is deterministic — the same user is always directed to the same experience on every request.
Manage traffic rules, health checks, logs, GTM and security decisions through the same FX model. Let's walk through a live setup in your own environment.