MongoDB Node
The MongoDB Node allows a workflow to query or update values in a MongoDB database and optionally store the result on the workflow payload.
Node Properties
The configuration of the MongoDB Node can be broken down into four major sections - configuring the connection, choosing the operation, setting up the arguments, and choosing what to do with the result.
Connection
Provide the connection URI one of two different ways …
- Choose a Service Credential …: When selected, you must provide the name of one of your application’s MongoDB service credentials for authentication. For security and ease of use, this is the recommended method.
- Enter connection URI …: Enter the connection string directly. This must include the host name and database name. It must also include the username and password if the database requires authentication, and it may also require the port.
For Edge Workflows, the connection URI must be entered into the node directly; you may not reference a service credential.
Operation
Next, enter the Mongo Collection Name, which is the name of the collection you wish to operate on. This field supports templates.
Then, choose the operation to perform against the collection. Currently the node has support for the following operations:
- Aggregate (Requires GEA v1.15.0 or higher)
- Count
- Delete Many
- Delete One
- Distinct
- Find
- Find One
- Insert Many
- Insert One
- Update Many
- Update One
- Replace One (Requires GEA v1.15.0 or higher)
- Insert (Deprecated, uses Insert One or Insert Many)
- Remove (Deprecated, uses Delete One or Delete Many)
- Update (Deprecated, uses Update One or - Update Many)
The deprecated methods above will utilize other methods appropriate for your configuration.
Arguments
Depending on the chosen operation, the expected arguments here will change. For example,
with the findOne
operation, there are two arguments - the query itself, and any options
for the query. In the above example, we are not passing any options, but we are passing
a JSON template - searching for a document in the collection with a deviceId field that
matches the trigger ID that kicked off the run of the workflow. Most of the arguments for the various operations are expected to evaluate to JSON objects, and the node supports EJSON syntax for specifying things like ObjectIDs.
Both the query argument and the options argument allows users to choose the method by which the value will be set: a payload path, a string template or a JSON template.
Response
Finally, you can optionally choose to store the result of the Mongo operation on the payload. For operations like insert
or remove
, you might not care about the result, but for an operation like the findOne
above, you almost certainly do! In this case the result of the operation is being placed at the payload path working.queryResult
.
Error Configuration
In the case that the provided JSON string fails to parse, there are two possible options for how to handle the error.
- Error the workflow: Halt the workflow at this node, preventing further execution.
- Store MongoDB at payload path: Configure a payload path at which to store the error.
Note: For Edge Workflows, this option is only available on GEA version 1.15.0 or higher. On older versions, the workflow will always halt on errors.
Node Example
Depending on the chosen operation, the shape of the node’s result changes drastically. Here is an example payload after the MongoDB Node successfully connects and returns a result for a Find One operation, with the result stored at a payload path of working.mongoResult
:
{
"working": {
"mongoResult": {
"_id": { "$oid": "576ae72d4c0c31470b856483" },
"deviceId": { "$oid": "56c8967bb8df0f0100d629120" },
"phoneNumber": "212 867-5309",
}
}
}
Node Errors
In the case that the provided MongoDB query fails, there are two possible options. You can either error the workflow, or you can store the error at a path on the payload.
Below is an example of an error stored on the payload at a path of working.mongoError
:
{
"working": {
"mongoError": {
"message": "E11000 duplicate key error collection: test.alertMapping index: test1_1 dup key: { primary: \"Warehouse3\" }",
"type": "MongoError"
}
}
}
Was this page helpful?
Still looking for help? You can also search the Losant Forums or submit your question there.