Lorsque chaque module a son propre langage, la complexité opérationnelle croît avec la plateforme.
La gestion de trafic en entreprise n'est plus seulement une question de règles d'équilibrage de charge. Au sein de la même plateforme, le routage de trafic, les contrôles de santé, l'enrichissement des journaux, les décisions GTM, le scoring de sécurité, la politique captcha, les ACL et le contexte d'accès fonctionnent tous ensemble. Le problème est que la plupart des produits gèrent ces modules avec des langages d'expression séparés, des noms de variables séparés et des comportements d'erreur séparés.
Cette fragmentation force les opérateurs à changer constamment de contexte mental. La même valeur est écrite différemment dans un module par rapport à un autre — le pays client, l'IP source, le chemin de requête, le JWT claim ou le score WAAP sont tous traités par une logique séparée dans chaque endroit. Le résultat est un coût d'apprentissage plus élevé, une duplication des règles multipliée et des cycles de débogage plus longs.
Plus dangereux encore est le fait que la même règle métier soit interprétée différemment entre les modules. Si la condition de contrôle de santé diverge de la condition de routage, le système peut marquer un service comme sain pendant qu'un chemin logique séparé abandonne le trafic vers ce même service. Lorsque le côté journal enregistre le même contexte de manière incomplète, l'investigation post-incident en souffre également.
La bonne approche consiste à faire d'un seul langage d'expression la couche de décision partagée. Ce langage doit définir les fonctions, les variables, la vérification de type et la portée d'utilisation de manière centralisée, de sorte que chaque module consomme le même arbre d'expression dans son propre contexte opérationnel.
Le Moteur FX de TR7 répond à ce besoin : il unifie la logique de décision dispersée entre les modules sous un seul langage d'expression, un seul catalogue de variables et un modèle de validation pré-enregistrement.
Notre approche
Au lieu de diviser la logique de décision en syntaxes séparées par module, TR7 compile et évalue tout via un arbre d'expression FX partagé.
Catalogue de fonctions et de variables défini de manière centralisée
Le moteur FX expose 41 fonctions intégrées et 173 variables organisées en 14 groupes. Les contextes connexion, headers HTTP, corps, SSL, minuteries, statistiques, WAAP et AAM sont tous sélectionnés depuis le même catalogue.
Les expressions se compilent en une chaîne native de sample-fetch et convertisseur
Les fonctions qui peuvent être gérées nativement s'exécutent directement comme une chaîne haute performance de sample-fetch et convertisseur. Par exemple, un champ JSON du corps de requête peut être lu, normalisé avec un transformateur de texte et lié à un résultat d'expression unique.
Les fonctions non natives se compilent en actions Lua
Les fonctions nécessitant XPath XML, des requêtes JWT complexes ou un traitement personnalisé sont émises comme actions Lua. Le langage FX reste unifié ; le chemin d'exécution est choisi en fonction de ce dont la fonction a besoin.
Le même moteur d'expression est consommé par chaque module
Les règles de trafic, les contrôles de santé, les formats de journaux, les déclencheurs GTM, la politique captcha et les ACL partagent tous le même modèle de fonctions et de variables. Cette commonalité réduit le besoin pour les opérateurs d'apprendre un nouveau langage de décision pour chaque module.
Capacités
Le Moteur d'Expression et de Variables FX transforme les variables et fonctions à l'échelle de la plateforme en un modèle piloté par schéma, validable et compilable.
173 variables sur 14 groupes couvrent le contexte trafic et sécurité
Le catalogue de variables FX est organisé en connexion, headers HTTP, corps, client, ligne de requête, ligne de réponse, SSL, statistiques, minuterie, tracking, WAAP, AAM, VarBuilder et autres groupes. Les opérateurs sélectionnent l'IP source, le port destination, le chemin de requête, le statut de réponse, le SNI, les détails du certificat, le score WAAP, le rôle utilisateur AAM ou des variables personnalisées depuis le même modèle. Cela évite que le même contexte soit écrit sous des noms différents dans différents modules, rendant le langage de règles plus cohérent, plus lisible et moins sujet aux erreurs.
41 fonctions couvrent de la transformation de texte aux requêtes JSON et XML
Le catalogue de fonctions couvre les groupes convertisseur, mathématique, XML, JSON, JWT, IP, chaîne, hash, FIX, MQTT, map/liste, paramètre et sélection conditionnelle. JSONQUERY, XMLQUERY, JWTHEADER, JWTPAYLOAD, PARAM, DIGEST, LOWERCASE, STRREPLACEALL, MAP_STR, LIST_REG et TERNARY peuvent tous être composés dans une seule expression. Les opérateurs utilisent le même modèle FX pour les simples transformations de texte et les requêtes profondes sur les champs du corps, faisant passer la rédaction de règles d'un codage ad hoc vers une définition de politique gérable.
Le chemin de compilation natif est utilisé pour les expressions à faible latence
Les variables et fonctions avec support natif se compilent directement en une chaîne de sample-fetch et convertisseur. Ce chemin convient aux décisions fréquemment nécessaires telles que les lectures de headers, la correspondance de chemins, la transformation de texte, les recherches par map et certaines requêtes du corps. Parce qu'aucune couche d'interprétation intermédiaire n'est impliquée, les performances restent prévisibles. Les règles de trafic sont traduites vers le chemin d'exécution le plus efficace de la plateforme chaque fois que possible.
Le chemin de compilation Lua couvre les fonctions complexes et personnalisées
Les contrôles qui ne peuvent pas être exprimés via la chaîne native s'exécutent comme actions Lua. Les requêtes XPath XML, les vérifications JWT personnalisées et le traitement conditionnel complexe sont tous pris en charge de cette manière. Le langage d'expression ne change pas du point de vue de l'opérateur — le système sélectionne le chemin d'exécution correct en arrière-plan. Cette séparation combine un chemin natif performant et un chemin Lua flexible dans une seule expérience FX.
La vérification de type rejette les expressions invalides avant leur sauvegarde
Chaque argument de fonction est défini avec un type — entier, chaîne, jsonPath, xmlPath, hash ou smartInput. L'interface et la couche de gestion valident ces types lors de la sauvegarde. Un type d'argument incorrect, un paramètre manquant ou une utilisation imbriquée incompatible est capturé avant d'atteindre l'exécution, réduisant les échecs de règles inattendus dans le trafic de production.
La portée d'utilisation est filtrée par module et contexte
Chaque variable porte des métadonnées décrivant dans quels modules, types de conditions et phases de trafic elle peut être utilisée. Certaines variables ne sont valides que dans la phase de réponse ; d'autres n'apparaissent que dans les modèles de journaux ou des types de conditions spécifiques. L'interface utilise ces informations pour présenter des options adaptées au contexte à l'opérateur, empêchant les variables invalides d'être placées au mauvais endroit.
VarBuilder permet aux opérateurs de créer leurs propres variables calculées
Le groupe VarBuilder permet aux opérateurs de produire des variables personnalisées calculées à l'exécution. Une valeur est calculée via une expression FX, stockée dans la portée de la transaction et réutilisée dans les règles suivantes. Ce modèle réduit le besoin de réécrire le même calcul à plusieurs endroits. Dans les flux complexes, la logique de décision devient plus modulaire et traçable.
L'auto-complétion est alimentée par les données de schéma pour accélérer la rédaction
La console FX extrait les informations de fonction, variable, argument et portée depuis le schéma central. Lorsque l'opérateur tape un nom de fonction ou de variable, les options appropriées sont suggérées ; les arguments qui acceptent des valeurs vides et les fonctions nécessitant des parenthèses sont guidés correctement par l'interface. Cela réduit la courbe d'apprentissage pour les nouveaux utilisateurs et permet aux opérateurs expérimentés de rédiger des règles plus rapidement. Les expressions deviennent plus correctes avant même d'atteindre l'étape de sauvegarde.
Profondeur opérationnelle
Le moteur FX est conçu avec la validation, l'application de portée, l'audit, les performances et les comportements aux cas limites à l'esprit — pas seulement l'expérience de rédaction d'expressions.
Validation des arguments
La liste d'arguments attendus et les types pour chaque fonction sont conservés dans la définition centrale. L'interface et la couche de gestion vérifient ces informations indépendamment. En conséquence, les expressions invalides sont rejetées non seulement à l'écran mais aussi au point de sauvegarde.
Portée de la phase de réponse
Certaines variables ne sont significatives que dans la phase de réponse. Ces variables sont signalées dans les métadonnées et bloquées de l'utilisation dans les conditions de la phase de requête. Cette distinction réduit les erreurs d'exécution causées par des inadéquations de phase.
Alias de variables cachés
Certaines variables sont conservées dans le système pour la compatibilité ascendante ou l'usage interne mais ne sont pas exposées dans l'interface. Cela permet à la plateforme de continuer à exécuter d'anciennes expressions tout en présentant aux opérateurs une liste de variables propre et précise. Le catalogue visible et l'usage interne sont maintenus séparés.
Chargement du convertisseur Lua
Des fonctions telles que XMLQUERY, XMLPATHTYPE et XMLPATHEXISTS dépendent de composants de convertisseur Lua. Ces composants sont chargés au démarrage du service et sont consommés par les fonctions FX concernées. Les états de convertisseur manquants doivent être détectés lors des processus de déploiement et de contrôle de santé.
Audit et versionnage
Chaque arbre d'expression doit être traçable avec un historique des modifications. Qui a changé quelle expression et quand est une information critique pour les opérations et les revues de sécurité. Ces enregistrements fournissent une capacité de rollback et un suivi des responsabilités, notamment pour les règles qui affectent le comportement du trafic.
Avertissements de performance regex
STRREPLACEALL et certaines vérifications basées sur des regex peuvent produire un coût de traitement élevé si elles sont écrites avec négligence. Les patterns à forte backtracking peuvent poser des risques à la fois de sécurité et de performance. L'interface devrait avertir les opérateurs dans ces cas et encourager une rédaction de patterns plus sûre.
Quand l'utiliser
Expression partagée dans les contrôles de santé et les règles de trafic
Les équipes SaaS peuvent utiliser la même expression FX — telle que `$.status == "OK"` dans le corps de réponse — à la fois dans le contrôle de santé et dans la règle de routage de trafic. Parce que le même état de service n'est pas écrit différemment dans chaque module, la cohérence opérationnelle s'améliore.
Enrichissement des journaux avec les JWT claims
Les équipes SOC peuvent ajouter l'adresse e-mail de l'utilisateur, le rôle ou les informations du tenant au format de journal via JWTPAYLOAD. L'investigation des incidents va au-delà des données brutes d'IP et d'URL, rendant le contexte utilisateur visible dans chaque entrée de journal.
Déclenchement basé sur le géo et l'ASN dans les décisions GTM
Les équipes de services globaux peuvent évaluer les données de pays, ASN ou latence via des expressions FX lors de la sélection d'une réponse DNS. La même logique peut être réutilisée dans une règle de routage de trafic chaque fois que nécessaire.
Routage A/B contrôlé basé sur un hash
Les équipes e-commerce peuvent orienter un pourcentage défini du trafic vers une nouvelle variante basée sur un hash dérivé de l'identifiant utilisateur. La distribution est déterministe — le même utilisateur est toujours dirigé vers la même expérience à chaque requête.
Questions fréquentes
Combien de fonctions et de variables le moteur FX fournit-il ?
Quels modules partagent le même langage d'expression FX ?
Comment fonctionne la vérification de type pré-enregistrement ?
Quelle est la différence entre le chemin de compilation natif et le chemin Lua ?
À quoi VarBuilder peut-il être utilisé ?
Comment la portée des variables est-elle appliquée ?
Unifiez les décisions de la plateforme dans un seul langage d'expression
Gérez les règles de trafic, les contrôles de santé, les journaux, GTM et les décisions de sécurité via le même modèle FX. Laissez-nous parcourir une mise en place en direct dans votre propre environnement.