Destinazione MongoDB
La destinazione MongoDB consente a Flowlyze di scrivere documenti in una collezione MongoDB, in complemento alla sorgente MongoDB (lettura). È adatta a pipeline di replica, sincronizzazione verso datastore documentali e scenari in cui il payload del flusso è già strutturato come documento JSON.
Parametri di connessione e target
| Parametro | Descrizione |
|---|---|
| ConnectionString | Stringa di connessione completa, inclusi protocollo e credenziali (es. mongodb+srv://user:password@host:27017/?authSource=admin). |
| Database | Nome del database che contiene la collezione di destinazione. |
| Collection | Nome della collezione in cui vengono scritti i documenti. |
La stringa di connessione deve riflettere rete, TLS e authSource richiesti dal cluster; verifica sempre la connettività dal contesto in cui gira Flowlyze (firewall, IP allowlist Atlas, ecc.).
Query di fase e transazioni
| Parametro | Descrizione |
|---|---|
| PrepareQuery | Query (o comando) eseguito all’inizio dell’inserimento di un chunk di messaggi: utile per indici temporanei, pulizia mirata o preparazione del contesto prima della scrittura bulk. |
| FinalizeQuery | Query eseguita alla fine del chunk, dopo tutte le operazioni di scrittura del batch: consolidamento, aggiornamenti di stato o chiamate successive sulla stessa sessione. |
| InTransaction | Se true, le operazioni del chunk possono essere racchiuse in una transazione MongoDB. Disponibile solo quando il deployment è in modalità replica set (o sharded cluster con supporto transazioni multi-documento). Su istanza standalone le transazioni non sono applicabili nello stesso modo: lascia disabilitata o verifica la topologia del cluster. |
Per ogni chunk elaborato, l’ordine logico è: PrepareQuery (opzionale) → scrittura documenti secondo Mode → FinalizeQuery (opzionale). Allineare Prepare/Finalize a operazioni idempotenti o a vincoli del dominio evita effetti collaterali se il chunk viene ripetuto (retry).
Modalità di scrittura (Mode) e campo di match
| Parametro | Descrizione |
|---|---|
| Mode | Strategia di inserimento/aggiornamento: insertOnly, upsert o replaceIfFound. |
| MatchFieldJsonPath | Percorso JSON nel documento in ingresso usato come chiave logica per upsert e replaceIfFound: il valore estratto viene usato per individuare il documento esistente nella collezione (uguaglianza sul campo corrispondente). |
MatchFieldJsonPath obbligatorio per upsert e replacePer upsert e replaceIfFound devi configurare MatchFieldJsonPath in modo che punti a un campo stabile e univoco nel payload (es. identificativo business o _id se presente e coerente con la collezione). Un path errato produce match mancati (solo insert) o aggiornamenti su documenti sbagliati.
Flussi supportati in base a Mode
Il parametro Mode determina come MongoDB applica ogni documento del chunk alla collezione.
insertOnly
Ogni documento viene inserito senza controlli di esistenza o deduplicazione lato destinazione: è un append puro alla collezione.
Se il documento in ingresso contiene un campo che MongoDB usa come _id (o un indice univoco) e quel valore esiste già, l’inserimento può fallire per violazione di unicità. Per uno stream di soli append senza collisioni, rimuovi o riscrivi il campo chiave sul payload tramite azione low-code in destinazione, così MongoDB può generare un nuovo _id automaticamente.
replaceIfFound
Se esiste un documento la cui chiave di match coincide con il valore indicato da MatchFieldJsonPath, quel documento viene sostituito interamente dal nuovo documento in scrittura. Se non c’è match, il comportamento atteso è l’inserimento del nuovo documento (comportamento tipo “sostituisci se c’è, altrimenti crea”).
upsert
Analogo al replace per la logica di ricerca per uguaglianza sul campo definito da MatchFieldJsonPath, ma l’aggiornamento è parziale: i campi inviati nel documento aggiornano solo le proprietà indicate, lasciando invariati gli altri campi del documento esistente dove previsto dal motore (merge/update parziale rispetto a sostituzione completa del documento).
Transazioni e replica set
Usa InTransaction solo quando la topologia lo consente e quando serve che Prepare + tutte le scritture + Finalize siano atomiche a livello di chunk; in caso di errore intermedio, il rollback del chunk mantiene la collezione coerente con lo stato precedente al batch.
- Solo caricamento storico o log: spesso
insertOnly+ rimozione_idin low-code se non vuoi collisioni. - Sincronizza per chiave business:
upsertoreplaceIfFound+ MatchFieldJsonPath allineato al campo indicizzato in MongoDB. - Coerenza forte per chunk: InTransaction su replica set, con Prepare/Finalize che non assumano commit esterni al chunk.