RabbitMQ

trigger_rabbitmq · trigger · Triggers · Disponibile · v1.0.0

Descrizione

Avvia il workflow ogni volta che arriva un messaggio su una coda RabbitMQ. Il runtime apre un consumer AMQP 0-9-1 persistente verso il broker e resta in ascolto: ideale per architetture a code dove un producer deposita lavori (ordini, email da inviare, job di elaborazione) e il workflow li processa uno a uno. Differenza con i sibling: trigger_webhook = HTTP in ingresso; trigger_websocket = stream push persistente; trigger_kafka = log distribuito ad alto throughput con consumer group/offset; trigger_rabbitmq = coda di lavoro con ack per-messaggio e requeue. Scegli RabbitMQ quando vuoi una coda di lavoro affidabile con conferma esplicita di elaborazione (work queue), non un log da rileggere. Consegna affidabile (at-least-once, default): il messaggio viene confermato (ACK) al broker SOLO dopo che il run è partito con successo. Se il run fallisce, il messaggio viene rimesso in coda (NACK + requeue) e riconsegnato: nessun lavoro perso su un crash. In modalità "auto" (at-most-once) il broker considera consegnato all'invio — più veloce ma un run fallito perde il messaggio. Backpressure: "prefetch" limita quanti messaggi non ancora confermati il broker invia in parallelo — è il vero regolatore di carico, evita di sommergere il runtime. Riconnessione automatica con backoff esponenziale (1s→2s→…→30s) su caduta del broker o della rete. Output per ogni messaggio: { data } = payload parsato come JSON quando possibile (altrimenti la stringa grezza), { raw } = testo originale, { receivedAt } = timestamp ISO. Con "JSON Pointer di filtro" processi solo i messaggi che hanno un certo campo. Use case: (1) coda di ordini da un e-commerce → validazione → evasione, (2) job di invio email/PDF depositati da un'altra app → generazione → invio, (3) eventi di dominio da microservizi → sync verso CRM/DB, (4) pipeline di elaborazione immagini/documenti con requeue automatico sui fallimenti.

⚙️ Parametri di configurazione

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

Campo	Tipo	Required	Default	Descrizione
`url` URL del broker (AMQP)	`string`	si	— amqps://user:[email protected]:5671/vhost	URI di connessione AMQP. amqps:// = TLS (raccomandato in produzione), amqp:// = in chiaro (solo reti fidate). Include credenziali e vhost. Il consumer resta connesso finché il workflow è abilitato.
`queue` Coda (queue)	`string`	si	— orders.incoming	Nome della coda da consumare. Se non esiste viene dichiarata (assertQueue). La durabilità è controllata dall'opzione qui sotto.
`durable` Coda durevole	`boolean`	no	`true`	On (default): la coda sopravvive al restart del broker. Deve combaciare con come la coda è stata dichiarata dal producer, altrimenti il broker rifiuta la connessione con un errore di parametri incompatibili.
`ackMode` Modalità di conferma	`enum` `manualauto`	no	`manual`	manual (default, consigliata): il messaggio è confermato SOLO se il run parte con successo; su errore torna in coda e viene riconsegnato. Automatica: il broker lo considera consegnato subito — un run fallito lo perde.
`prefetch` Prefetch (backpressure)	`number`	no	`10`	Quanti messaggi non ancora confermati il broker può inviare in parallelo. È il regolatore di carico principale: valori bassi = più prudente, alti = più throughput ma più run concorrenti. Solo in modalità Manuale.
`jsonParse` Parsa i messaggi come JSON	`boolean`	no	`true`	On (default): il payload viene parsato come JSON in "data" (fallback alla stringa grezza se non è JSON valido). Off: "data" resta la stringa. "raw" contiene sempre il testo originale del messaggio.
`messagePointer` JSON Pointer di filtro/estrazione	`string`	no	— /type oppure /event/name	RFC 6901 JSON Pointer. Se valorizzato, il run parte SOLO se il puntatore risolve a un valore non-undefined (esposto come "matched"). I messaggi senza match vengono comunque confermati al broker (scartati per scelta, non riconsegnati). Vuoto = ogni messaggio fa partire un run.
`maxMessagesPerSec` Budget anti-flood (messaggi/sec)	`number`	no	`0`	Tetto di run avviati al secondo. I messaggi oltre il budget vengono rimessi in coda (requeue) per non saturare il runtime. 0 = nessun limite (il prefetch fa già da backpressure — di norma basta quello).
`reconnect` Riconnessione automatica	`boolean`	no	`true`	On (default): su caduta del broker/rete riconnette con backoff esponenziale (1s→2s→…→30s). Off: alla prima disconnessione il consumer si ferma finché non riabiliti/salvi il workflow.

💡 Esempio configurazione

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

{
  "id": "node-trigger_rabbitmq-1",
  "defId": "trigger_rabbitmq",
  "label": "RabbitMQ",
  "config": {
    "url": "amqps://user:[email protected]:5671/vhost",
    "queue": "orders.incoming",
    "durable": true,
    "ackMode": "manual",
    "prefetch": 10,
    "jsonParse": true,
    "maxMessagesPerSec": 0,
    "reconnect": true
  }
}

🔗 Nodi correlati nella stessa categoria

Pronto a usare RabbitMQ?

Disponibile da subito in tutti i piani FlowForge. Provalo gratis senza carta di credito.

Inizia gratis Sfoglia tutti i nodi