Run JavaScript

Descrizione

Esecutore enterprise di codice JavaScript custom in sandbox isolated-vm in-process — la primitiva di escape hatch per qualsiasi trasformazione di business logic NON coperta dai nodi specifici stdlib o logic_transform. Usa isolated-vm (lib battle-tested usata in produzione da Cloudflare Workers, Discord bot eval, Replit, Algolia per allow user code execution) che fornisce isolation a livello V8 (process-level VM con context separato) — il codice user-provided NON può vedere né interferire con il main runtime process del tenant, evitando classic Node.js eval vulnerabilities (process.exit, fs.access, require di moduli arbitrari come "child_process"). Sandboxing rigoroso multi-livello: NO accesso al filesystem (fs module assente), NO accesso di rete (fetch/http/https assenti), NO require/import di moduli (limitato strict alla standard JavaScript std: Math, JSON, Array, Object, Date, String, RegExp, Number, Map, Set, Promise — il subset safe-by-construction); cap di memoria configurable (default 128MB, max 512MB per workflow heavy-compute); timeout configurable (default 5s, max 30s per evitare workflow stuck su infinite loop bug); deep stack depth cap a 1000 frame per protezione recursion-bomb. Performance enterprise: latenza tipica < 5ms per script piccoli (overhead di context entry/exit + snapshot creation è minimo), throughput sustained 1000+ exec/sec single-thread su CPU moderno — pattern OK per high-volume workflow batch dove ogni iter richiede un piccolo bit of custom JS. Variabili globali disponibili nel script: input (output JSON del nodo precedente — la fonte primaria di dati da processare), vars (workflow variables persistenti — ricordo cross-step), ctx (run metadata come runId, tenantId, workflowId, currentTime per timestamp embedding). Output: il valore return-ato dallo script diventa l'output del nodo (deve essere JSON-serializable — no functions, no circular references, no Symbol — il check è automatic e fail con error semantic esplicito se viola la regola). Use case: trasformazione dati custom non coperta da logic_transform (es. complex map+filter+reduce multi-pass su array nested); calcoli business logic specifici del cliente (es. provvigione tier-based con scaglioni di importo + bonus YoY + override regola country); validation custom multi-field con rule complex (es. "if amount > 1000 AND country != billing_country AND timestamp < user.created_at + 7days → fraud_signal"); mapping/reshape input prima di chiamata API downstream con format esotic non mappabile dichiarativamente; generazione di id deterministici via hash semplice (sha256(email + company)); compute di statistiche aggregate custom (median, percentiles, weighted average con peso configurable); algoritmi proprietari del cliente (lead scoring custom, churn risk score, NPS adjusted) che NON vuole esporre come logica in template visuale ma come black-box pura function.

⚙️ Parametri di configurazione

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

💡 Esempio configurazione

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

{
  "id": "node-action_run_js-1",
  "defId": "action_run_js",
  "label": "Run JavaScript",
  "config": {
    "code": "// input = output del nodo precedente\n// vars = workflow variables\n// ctx = { tenantId, runId, nodeId }\n\nconst items = input.items || [];\nconst total = items.reduce((s, x) => s + (x.amount || 0), 0);\nreturn { total, count: items.length };\n",
    "timeoutMs": 5000,
    "memoryLimitMb": 128
  }
}

🔗 Nodi correlati nella stessa categoria