Connettore Router

Panoramica

Il connettore Router valuta una lista di condizioni MXL contro ogni payload in ingresso ed emette il payload marcato con la prima route corrispondente. Usalo per dividere un singolo stream in più canali logici su cui i connettori a valle possono fare branching.

Tipo Connettore: MeddleRouter

Configurazione

{
  "type": "MeddleRouter",
  "config": {
    "routes": [
      { "condition": "temperature > 80", "tag": "critical" },
      { "condition": "temperature > 50", "tag": "warning" },
      { "condition": "temperature <= 50", "tag": "normal" }
    ],
    "defaultTag": "unknown"
  }
}

Il connettore valuta le route dall’alto verso il basso. La prima la cui condition valuta true vince; il suo tag viene scritto al payload sotto la chiave riservata _route.

Output

Ogni payload corrispondente viene arricchito con un campo _route:

{
  "temperature": 92.5,
  "sensor_id": "S-01",
  "_route": "critical"
}

I connettori a valle (Filter, Trigger, Notification, ecc.) possono fare branching su _route per inviare ogni tag a una destinazione diversa.

Parametri di Configurazione

• routes (richiesto, min 1): Array ordinato di definizioni di route. Ogni route ha:
  • condition (richiesto): Un’espressione MXL valutata contro il payload
  • tag (richiesto): Stringa scritta in _route quando la condizione corrisponde
• defaultTag: Tag opzionale applicato quando nessuna route corrisponde. Se non impostato e nessuna route corrisponde, il payload viene scartato e viene emesso un errore.

Espressioni MXL

Le route usano MXL (Meddle Expression Language) — la stessa sintassi di espressione usata da Trigger e Alert.

temperature > 80
status == "active" && pressure < 10
humidity >= 60 || temperature > 25
count != 0

Le condizioni vengono analizzate all’avvio; MXL non valido impedisce l’avvio del connettore.

Casi d’Uso

1. Routing basato sulla severità — dividi la telemetria in stream normale / warning / critico
2. Fan-out multi-tenant — tagga i payload per sito, cliente o classe di dispositivo
3. Branchamento di workflow — dirige forme di payload diverse a pipeline a valle diverse
4. Routing A/B — invia un sottoinsieme di traffico a un processore sperimentale

Esempio: Routing Multi-Sito

{
  "type": "MeddleRouter",
  "config": {
    "routes": [
      { "condition": "site_id == \"plant-a\"", "tag": "plant_a" },
      { "condition": "site_id == \"plant-b\"", "tag": "plant_b" },
      { "condition": "site_id == \"plant-c\"", "tag": "plant_c" }
    ],
    "defaultTag": "unassigned"
  }
}

Ogni payload viene marcato con il suo sito di origine, e qualsiasi payload senza un site_id riconosciuto cade nel canale unassigned.

Esempio: Triage di Severità

{
  "type": "MeddleRouter",
  "config": {
    "routes": [
      { "condition": "vibration > 5.0 || temperature > 100", "tag": "critical" },
      { "condition": "vibration > 2.0 || temperature > 70",  "tag": "warning" },
      { "condition": "true",                                  "tag": "normal" }
    ]
  }
}

Una condizione true come ultima voce agisce come default implicito. Il campo _route può quindi guidare Notification (critical -> Slack, warning -> email) o Filter (normal -> scarta).

Migliori Pratiche

• Ordina le route dalla più specifica alla più generale; vince solo la prima corrispondenza
• Usa defaultTag per garantire che ogni payload esca dal connettore — altrimenti i payload non corrispondenti diventano errori
• Mantieni le condizioni MXL prive di effetti collaterali e basate su campi del payload che l’upstream è garantito popolare
• Evita route sovrapposte che dipendono solo dall’ordine — condizioni esplicite sono più facili da mantenere
• I connettori Filter o Trigger a valle dovrebbero fare branching su _route invece di rivalutare lo stesso MXL

Connettori Correlati

• Trigger - Gating MXL a singola condizione
• Filter - Scarta o mantieni payload per chiave
• Riferimento MXL - Documentazione completa MXL