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.
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 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 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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.