Yetenek

FX İfade ve Değişken Motoru

Tek ifade diliyle kural, sağlık kontrolü, log, GTM, güvenlik ve erişim kararlarını aynı mantıkta yönetin.

TR7 FX İfade ve Değişken Motoru, platformun farklı modüllerinde aynı karar dilini kullanmanızı sağlar. Trafik kuralı, sağlık kontrolü, log şablonu, güvenlik politikası, GTM tetikleyicisi ve ACL mantığı ayrı ayrı sözdizimleriyle değil, ortak FX diliyle tanımlanır. FX motoru; 41 yerleşik fonksiyon, 173 değişken ve 14 değişken grubu ile trafik, kullanıcı, bağlantı, gövde, SSL, WAAP ve AAM bağlamını tek ifade modeli altında toplar. JSONQUERY, XMLQUERY, JWTPAYLOAD, PARAM, MAP, LIST, DIGEST, IPMASK ve metin dönüştürme fonksiyonları aynı ifade ağacında birlikte kullanılabilir. İfade yazımı şema tabanlıdır; fonksiyon argümanları, değişken kapsamları, kullanım bağlamları ve tipler kayıt öncesinde kontrol edilir. Hata runtime'da servis trafiğini etkilerken değil, kural yazımı sırasında yakalanır. Sonuç: TR7, karmaşık trafik ve güvenlik kararlarını tek dil, tek değişken modeli ve modüller arası ortak mantıkla yönetilebilir hale getirir.

41
Yerleşik fonksiyon — converter'dan JWT sorgusuna kadar
173
Yerleşik değişken — 14 grup altında trafik ve güvenlik bağlamı
6+
Modül — aynı FX dilini kullanan: kural, sağlık kontrolü, log, captcha, GTM, ACL

Her modül ayrı dil kullanıyorsa, platform büyüdükçe operasyon karmaşası da büyür.

Kurumsal trafik yönetimi artık yalnızca yük dengeleme kuralından ibaret değildir. Aynı platform içinde trafik yönlendirme, sağlık kontrolü, log zenginleştirme, GTM kararı, güvenlik skoru, captcha politikası, ACL ve erişim bağlamı birlikte çalışır. Sorun, bu modüllerin çoğu üründe ayrı ifade dili, ayrı değişken adı ve ayrı hata davranışıyla yönetilmesidir.

Bu parçalanma operatörü sürekli bağlam değiştirmeye zorlar. Aynı değer bir modülde farklı, başka bir modülde farklı yazılır; kullanıcı ülkesi, istemci IP'si, istek yolu, JWT claim'i veya WAAP skoru her yerde ayrı mantıkla ele alınır. Sonuçta öğrenme maliyeti artar, kural tekrarları çoğalır ve debug süresi uzar.

Daha tehlikelisi, aynı iş kuralının farklı modüllerde farklı yorumlanmasıdır. Sağlık kontrolünde kullanılan koşul ile trafik yönlendirme koşulu ayrışırsa, sistem bir servisi sağlıklı kabul ederken aynı servise giden trafiği başka bir mantıkla kesebilir. Log tarafında aynı bağlam eksik kaydedilirse, olay sonrası inceleme de zayıflar.

Doğru yaklaşım, tek bir ifade dilini ortak karar katmanı haline getirmektir. Bu dil fonksiyonları, değişkenleri, tip kontrolünü ve kullanım kapsamını merkezi olarak tanımlamalı; her modül aynı ifade ağacını kendi çalışma alanına uygun şekilde kullanmalıdır.

TR7 FX Motoru bu ihtiyacı karşılar: farklı modüllerde dağılmış karar mantığını tek ifade dili, tek değişken kataloğu ve kayıt öncesi doğrulama modeli altında birleştirir.

Yaklaşımımız

TR7, karar mantığını modül bazlı ayrı sözdizimlerine bölmek yerine, ortak FX ifade ağacı üzerinden derler ve uygular.

Fonksiyon ve değişken kataloğu merkezi olarak tanımlanır

FX motoru 41 yerleşik fonksiyon ve 173 değişkeni 14 grup altında sunar. Bağlantı, HTTP başlıkları, gövde, SSL, zamanlayıcı, istatistik, WAAP ve AAM bağlamları aynı katalog üzerinden seçilir.

İfadeler native sample ve converter zincirine derlenir

Uygun fonksiyonlar doğrudan yüksek performanslı sample fetch ve converter zinciri olarak çalıştırılır. Örneğin gövde içindeki JSON alanı okunup metin dönüştürücüyle normalize edilebilir ve tek ifade sonucuna bağlanabilir.

Native olmayan fonksiyonlar Lua aksiyonuna dönüştürülür

XML XPath, karmaşık JWT sorguları veya özel işlem gerektiren fonksiyonlar Lua tabanlı aksiyon olarak üretilir. Böylece FX dili tek kalır; çalışma yolu fonksiyonun ihtiyacına göre seçilir.

Aynı ifade motoru farklı modüller tarafından tüketilir

Trafik kuralı, sağlık kontrolü, log formatı, GTM tetikleyici, captcha politikası ve ACL aynı fonksiyon ve değişken modelini kullanır. Bu ortaklık, operatörün her modül için yeni bir karar dili öğrenme ihtiyacını azaltır.

Yetenekler

FX İfade ve Değişken Motoru, platform genelinde kullanılabilir değişkenleri ve fonksiyonları şema tabanlı, doğrulanabilir ve derlenebilir bir modele dönüştürür.

173 değişken, 14 grup altında trafik ve güvenlik bağlamını kapsar

FX değişken kataloğu bağlantı, HTTP başlıkları, gövde, istemci, istek satırı, yanıt satırı, SSL, istatistik, zamanlayıcı, tracking, WAAP, AAM, VarBuilder ve diğer gruplardan oluşur. Operatör kaynak IP, hedef port, istek yolu, yanıt durumu, SNI, sertifika bilgisi, WAAP skoru, AAM kullanıcı rolü veya özel değişken gibi değerleri aynı modelden seçer. Bu yapı, farklı modüllerde aynı bağlamın farklı isimlerle yazılmasını engeller. Kural dili daha tutarlı, daha okunabilir ve daha az hataya açık hale gelir.

41 fonksiyon, dönüşümden JSON ve XML sorgusuna kadar genişler

Fonksiyon kataloğu converter, matematik, XML, JSON, JWT, IP, metin, hash, FIX, MQTT, map/list, parametre ve koşullu seçim gruplarını kapsar. JSONQUERY, XMLQUERY, JWTHEADER, JWTPAYLOAD, PARAM, DIGEST, LOWERCASE, STRREPLACEALL, MAP_STR, LIST_REG ve TERNARY gibi fonksiyonlar aynı ifade içinde birlikte kullanılabilir. Operatör hem basit metin dönüşümleri hem de gövde içeriği sorguları için aynı FX modelini kullanır. Bu, kural yazımını kodlama işinden çıkarıp yönetilebilir politika tanımına yaklaştırır.

Native derleme yolu düşük gecikmeli ifadeler için kullanılır

Native olarak desteklenen değişken ve fonksiyonlar doğrudan sample fetch ve converter zinciri halinde derlenir. Bu yol, header okuma, path eşleştirme, metin dönüştürme, map kontrolü ve belirli gövde sorguları gibi sık kullanılan kararlar için uygundur. Ara katmanda gereksiz yorumlama yapılmadığı için performans öngörülebilir kalır. Trafik kuralları, mümkün olduğunda platformun en verimli çalışma yoluna çevrilir.

Lua derleme yolu karmaşık ve özel fonksiyonları kapsar

Native zincirle ifade edilemeyen bazı kontroller Lua aksiyonu olarak çalıştırılır. XML XPath sorguları, özel JWT kontrolleri veya karmaşık koşullu işlemler bu yolla desteklenebilir. Operatör açısından ifade dili değişmez; sistem arka planda doğru çalışma yolunu seçer. Bu ayrım, hem performanslı native yolu hem esnek Lua yolunu aynı FX deneyiminde birleştirir.

Tip kontrolü kayıt öncesinde hatalı ifadeleri reddeder

Her fonksiyon argümanı integer, string, jsonPath, xmlPath, hash veya smartInput gibi tiplerle tanımlanır. UI ve yönetim katmanı bu tipleri kayıt sırasında kontrol eder. Yanlış argüman tipi, eksik parametre veya uyumsuz nested kullanım runtime'a taşınmadan yakalanır. Bu yaklaşım, üretim trafiğinde beklenmeyen kural hatalarını azaltır.

Kullanım kapsamı modül ve bağlama göre filtrelenir

Her değişken hangi modüllerde, hangi koşul tiplerinde ve hangi trafik aşamasında kullanılabileceğini metadata olarak taşır. Örneğin bazı değişkenler yalnızca response aşamasında geçerlidir; bazıları yalnızca log şablonunda veya belirli koşul tipinde gösterilir. UI bu bilgiyi kullanarak operatöre bağlama uygun seçenekler sunar. Böylece geçersiz değişkenlerin yanlış yerde kullanılması önlenir.

VarBuilder ile operatör kendi hesaplanmış değişkenini oluşturur

VarBuilder grubu, operatörün runtime sırasında hesaplanan özel değişkenler üretmesini sağlar. Bir değer FX ifadesiyle hesaplanır, işlem kapsamında saklanır ve sonraki kurallarda tekrar kullanılabilir. Bu model, aynı hesaplamanın birden fazla yerde tekrar yazılmasını azaltır. Karmaşık akışlarda karar mantığı daha modüler ve izlenebilir hale gelir.

Otomatik tamamlama şema bilgisinden beslenerek yazımı hızlandırır

FX konsolu fonksiyon, değişken, argüman ve kullanım kapsamı bilgisini merkezi şemadan alır. Operatör fonksiyon adı veya değişken yazarken uygun seçenekleri görür; boş değer kabul eden argümanlar ve parantez gerektiren fonksiyonlar UI tarafından doğru biçimde yönlendirilir. Bu, hem yeni kullanıcıların öğrenme süresini azaltır hem de deneyimli operatörlerin daha hızlı kural yazmasını sağlar. Yazılan ifade daha kayıt aşamasına gelmeden daha doğru hale gelir.

Operasyonel derinlik

FX motoru yalnızca ifade yazma deneyimi değil; doğrulama, kapsam, audit, performans ve edge case davranışlarıyla birlikte tasarlanır.

01

Argüman doğrulama

Her fonksiyonun beklediği argüman listesi ve tipleri merkezi tanımda tutulur. UI ve yönetim katmanı bu bilgiyi ayrı ayrı kontrol eder. Böylece yalnızca ekranda değil, kayıt işleminde de hatalı ifade reddedilir.

02

Response aşaması kapsamı

Bazı değişkenler yalnızca response aşamasında anlamlıdır. Bu değişkenler metadata ile işaretlenir ve request aşamasındaki koşullarda kullanılmaları engellenir. Bu ayrım, aşama kaynaklı runtime hatalarını azaltır.

03

Gizli değişken aliasları

Bazı değişkenler geriye dönük uyumluluk veya iç kullanım için sistemde tutulur ancak UI'da gösterilmez. Bu sayede platform eski ifadeleri çalıştırabilirken operatöre sade ve doğru değişken listesi sunulur. Görünür katalog ile internal kullanım birbirinden ayrılır.

04

Lua converter yükleme

XMLQUERY, XMLPATHTYPE ve XMLPATHEXISTS gibi bazı fonksiyonlar Lua converter bileşenlerine ihtiyaç duyar. Bu bileşenler servis başlatılırken yüklenir ve ilgili FX fonksiyonları tarafından kullanılır. Eksik converter durumları deployment ve sağlık kontrol süreçlerinde yakalanmalıdır.

05

Audit ve versiyonlama

Her ifade ağacı değişiklik geçmişiyle birlikte izlenebilir olmalıdır. Kim, ne zaman, hangi ifadeyi değiştirdi bilgisi operasyon ve güvenlik incelemeleri için kritik değerdedir. Bu kayıtlar özellikle trafik davranışını değiştiren kurallarda geri dönüş ve sorumluluk takibi sağlar.

06

Regex performans uyarıları

STRREPLACEALL ve regex tabanlı bazı kontroller dikkatli yazılmadığında yüksek işlem maliyeti üretebilir. Backtracking ağırlıklı pattern'ler güvenlik ve performans riski oluşturabilir. UI bu tür durumlarda operatörü uyarmalı ve daha güvenli pattern yazımını teşvik etmelidir.

Hangi senaryolarda kullanılır

Sağlık kontrolü ve trafik kuralında ortak ifade

SaaS ekipleri, response gövdesi içindeki `$.status == "OK"` kontrolünü hem sağlık kontrolünde hem trafik kuralında aynı FX ifadesiyle kullanabilir. Aynı servis durumu farklı modüllerde farklı yazılmadığı için operasyonel tutarlılık artar.

JWT claim ile log satırı zenginleştirme

SOC ekipleri, log formatına JWTPAYLOAD üzerinden kullanıcı e-posta adresi, rol veya tenant bilgisini ekleyebilir. Olay incelemesinde ham IP ve URL bilgisinin ötesine geçilerek kullanıcı bağlamı görünür hale gelir.

GTM kararlarında geo ve ASN tabanlı tetikleme

Global servis ekipleri, DNS yanıtı seçerken ülke, ASN veya gecikme bilgisini FX ifadesiyle değerlendirebilir. Aynı mantık gerektiğinde trafik yönlendirme kuralında da kullanılabilir.

Hash tabanlı kontrollü A/B yönlendirme

E-ticaret ekipleri, kullanıcı kimliğinden üretilen hash değerine göre trafiğin belirli yüzdesini yeni varyanta aktarabilir. Dağıtım deterministik olur; aynı kullanıcı her istekte aynı deneyime yönlendirilir.

Sık sorulanlar

FX motoru kaç fonksiyon ve değişken sunar?
FX motoru 41 yerleşik fonksiyon ve 173 değişken içerir. Fonksiyonlar converter, matematik, XML, JSON, JWT, IP, metin, hash, FIX, MQTT, map/list, parametre ve koşullu seçim gruplarında yer alır. Değişkenler bağlantı, HTTP başlıkları, gövde, SSL, istatistik, zamanlayıcı, WAAP, AAM ve VarBuilder dahil 14 grup altında düzenlenir.
Hangi modüller aynı FX ifade dilini kullanır?
Trafik kuralı, sağlık kontrolü, log şablonu, GTM tetikleyici, captcha politikası ve ACL aynı FX fonksiyon ve değişken modelini paylaşır. Bu sayede operatör aynı değer için her modülde farklı bir sözdizimi öğrenmek zorunda kalmaz ve modüller arası tutarsızlık riski azalır.
Kayıt öncesi tip kontrolü nasıl çalışır?
Her fonksiyon argümanı integer, string, jsonPath, xmlPath, hash veya smartInput gibi bir tipte tanımlanır. UI ve yönetim katmanı bu tipleri ifade kaydedilmeden kontrol eder. Yanlış tip, eksik parametre veya uyumsuz nested kullanım runtime'a taşınmadan reddedilir.
Native derleme yolu ile Lua yolu arasındaki fark nedir?
Native olarak desteklenen değişken ve fonksiyonlar doğrudan sample fetch ve converter zinciri olarak derlenir; bu yol header okuma, path eşleştirme ve sık kullanılan gövde sorguları için idealdir. XMLQUERY, özel JWT kontrolleri veya karmaşık koşullu işlemler gibi native zincirle ifade edilemeyenler Lua aksiyonu olarak üretilir. Operatör açısından ifade dili her iki durumda da değişmez.
VarBuilder ile ne yapılabilir?
VarBuilder grubu, operatörün FX ifadesiyle runtime sırasında hesaplanan özel değişkenler tanımlamasını sağlar. Hesaplanan değer işlem kapsamında saklanır ve sonraki kurallarda doğrudan kullanılabilir. Bu, aynı hesaplamanın birden fazla kural içinde tekrar yazılması ihtiyacını ortadan kaldırır.
Değişken kapsamı nasıl denetlenir?
Her değişken, hangi modüllerde, hangi koşul tiplerinde ve hangi trafik aşamasında geçerli olduğunu metadata olarak taşır. Yalnızca response aşamasında anlamlı olan değişkenler request koşullarında gösterilmez. UI bu kapsam bilgisini kullanarak operatöre bağlama uygun seçenekleri sunar ve geçersiz kullanımı engeller.

Platform kararlarını tek ifade dilinde birleştirin

Trafik kuralı, sağlık kontrolü, log, GTM ve güvenlik kararlarını aynı FX modeliyle yönetin. Kendi ortamınızda canlı bir kurulumda gezdirelim.