Enterprise-Verkehrsverwaltung ist nicht mehr nur Load-Balancing-Regeln. Innerhalb derselben Plattform laufen Verkehrsweiterleitung, Gesundheitsprüfung, Log-Anreicherung, GTM-Entscheidungen, Sicherheits-Scoring, Captcha-Richtlinie, ACL und Zugriffskontext alle zusammen. Das Problem ist, dass die meisten Produkte diese Module mit separaten Ausdruckssprachen, separaten Variablennamen und separatem Fehlerverhalten verwalten.
Diese Fragmentierung zwingt Operatoren, ständig den mentalen Kontext zu wechseln. Derselbe Wert wird in einem Modul anders geschrieben als in einem anderen — Client-Land, Quell-IP, Anfragepfad, JWT-Claim oder WAAP-Score werden in jedem Bereich durch separate Logik verarbeitet. Das Ergebnis sind höhere Lernkosten, multiplizierte Regelduplizierung und längere Debug-Zyklen.
Noch gefährlicher ist es, wenn dieselbe Geschäftsregel in verschiedenen Modulen unterschiedlich interpretiert wird. Wenn die Gesundheitsprüfungsbedingung von der Routingbedingung abweicht, kann das System einen Dienst als gesund markieren, während ein separater Logikpfad den Verkehr zu demselben Dienst abbricht. Wenn die Log-Seite denselben Kontext unvollständig aufzeichnet, leidet auch die Untersuchung nach einem Vorfall.
Der richtige Ansatz ist, eine einzige Ausdruckssprache zur gemeinsamen Entscheidungsschicht zu machen. Diese Sprache sollte Funktionen, Variablen, Typprüfung und Verwendungsbereich zentral definieren, sodass jedes Modul denselben Ausdrucksbaum in seinem eigenen operativen Kontext verwendet.
Die TR7 FX-Engine erfüllt diesen Bedarf: Sie vereinheitlicht über Module verteilte Entscheidungslogik unter einer einzigen Ausdruckssprache, einem einzigen Variablenkatalog und einem Vorab-Registrierungsvalidierungsmodell.
Anstatt Entscheidungslogik in separate modulbezogene Syntaxen aufzuteilen, kompiliert und evaluiert TR7 alles durch einen gemeinsamen FX-Ausdrucksbaum.
Die FX-Engine stellt 41 integrierte Funktionen und 173 Variablen bereit, die in 14 Gruppen organisiert sind. Verbindungs-, HTTP-Header-, Body-, SSL-, Timer-, Statistik-, WAAP- und AAM-Kontexte werden alle aus demselben Katalog ausgewählt.
Funktionen, die nativ verarbeitet werden können, laufen direkt als hochperformante Sample-Fetch- und Converter-Kette. Beispielsweise kann ein JSON-Feld aus dem Anfrage-Body gelesen, mit einem Texttransformator normalisiert und an ein einzelnes Ausdrucksergebnis gebunden werden.
Funktionen, die XML XPath, komplexe JWT-Abfragen oder benutzerdefinierte Verarbeitung erfordern, werden als Lua-basierte Aktionen emittiert. Die FX-Sprache bleibt einheitlich; der Laufzeitpfad wird basierend auf dem Bedarf der Funktion gewählt.
Verkehrsregeln, Gesundheitsprüfungen, Log-Formate, GTM-Trigger, Captcha-Richtlinie und ACL teilen alle dasselbe Funktions- und Variablenmodell. Diese Gemeinsamkeit reduziert die Notwendigkeit, für jedes Modul eine neue Entscheidungssprache zu erlernen.
Die FX-Ausdrucks- und Variablen-Engine wandelt plattformweite Variablen und Funktionen in ein schemagesteuert, validierbares und kompilierbares Modell um.
Der FX-Variablenkatalog ist in Verbindungs-, HTTP-Header-, Body-, Client-, Anfrageleitungs-, Antwortleitungs-, SSL-, Statistik-, Timer-, Tracking-, WAAP-, AAM-, VarBuilder- und weitere Gruppen organisiert. Operatoren wählen Quell-IP, Zielport, Anfragepfad, Antwortstatus, SNI, Zertifikatdetails, WAAP-Score, AAM-Benutzerrolle oder benutzerdefinierte Variablen aus demselben Modell. Dies verhindert, dass derselbe Kontext unter verschiedenen Namen in verschiedenen Modulen geschrieben wird, wodurch die Regelsprache konsistenter, lesbarer und weniger fehleranfällig wird.
Der Funktionskatalog umfasst Converter-, Mathematik-, XML-, JSON-, JWT-, IP-, String-, Hash-, FIX-, MQTT-, Map/List-, Parameter- und Bedingungsauswahlgruppen. JSONQUERY, XMLQUERY, JWTHEADER, JWTPAYLOAD, PARAM, DIGEST, LOWERCASE, STRREPLACEALL, MAP_STR, LIST_REG und TERNARY können alle innerhalb eines einzigen Ausdrucks kombiniert werden. Operatoren verwenden dasselbe FX-Modell sowohl für einfache Texttransformationen als auch für tiefe Body-Feldabfragen und bewegen das Regel-Authoring weg von Ad-hoc-Coding hin zu überschaubarer Richtliniendefinition.
Variablen und Funktionen mit nativer Unterstützung werden direkt in eine Sample-Fetch- und Converter-Kette kompiliert. Dieser Pfad ist für häufig benötigte Entscheidungen wie Header-Lesevorgänge, Pfadabgleiche, Texttransformationen, Map-Lookups und bestimmte Body-Abfragen geeignet. Da keine Zwischen-Interpretationsschicht einbezogen ist, bleibt die Leistung vorhersehbar. Verkehrsregeln werden wann immer möglich in den effizientesten Ausführungspfad der Plattform übersetzt.
Kontrollen, die nicht durch die native Kette ausgedrückt werden können, laufen als Lua-Aktionen. XML XPath-Abfragen, benutzerdefinierte JWT-Prüfungen und komplexe bedingte Verarbeitung werden alle auf diese Weise unterstützt. Die Ausdruckssprache ändert sich aus der Perspektive des Operators nicht — das System wählt den korrekten Ausführungspfad im Hintergrund. Diese Trennung kombiniert einen leistungsstarken nativen Pfad und einen flexiblen Lua-Pfad in einer einzigen FX-Erfahrung.
Jedes Funktionsargument wird mit einem Typ definiert — Integer, String, jsonPath, xmlPath, Hash oder smartInput. Die Benutzeroberfläche und die Verwaltungsschicht validieren diese Typen zum Speicherzeitpunkt. Falscher Argumenttyp, fehlender Parameter oder inkompatibler verschachtelter Gebrauch wird abgefangen, bevor die Laufzeit erreicht wird, wodurch unerwartete Regelfehler im Produktionsverkehr reduziert werden.
Jede Variable trägt Metadaten, die beschreiben, in welchen Modulen, Bedingungstypen und Verkehrsphasen sie verwendet werden kann. Einige Variablen sind nur in der Response-Phase gültig; andere erscheinen nur in Log-Templates oder bestimmten Bedingungstypen. Die Benutzeroberfläche verwendet diese Informationen, um dem Operator kontextgerechte Optionen anzuzeigen und zu verhindern, dass ungültige Variablen an der falschen Stelle platziert werden.
Die VarBuilder-Gruppe ermöglicht es Operatoren, benutzerdefinierte Variablen zu erstellen, die zur Laufzeit berechnet werden. Ein Wert wird durch einen FX-Ausdruck berechnet, innerhalb des Transaktionsbereichs gespeichert und in nachfolgenden Regeln wiederverwendet. Dieses Modell reduziert die Notwendigkeit, dieselbe Berechnung an mehreren Stellen neu zu schreiben. In komplexen Abläufen wird die Entscheidungslogik modularer und nachverfolgbarer.
Die FX-Konsole bezieht Funktions-, Variablen-, Argument- und Bereichsinformationen aus dem zentralen Schema. Wenn der Operator einen Funktionsnamen oder eine Variable eingibt, werden geeignete Optionen vorgeschlagen; Argumente, die leere Werte akzeptieren, und Funktionen, die Klammern erfordern, werden von der Benutzeroberfläche korrekt geführt. Dies reduziert die Lernkurve für neue Benutzer und ermöglicht erfahrenen Operatoren, Regeln schneller zu erstellen. Ausdrücke werden korrekter, noch bevor sie den Speicherschritt erreichen.
Die FX-Engine ist mit Validierung, Bereichsdurchsetzung, Audit, Leistung und Edge-Case-Verhalten konzipiert — nicht nur mit der Authoring-Erfahrung für Ausdrücke.
Die erwartete Argumentliste und die Typen für jede Funktion werden in der zentralen Definition gespeichert. Sowohl die Benutzeroberfläche als auch die Verwaltungsschicht prüfen diese Informationen unabhängig voneinander. Dadurch werden ungültige Ausdrücke nicht nur auf dem Bildschirm, sondern auch beim Speichern abgelehnt.
Einige Variablen sind nur in der Response-Phase sinnvoll. Diese Variablen werden in den Metadaten gekennzeichnet und von der Verwendung in Anfragephasen-Bedingungen ausgeschlossen. Diese Unterscheidung reduziert Laufzeitfehler, die durch Phasen-Fehlanpassungen verursacht werden.
Einige Variablen werden im System für die Abwärtskompatibilität oder den internen Gebrauch vorgehalten, sind aber nicht in der Benutzeroberfläche verfügbar. Dies ermöglicht es der Plattform, ältere Ausdrücke weiterhin auszuführen, während den Operatoren eine saubere und genaue Variablenliste präsentiert wird. Der sichtbare Katalog und die interne Verwendung werden getrennt gehalten.
Funktionen wie XMLQUERY, XMLPATHTYPE und XMLPATHEXISTS sind auf Lua-Converter-Komponenten angewiesen. Diese Komponenten werden beim Start des Dienstes geladen und von den relevanten FX-Funktionen verwendet. Fehlende Converter-Zustände sollten bei der Bereitstellung und in Gesundheitsprüfungsprozessen abgefangen werden.
Jeder Ausdrucksbaum sollte mit einer Änderungshistorie nachverfolgbar sein. Wer welchen Ausdruck wann geändert hat, ist kritische Information für Betriebs- und Sicherheitsüberprüfungen. Diese Aufzeichnungen bieten Rollback-Fähigkeit und Verantwortlichkeitsverfolgung, insbesondere für Regeln, die das Verkehrsverhalten beeinflussen.
STRREPLACEALL und bestimmte Regex-basierte Prüfungen können bei nachlässiger Programmierung hohe Verarbeitungskosten verursachen. Backtracking-intensive Muster können sowohl Sicherheits- als auch Leistungsrisiken darstellen. Die Benutzeroberfläche sollte Operatoren in diesen Fällen warnen und ein sichereres Muster-Authoring fördern.
SaaS-Teams können denselben FX-Ausdruck — wie `$.status == "OK"` im Response-Body — sowohl in der Gesundheitsprüfung als auch in der Verkehrsroutingregel verwenden. Da derselbe Dienststatus nicht in jedem Modul unterschiedlich geschrieben wird, verbessert sich die operative Konsistenz.
SOC-Teams können über JWTPAYLOAD E-Mail-Adresse, Rolle oder Tenant-Informationen des Benutzers zum Log-Format hinzufügen. Die Vorfallsuntersuchung geht über rohe IP- und URL-Daten hinaus und macht den Benutzerkontext in jedem Log-Eintrag sichtbar.
Globale Service-Teams können bei der Auswahl einer DNS-Antwort Land-, ASN- oder Latenzdaten durch FX-Ausdrücke auswerten. Dieselbe Logik kann bei Bedarf in einer Verkehrsroutingregel wiederverwendet werden.
E-Commerce-Teams können einen definierten Prozentsatz des Verkehrs basierend auf einem aus der Benutzerkennung abgeleiteten Hash auf eine neue Variante umleiten. Die Verteilung ist deterministisch — derselbe Benutzer wird bei jeder Anfrage immer zur selben Erfahrung weitergeleitet.
Verwalten Sie Verkehrsregeln, Gesundheitsprüfungen, Logs, GTM- und Sicherheitsentscheidungen durch dasselbe FX-Modell. Lassen Sie uns ein Live-Setup in Ihrer eigenen Umgebung durchgehen.