Redis Node

The Redis Node allows a workflow to query or update values in a Redis database and optionally store the result on the workflow payload.

Node Properties

The configuration of the Redis Node can be broken down into 5 major sections - configuring the connection, configuring authentication, choosing the operation, setting up the arguments, and choosing what to do with the result. For Edge Workflows, if a Gateway Edge Agent (GEA) version is noted, that field is only available in that version or higher. In all cases, the configuration fields are available in Application and Experience Workflows.

Connection

A Redis connection can either be configured as a connection to a standalone Redis server (the default), or to a Redis cluster.

When connecting to a standalone Redis server, the following are the connection options:

• Connect With TLS: If your Redis instance is behind a TLS proxy (or is Redis 6 and supports TLS directly), you can specify that the connection should be made through TLS by checking this checkbox. (In Edge Workflows, this feature is only available in GEA version 1.9.0 and higher.)
• Redis Hostname Template: When configuring the connection, you must provide the hostname where your Redis instance is running. This can be an IP address or a resolvable DNS hostname. This can be a template.
• Redis Port Template: You can also optionally provide the Redis port, if your Redis is running on a non-standard port. By default, when this is left blank, the node assumes the standard Redis port of 6379. This can be a template.
• Database Number Template: You can provide the Redis database number if you are not using the default database 0. This can be a template.

In the example above, the Redis Node has been configured to connect to database 0 at myredis.example.com on port 6379 with TLS disabled.

If you receive a MOVED error when attempting an operation while connecting over a standalone connection, that means that you are attempting to interact with a Redis cluster as if it were a standalone instance. Please switch your node configuration to the cluster connection type in that case.

When connecting to a Redis cluster, the following are the connection options:

• Connect With TLS: If your Redis instance is behind a TLS proxy (or is Redis 6 and supports TLS directly), you can specify that the connection should be made through TLS by checking this checkbox. This will apply to any connections made to any member of the cluster.
• Host Template: When configuring the connection, you must provide at least one hostname where your Redis cluster is running. These can be IP addresses or resolvable DNS hostnames. These can be templates.
• Port Template: You can also optionally provide a port for each host, if your Redis cluster is running on non-standard ports. By default, when this is left blank, the node assumes the standard Redis port of 6379. This can be a template.

In the example above, the Redis Node has been configured to connect to the cluster at hosts myredis1.example.com and myredis2.example.com on port 6379 with TLS disabled.

Due to the fact that Redis cluster only returns IP addresses when asking for cluster members, there are some caveats when connecting to a cluster over TLS. If a single host is provided in the node configuration, WEGnology will assume that the SSL certificate on all of the members of the cluster will match the provided hostname (this is, for example, how Redis clusters on Azure and AWS work). When multiple hosts are provided, WEGnology will not attempt to verify the hostname on the SSL certificate of any cluster members connected to by IP address.

If you receive an error about No startup nodes are available when connecting to a Redis cluster, that means the node was unable to get the list of cluster members and then connect to them. The most likely reasons for this (assuming the cluster is actually up and running) are either incorrect authentication details, or issues with the SSL certificate.

In Edge Workflows, connecting to a Redis cluster is only available in GEA version 1.38.0 and higher.

Authentication

• Redis Username: If your Redis instance requires a username, you can provide it through this field. This can be a template. (In Edge Workflows, this feature is only available in GEA version 1.23.0 and higher.)
• Redis Password: If your Redis instance requires a password, you can provide it through this field. This can be a template.

In the example above, the Redis Node has been configured with no username and with the password template {{globals.myPassword}}.

SSL Options

If you selected “Connect with TLS” in your Connection configuration, this section will be made available.

• Custom CA Certificate: If you are connecting to your Redis instance with TLS and require a CA Certificate, you can provide it through this optional field. This can be a template. (In Edge Workflows, this feature is only available in GEA version 1.41.0 and higher.)

In the example above, the Redis Node has been configured with the CA Certificate template {{globals.caCert}}.

Command

Choose the command that will be performed on the Redis database.

The Redis Node has support for most regular Redis commands that deal with keys, sets, sorted sets, hashes, lists, strings, streams, geo, hyperloglog, and publishing. The full source for the Redis commands can be found in the Redis Documentation. The node does not support cluster, connection, scripting, server, subscribing, or transaction command groups.

Depending on the command, the next section of configuration will change - due to the expected number of arguments differing per command.

The full source for the Redis commands can be found here.

NOTE: In Edge Workflows, streaming commands are only supported for GEA v1.18.0 and higher. Additionally, there are a number of assorted Redis 5 & 6 commands that are only supported for GEA v1.23.0 or higher and Redis 6 & 7 commands that are only supported for GEA v1.35.0 or higher.

Arguments

Depending on the chosen command, the expected arguments here will change. For example, with the hget operation, there are two arguments - the key representing the hash, and the field to get within that hash. In the above example, the key that will be queried is phone_contacts, and the particular field in the key depends on the triggerId that triggered the workflow to run. All arguments support string templates. For commands that have optional or arbitrary numbers of arguments, the node will let you provide as many arguments as you need.

In Edge Workflows prior to GEA v1.35.0 each argument must be specified individually.

In Edge Workflows starting with GEA v1.35.0, as well as Application and Experience Workflows, arguments may also be specified by payload path.

Result

Finally, you can optionally choose to store the result of the Redis operation on the payload at a given payload path. For operations like set or sadd, you might not care about the result, but for an operation like the hget above, you almost certainly do! In this case the result of the hget is being placed at the JSON path data.redisResult.

Node Example

Here is an example payload after the above Redis Node has been run:

{
  "time": Fri Feb 19 2016 17:26:00 GMT-0500 (EST),
  "data": {
    "current": 10,
    "on": true,
    "redisResult": "212 867-5309"
  },
  "applicationId": "568beedeb436ab01007be53d",
  "applicationName": "Embree",
  "triggerId": "56c8967bb8df0f0100d629120",
  "triggerType": "deviceId",
  "deviceTags": {
    "floor": ["2"],
    "location": ["warehouse1"]
  },
  "deviceName": "My Factory Device",
  "flowId": "56c74add04d0b50100043381",
  "flowName": "Power Usage Alert",
  "globals": { }
}

Node Errors

In Edge Workflows prior to GEA v1.35.0, when a Redis Node encounters an error, the workflow will halt and display the error in the debug panel.

In Edge Workflows starting with GEA v1.35.0, as well as Application and Experience Workflows, you may elect to catch the error, store it at a payload path, and continue the workflow execution if the node errors.

Related Nodes

• Redis Trigger