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