Cuando cada módulo tiene su propio lenguaje, la complejidad operacional crece con la plataforma.
La gestión de tráfico empresarial ya no son solo reglas de balanceo de carga. Dentro de la misma plataforma, el enrutamiento de tráfico, la comprobación de salud, el enriquecimiento de logs, las decisiones GTM, el scoring de seguridad, la política de captcha, la ACL y el contexto de acceso se ejecutan todos juntos. El problema es que la mayoría de los productos gestionan estos módulos con lenguajes de expresión separados, nombres de variables separados y comportamientos de error separados.
Esa fragmentación obliga a los operadores a cambiar de contexto mental constantemente. El mismo valor se escribe de forma diferente en un módulo respecto a otro — el país del cliente, la IP de origen, la ruta de la solicitud, el claim JWT o el score WAAP se manejan todos por una lógica separada en cada lugar. El resultado es un mayor coste de aprendizaje, una multiplicación de duplicación de reglas y ciclos de depuración más largos.
Más peligroso es cuando la misma regla de negocio se interpreta de forma diferente entre módulos. Si la condición de comprobación de salud diverge de la condición de enrutamiento, el sistema puede marcar un servicio como saludable mientras una ruta lógica separada descarta el tráfico hacia ese mismo servicio. Cuando el lado del log registra el mismo contexto de forma incompleta, la investigación post-incidente también se resiente.
El enfoque correcto es convertir un único lenguaje de expresión en la capa de decisión compartida. Ese lenguaje debe definir funciones, variables, comprobación de tipos y alcance de uso de forma centralizada, de modo que cada módulo consuma el mismo árbol de expresiones dentro de su propio contexto operacional.
El Motor FX de TR7 satisface esta necesidad: unifica la lógica de decisión dispersa entre módulos bajo un único lenguaje de expresión, un único catálogo de variables y un modelo de validación previo al registro.
Nuestro enfoque
En lugar de dividir la lógica de decisión en sintaxis separadas por módulo, TR7 compila y evalúa todo a través de un árbol de expresiones FX compartido.
El catálogo de funciones y variables se define de forma centralizada
El motor FX expone 41 funciones integradas y 173 variables organizadas en 14 grupos. Los contextos de conexión, headers HTTP, cuerpo, SSL, temporizadores, estadísticas, WAAP y AAM se seleccionan todos del mismo catálogo.
Las expresiones se compilan a una cadena nativa de sample-fetch y conversor
Las funciones que pueden manejarse de forma nativa se ejecutan directamente como una cadena de alta performance de sample-fetch y conversor. Por ejemplo, un campo JSON del cuerpo de la solicitud puede leerse, normalizarse con un transformador de texto y vincularse a un único resultado de expresión.
Las funciones no nativas se compilan a acciones Lua
Las funciones que requieren XPath XML, consultas JWT complejas o procesamiento personalizado se emiten como acciones basadas en Lua. El lenguaje FX permanece unificado; la ruta de runtime se elige en función de lo que necesita la función.
El mismo motor de expresiones es consumido por todos los módulos
Las reglas de tráfico, las comprobaciones de salud, los formatos de log, los disparadores GTM, la política de captcha y la ACL comparten el mismo modelo de funciones y variables. Esta comunalidad reduce la necesidad de que los operadores aprendan un nuevo lenguaje de decisión para cada módulo.
Capacidades
El Motor de Expresiones y Variables FX convierte las variables y funciones de toda la plataforma en un modelo dirigido por esquema, validable y compilable.
173 variables en 14 grupos cubren el contexto de tráfico y seguridad
El catálogo de variables FX está organizado en grupos de conexión, headers HTTP, cuerpo, cliente, línea de solicitud, línea de respuesta, SSL, estadísticas, temporizador, tracking, WAAP, AAM, VarBuilder y otros. Los operadores seleccionan la IP de origen, el puerto de destino, la ruta de solicitud, el estado de respuesta, el SNI, los detalles del certificado, el score WAAP, el rol de usuario AAM o las variables personalizadas del mismo modelo. Esto evita que el mismo contexto se escriba bajo diferentes nombres en diferentes módulos, haciendo el lenguaje de reglas más consistente, más legible y menos propenso a errores.
41 funciones van desde la transformación de texto hasta las consultas JSON y XML
El catálogo de funciones cubre grupos de conversor, matemáticas, XML, JSON, JWT, IP, cadena, hash, FIX, MQTT, map/list, parámetro y selección condicional. JSONQUERY, XMLQUERY, JWTHEADER, JWTPAYLOAD, PARAM, DIGEST, LOWERCASE, STRREPLACEALL, MAP_STR, LIST_REG y TERNARY pueden componerse todos dentro de una única expresión. Los operadores usan el mismo modelo FX para transformaciones de texto simples y para consultas profundas de campos del cuerpo por igual, alejando la creación de reglas de la codificación ad hoc hacia una definición de política manejable.
La ruta de compilación nativa se usa para expresiones de baja latencia
Las variables y funciones con soporte nativo se compilan directamente en una cadena de sample-fetch y conversor. Esta ruta es adecuada para decisiones frecuentemente necesarias como lecturas de headers, coincidencia de rutas, transformación de texto, búsquedas en map y ciertas consultas del cuerpo. Dado que no hay una capa de interpretación intermedia involucrada, el rendimiento se mantiene predecible. Las reglas de tráfico se traducen a la ruta de ejecución más eficiente de la plataforma siempre que sea posible.
La ruta de compilación Lua cubre las funciones complejas y personalizadas
Los controles que no pueden expresarse a través de la cadena nativa se ejecutan como acciones Lua. Las consultas XPath XML, las comprobaciones JWT personalizadas y el procesamiento condicional complejo se soportan todos de esta manera. El lenguaje de expresión no cambia desde la perspectiva del operador — el sistema selecciona la ruta de ejecución correcta en segundo plano. Esta separación combina una ruta nativa de alto rendimiento y una ruta Lua flexible en una única experiencia FX.
La comprobación de tipos rechaza las expresiones inválidas antes de que se guarden
Cada argumento de función se define con un tipo — integer, string, jsonPath, xmlPath, hash o smartInput. La UI y la capa de gestión validan estos tipos en el momento de guardar. El tipo de argumento incorrecto, el parámetro faltante o el uso anidado incompatible se detectan antes de llegar al runtime, reduciendo los fallos de reglas inesperados en el tráfico de producción.
El alcance de uso se filtra por módulo y contexto
Cada variable lleva metadatos que describen en qué módulos, tipos de condición y fases de tráfico puede usarse. Algunas variables son válidas solo en la fase de respuesta; otras aparecen solo en plantillas de log o tipos de condición específicos. La UI usa esta información para presentar opciones apropiadas al contexto al operador, evitando que variables inválidas se coloquen en la posición incorrecta.
VarBuilder permite a los operadores crear sus propias variables calculadas
El grupo VarBuilder permite a los operadores producir variables personalizadas que se calculan en tiempo de ejecución. Un valor se calcula a través de una expresión FX, se almacena dentro del alcance de la transacción y se reutiliza en las reglas siguientes. Este modelo reduce la necesidad de reescribir el mismo cálculo en múltiples lugares. En flujos complejos, la lógica de decisión se vuelve más modular y trazable.
El autocompletado se alimenta de datos de esquema para acelerar la creación
La consola FX obtiene la información de función, variable, argumento y alcance del esquema central. A medida que el operador escribe un nombre de función o variable, se sugieren las opciones apropiadas; los argumentos que aceptan valores vacíos y las funciones que requieren paréntesis son guiados correctamente por la UI. Esto reduce la curva de aprendizaje para los nuevos usuarios y permite a los operadores experimentados crear reglas más rápido. Las expresiones se vuelven más correctas antes de llegar siquiera al paso de guardado.
Profundidad operacional
El motor FX está diseñado con validación, aplicación del alcance, auditoría, rendimiento y comportamiento en casos extremos en mente — no solo con la experiencia de creación de expresiones.
Validación de argumentos
La lista de argumentos esperados y los tipos para cada función se mantienen en la definición central. Tanto la UI como la capa de gestión comprueban esta información de forma independiente. Como resultado, las expresiones inválidas se rechazan no solo en pantalla sino también en el punto de guardado.
Alcance de fase de respuesta
Algunas variables son significativas solo en la fase de respuesta. Estas variables se marcan en los metadatos y se bloquea su uso en las condiciones de la fase de solicitud. Esta distinción reduce los errores de runtime causados por desajustes de fase.
Alias de variables ocultos
Algunas variables se mantienen en el sistema por compatibilidad hacia atrás o uso interno pero no se exponen en la UI. Esto permite a la plataforma seguir ejecutando expresiones más antiguas mientras presenta a los operadores una lista de variables limpia y precisa. El catálogo visible y el uso interno se mantienen separados.
Carga del conversor Lua
Funciones como XMLQUERY, XMLPATHTYPE y XMLPATHEXISTS dependen de componentes del conversor Lua. Estos componentes se cargan cuando el servicio se inicia y son consumidos por las funciones FX relevantes. Los estados de conversor faltantes deben detectarse durante los procesos de despliegue y comprobación de salud.
Auditoría y versionado
Cada árbol de expresiones debe ser trazable con un historial de cambios. Quién cambió qué expresión y cuándo es información crítica para las operaciones y las revisiones de seguridad. Estos registros proporcionan capacidad de reversión y seguimiento de responsabilidad, especialmente para las reglas que afectan al comportamiento del tráfico.
Advertencias de rendimiento de regex
STRREPLACEALL y ciertas comprobaciones basadas en regex pueden producir un alto coste de procesamiento si se escriben descuidadamente. Los patrones con mucho backtracking pueden suponer tanto riesgos de seguridad como de rendimiento. La UI debe advertir a los operadores en estos casos y fomentar una creación de patrones más segura.
Cuándo usarlo
Expresión compartida en comprobaciones de salud y reglas de tráfico
Los equipos SaaS pueden usar la misma expresión FX — como `$.status == "OK"` en el cuerpo de respuesta — tanto en la comprobación de salud como en la regla de enrutamiento de tráfico. Dado que el mismo estado del servicio no se escribe de forma diferente en cada módulo, la consistencia operacional mejora.
Enriquecimiento de logs con claims JWT
Los equipos SOC pueden añadir la dirección de correo electrónico del usuario, el rol o la información de tenant al formato de log a través de JWTPAYLOAD. La investigación de incidentes va más allá de los datos de IP y URL en bruto, haciendo visible el contexto del usuario en cada entrada de log.
Activación basada en geo y ASN en decisiones GTM
Los equipos de servicios globales pueden evaluar datos de país, ASN o latencia a través de expresiones FX al seleccionar una respuesta DNS. La misma lógica puede reutilizarse en una regla de enrutamiento de tráfico cuando sea necesario.
Enrutamiento A/B controlado basado en hash
Los equipos de e-commerce pueden desviar un porcentaje definido del tráfico a una nueva variante basándose en un hash derivado del identificador del usuario. La distribución es determinista — el mismo usuario siempre se dirige a la misma experiencia en cada solicitud.
Preguntas frecuentes
¿Cuántas funciones y variables proporciona el motor FX?
¿Qué módulos comparten el mismo lenguaje de expresión FX?
¿Cómo funciona la comprobación de tipos previa al registro?
¿Cuál es la diferencia entre la ruta de compilación nativa y la ruta Lua?
¿Para qué puede usarse VarBuilder?
¿Cómo se aplica el alcance de las variables?
Unifique las decisiones de la plataforma en un único lenguaje de expresión
Gestione reglas de tráfico, comprobaciones de salud, logs, GTM y decisiones de seguridad a través del mismo modelo FX. Permítanos guiarle por una configuración en vivo en su propio entorno.