Node Variables are attached to datasets, which are represented by nodes in the Data Pipeline. Node Variables must be inserted into the queries and scripts configured for those nodes in the pipeline. Once inserted, end users will be able to alter the underlying queries and scripts by passing in different values for the Node Variable.
The values that get passed into these underlying queries need to be constrained so they don’t break things. This is handled through the concept of Variable Constraints.
The primary reason for using Node Variables is interactivity. Static queries produce static data, which in turn create static visualizations. End users often want to alter the way data is filtered, adjust time ranges, or compare different metrics. Essentially, end users want to interact with data. Variables, along with Variable Constraints, enable that interactivity.
Adding interactivity starts with the queries and scripts used inside of feed and transform nodes in the pipeline. In order to be interactive, these queries and scripts need to use variables. We refer to these types of variables as “Node Variables”, because elements are visually depicted in the data pipeline as a hierarchy of nodes.
The syntax above will return all records that have a value of “Arches” for the “Park” attribute (column). This is great if you happen to be interested in a park called “Arches“, but that is all this query will ever return. What if you are interested in a different park? What if you want the user to be able to choose whatever park they want?
When an administrator desires interactivity, they will need to click the Insert > Node Variable button. The example below shows what the resulting query would look like after replacing the static value “Arches” with a node variable named “ParkName“.
After clicking the Insert Variable button, the Choose a Variable dialog will appear. This dialog lets you reuse variables that have already been created for the current connection.
Node Variable Scope
Adding a new variable is simple. It consists of adding a new “Variable Name”, and then mapping that name to an existing “Variable Constraint”. A bulk of the configuration for Node Variables is contained in the Variable Constraint, which means that most of the configuration is global. Only the name is bound to an individual node.
edgeSuite v3.2 introduced a new “safeNodeVar” syntax to use inside of SQL queries. This new syntax protects against malicious SQL injection.
If safeSubstitution is turned off, then nodeVars will behave the same as they did in previous versions of the product. The old concept of a “nodeVar” offers a lot of flexibility, however unbounded STRING values passed in for existing nodeVars could leave a system vulnerable to a SQL injection attack.
The following list provides various scenarios regarding upgrade logic for existing archives:
For archives using the deprecated “nodeVar” syntax, which is anything created prior to the edgeSuite v3.2 release, an administrator can run a command to update all queries so that they are protected against malicious SQL Injection. Running the command below will enable the new “safeNodeVar” syntax on all SQL queries.
bin/edge.sh config -s global -k pipeline.safeSubstitution -v
The following table provides a summary of how edgeSuite v3.2+ protects against SQL Injection: