Router-Konnektor

Übersicht

Der Router-Konnektor wertet eine Liste von MXL-Bedingungen gegen jede eingehende Payload aus und gibt die Payload mit der ersten passenden Route gekennzeichnet aus. Verwenden Sie ihn, um einen einzelnen Stream in mehrere logische Kanäle aufzuteilen, auf die nachgelagerte Konnektoren verzweigen können.

Konnektor-Typ: MeddleRouter

Konfiguration

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

Der Konnektor wertet Routen von oben nach unten aus. Die erste, deren condition zu true ausgewertet wird, gewinnt; ihr tag wird in die Payload unter dem reservierten Schlüssel _route geschrieben.

Ausgabe

Jede passende Payload wird um ein _route-Feld erweitert:

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

Nachgelagerte Konnektoren (Filter, Trigger, Notification usw.) können auf _route verzweigen, um jeden Tag an ein anderes Ziel zu senden.

Konfigurationsparameter

routes (erforderlich, min 1): Geordnetes Array von Routendefinitionen. Jede Route hat:
- condition (erforderlich): Ein gegen die Payload ausgewerteter MXL-Ausdruck
- tag (erforderlich): String, der in _route geschrieben wird, wenn die Bedingung übereinstimmt
defaultTag: Optionaler Tag, der angewendet wird, wenn keine Route übereinstimmt. Wenn nicht gesetzt und keine Route übereinstimmt, wird die Payload verworfen und ein Fehler ausgegeben.

MXL-Ausdrücke

Routen verwenden MXL (Meddle Expression Language) — dieselbe Ausdruckssyntax, die von Trigger und Alert verwendet wird.

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

Bedingungen werden beim Start geparst; ungültiges MXL verhindert den Start des Konnektors.

Anwendungsfälle

Schweregradbasiertes Routing — Telemetrie in Normal-/Warning-/Critical-Streams aufteilen
Mandanten-Fan-Out — Payloads nach Standort, Kunde oder Geräteklasse kennzeichnen
Workflow-Verzweigung — verschiedene Payload-Formen an verschiedene nachgelagerte Pipelines lenken
A/B-Routing — eine Teilmenge des Verkehrs an einen experimentellen Prozessor senden

Beispiel: Multi-Standort-Routing

{
  "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"
  }
}

Jede Payload wird mit ihrem Ursprungsstandort gekennzeichnet, und jede Payload ohne erkannten site_id fällt in den unassigned-Kanal.

Beispiel: Schweregrad-Triage

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

Eine true-Bedingung als letzter Eintrag fungiert als impliziter Standard. Das _route-Feld kann dann Notification steuern (critical -> Slack, warning -> E-Mail) oder Filter (normal -> Drop).

Best Practices

Ordnen Sie Routen von der spezifischsten zur allgemeinsten an; nur die erste Übereinstimmung gewinnt
Verwenden Sie defaultTag, um zu garantieren, dass jede Payload den Konnektor verlässt — andernfalls werden nicht zugeordnete Payloads zu Fehlern
Halten Sie MXL-Bedingungen frei von Seiteneffekten und basieren Sie sie auf Payload-Feldern, die der vorgelagerte Konnektor garantiert befüllt
Vermeiden Sie überlappende Routen, die allein von der Reihenfolge abhängen — explizite Bedingungen sind einfacher zu warten
Nachgelagerte Filter- oder Trigger-Konnektoren sollten auf _route verzweigen, anstatt dasselbe MXL erneut auszuwerten