Skip to main content

MongoDB Destination

The MongoDB destination lets Flowlyze write documents to a MongoDB collection, complementing the MongoDB source (read). Use it for replication pipelines, syncing into document stores, and flows where the payload is already shaped as a JSON document.

Connection and Target Parameters

ParameterDescription
ConnectionStringFull connection string including protocol and credentials (e.g. mongodb+srv://user:password@host:27017/?authSource=admin).
DatabaseName of the database that holds the target collection.
CollectionCollection where documents are written.

Ensure the connection string matches your network, TLS, and authSource requirements; validate connectivity from the environment where Flowlyze runs (firewalls, Atlas IP allowlists, etc.).

Phase Queries and Transactions

ParameterDescription
PrepareQueryQuery or command run at the start of a message chunk insert: useful for temporary setup, targeted cleanup, or preparing context before bulk writes.
FinalizeQueryQuery run after the chunk insert completes, following all write operations for that batch: consolidation, status updates, or follow-up operations on the same session.
InTransactionWhen true, chunk operations can run inside a MongoDB transaction. Only available when the deployment is a replica set (or a sharded cluster with multi-document transaction support). On a standalone instance, transaction semantics differ; leave this disabled or confirm your cluster topology.
Per-chunk write cycle

For each processed chunk, the logical order is: PrepareQuery (optional) → document writes according to ModeFinalizeQuery (optional). Keep Prepare/Finalize idempotent or domain-safe so retries on the same chunk do not cause unintended side effects.

Write Mode (Mode) and Match Field

ParameterDescription
ModeWrite strategy: insertOnly, upsert, or replaceIfFound.
MatchFieldJsonPathJSON path into the incoming document used as the logical key for upsert and replaceIfFound: the extracted value is matched against existing documents in the collection (equality on the corresponding field).
MatchFieldJsonPath required for upsert and replace

For upsert and replaceIfFound, configure MatchFieldJsonPath to point to a stable, unique field in the payload (e.g. business id or _id when it matches collection semantics). A wrong path leads to missed matches (insert-only behavior) or updates against the wrong documents.

Supported Flows by Mode

Mode controls how each document in the chunk is applied to the collection.

insertOnly

Each document is inserted without existence checks or destination-side deduplication: pure append to the collection.

Primary key and append

If the incoming document includes a field MongoDB treats as _id (or a unique index) and that value already exists, the insert may fail on uniqueness. For a pure append stream without collisions, remove or rewrite the key field on the payload using a low-code action on the destination so MongoDB can assign a new _id automatically.

replaceIfFound

If a document exists whose match key equals the value from MatchFieldJsonPath, that document is fully replaced by the new document. If there is no match, the expected behavior is to insert the new document (replace-if-found, otherwise create).

upsert

Same equality match on MatchFieldJsonPath as replace, but the update is partial: fields present in the incoming document update only those properties, leaving other fields on the existing document unchanged where the engine applies a partial merge (as opposed to replacing the entire document).

Transactions and Replica Sets

Use InTransaction only when the topology supports it and you need Prepare + all writes + Finalize to be atomic for the chunk; on failure mid-batch, rolling back the chunk keeps the collection consistent with the pre-batch state.

Operational summary
  • Historical load or logs: often insertOnly plus low-code removal of _id when you must avoid collisions.
  • Sync by business key: upsert or replaceIfFound with MatchFieldJsonPath aligned to an indexed field in MongoDB.
  • Strong chunk-level consistency: InTransaction on a replica set, with Prepare/Finalize that do not assume commits outside the chunk.