Switch

Descrizione

Operatore di branching N-way enterprise — l'equivalent del switch/case dei linguaggi di programmazione classici (Java, C#, JavaScript, Python match) applicato al workflow orchestration. Mentre logic_if è binario (true/false), logic_switch instrada il flusso su uno tra molti rami in base al valore di un'espressione discriminante — pattern fondamentale per routing a dispatcher basato su tipo di evento, categoria, status, regione, customer tier, e centinaia di altri campi categorical che richiedono "se è A vai qui, se è B vai là, se è C ancora altrove, altrimenti gestisci come default". Ogni "case" è una porta di output dedicata del nodo nel grafo del workflow editor, etichettata con il valore matched (es. "order_confirmed", "refund_requested", "subscription_cancelled") — l'utente collega visualmente ogni porta a una catena di azioni diversa, e l'engine FlowForge esegue SOLO il ramo scelto in base alla chosenBranch decision (vedere workflow-engine strategy logic-switch) evitando fan-out su tutti i rami e sprecando risorse + side effects indesiderati. Modalità di matching per case: (1) Literal match (default) — comparison esatto value === case_value (con type coercion intelligente: "42" matcha 42 number, "true" matcha boolean true) — il pattern più semplice e più comune che copre 90% degli use case enum-like; (2) Condition-rules sidecar — per case con logica complessa che NON è esprimibile come singolo literal (es. "matcha questo case se amount > 1000 AND country in ['IT', 'ES']"), ogni case può avere un condition-rules array opzionale che fa override del literal match con AND/OR builder visuale identico a logic_if — pattern hybrid per ottenere il visual N-way switch con la potenza condizionale del if. Ramo di fallback "default" obbligatorio attivabile: quando nessun case matcha, il flusso prosegue sull'output "default" — pattern safety per non lasciare workflow stuck su input inatteso (es. nuovo tipo di evento aggiunto upstream che il nostro switch non conosce ancora — vogliamo gestirlo gracefully con log + escalation invece di crash silenzioso). Il flag strictMode può rendere obbligatorio match (throw error se nessun case + no default) — pattern per workflow critici dove un fallthrough è bug. Use case: routing per tipo evento webhook (Stripe webhook può avere 50+ type — order.created → ramo fulfillment, charge.refunded → ramo customer success, subscription.deleted → ramo retention, ecc.); classificazione status di un ordine (pending → ramo "in attesa pagamento email cliente", paid → ramo "trigger fulfillment", failed → ramo "alert ops e retry pagamento", refunded → ramo "audit + recupero merce"); multi-tenant routing per workflow super-admin che processa eventi da N tenant diversi e li instrada al subprocess giusto del tenant target; routing per language (it → email italiano, en → inglese, de → tedesco, ecc. per workflow internazionali); dispatching per region geografica con SLA differenziati per cluster di server (EU → ramo Frankfurt, US → ramo Virginia, APAC → ramo Singapore).

⚙️ Parametri di configurazione

Campi mostrati nell’editor quando si configura il nodo. Generati direttamente dal NodeDefconfigFields.

⬆️ Output del nodo

Campi disponibili nei nodi successivi via $node.<alias>.json.<field>:

• *

💡 Esempio configurazione

Snippet JSON del nodo come compare nel workflow. I valori sono derivati daidefaultValue e dai parametri required.

{
  "id": "node-logic_switch-1",
  "defId": "logic_switch",
  "label": "Switch",
  "config": {
    "expression": "input.country",
    "cases": "<cases>",
    "fallbackBranch": "default",
    "caseSensitive": true,
    "strictMode": false
  }
}

🔗 Nodi correlati nella stessa categoria