Apologies in advance - this is a long post, as there is a lot in this update, with a lot of new features and versatility added to our Flow Control nodes. As a taster, here is a somewhat contrived example showing some of the new nodes:
The short version:
- Configurable Empty Table Switch
- Configurable IF/Case Switch (Flow Variable Value)
- Configurable IF/Case Switch
- Configurable Crossover (Flow Variable Value)
- Configurable End IF/Case
New Features (See also API section)
- New flow variable conditions for String, String Array, Integer, Integer Array, Long, Long Array, Double, Double Array, Boolean, Boolean Array and Path variable types
- New Port Combiners for Buffered Data Table, Flow Variable and RCSB Advanced Query port types
- Deprecated all IF Switch / Case Switch, End IF and End Case nodes
API - Added 2 new extension points:
com.vernalis.knime.flowcontrol.variablecondition(Variable Condition) - Used to provide conditions to the Flow Variable value based nodes
com.vernalis.knime.flowcontrolporttypecombiner(Port Type Combiner) - Used to allow merging of multiple active ports in Configurable End IF/Case nodes
Now the details… (!)
Firstly, we deprecated all the old IF/Case switch nodes, Crossover, End IF/Case nodes for various port types, and replaced them with 5 ‘Configurable’ nodes which do it all, and more.
This node replaces our popular ‘IF Switch (Flow Variable Value)’ series of nodes which we provide for a variety of port types currently.
There is by default 1 standard data table input, and 2 outputs. Again, the ‘base’ port type can be changed, and individual outputs can be changed to flow variable ports (either from the ‘…’ configurable menu, or from within the node dialog.) Additional output ports can also be added.
Each output apart from the last has a separate flow variable condition setting representing a logical comparison operation. The figure below shows the situation for a node configured with 4 outputs. The ‘active’ output is the first output where the logical comparison is
This is coupled to the new framework for logical comparisons, which allows for additional options for each comparison (e.g. the String comparison in the first and third settings have addition options around case sensitivity, and leading and trailing white-space) - at present we provide comparisons for
Double, along with their corresponding array variants, and also for the new
Path flow variable type. Further comparison methods can be added by implementing the
com.vernalis.knime.flowcontrol.variablecondition extension point - please let us know if you spot any obvious comparisons that we have missed!
This node is an ‘enhanced’ version of a standard ‘CASE Switch’ node (which takes 1 input and switches between 3 outputs), of which we have contributed several variants for different port types, and had requests for other port types previously.
In this node, by default, 1 standard input table port is switched between 2 possible output ports. The node is configurable such that:
- Additional output ports can be added
- The ‘base’ port type or the input and outputs can be changed to any port type
- Individual output ports can be changed to flow variable ports
Additionally, the active port is selected as previously by the value of an integer variable. However, there are now additional options for when the variable is outside the range or available output ports (e.g below 0, or beyond the upper limit of number of ports) as shown:
The default ‘fail’ option is the same as the previous behaviour. There is an additional option to allow negative values to be read ‘backwards’ from the end of the output ports as is the case in Python indexing systems (e.g. -1 refers to the last port, -2 the penultimate port etc)
(Replaces ‘Empty Table Switch’)
KNIME has a standard ‘Empty Table Switch’ node which has 1 input table and two outputs. If the incoming table is empty (has no rows), then the second output is the ‘active’ workflow branch, and the empty table is made available there. Frequently, what is needed in this branch is to use a different table (after all, the input is empty!) which required multiple convolutions of nodes to implement
Vernalis Empty Table Switch node took two input tables. If the first was empty, then the second one was passed through to the second, active output – otherwise, the first table was made available as the first ‘active’ output, as per the original standard node. That solves the first part of the problem, but often something else is required as the second port… – e.g. a database connection port to read a table from only if the first table was empty, or a flow variable port to control a file reader only if the first table was empty.
The new ‘configurable’ version of this node allows the user to change the port type of the second input port, allowing all of these cases to be resolved directly
There are a number of End IF (2 ports, combined to a single port) and End CASE (3 ports, combined to a single port) nodes in KNIME, and in our community contribution for various port types. These nodes take one or more ‘inactive’ workflow branches, along with at least one ‘active’ branch, and produce an ‘active’ output.
The new version of our node can act in place of all of these. The user can change the basic port type, which is then the port type available as an output. The node by default has two inputs, but any number of inputs can be added.
As an additional feature, for some port types (Currently, the standard KNIME data table, Flow Variable ports and PDB Connector query ports - if you need others, let us know - the new API we added allows adding this very easily - or you can implement the
com.vernalis.knime.flowcontrolporttypecombiner extension point yourself!), there are more options available for combining multiple active, making the node considerably more versatile.
This last feature means that the node can also be used standalone as a way of merging ports without them being part of an IF/Case - End IF pair.
(Replaces ‘Crossover (Flow Variable Value)’ node)
This node takes two input ports (in the previous version, these were constrained to be standard data tables, although it would have been possible trivially to add other types as new nodes) Depending on the value of the logical comparison on a flow variable, the two outputs are either in the same order as the inputs, or ‘crossed over’ – i.e. input port 1 is output again as the second output, and input port 2 is output at the first output. All 4 ports must be of the same type, but in this new implementation that type can be selected by the user using the new configurable node feature.
This has been release to the nightly, 4.5 and 4.4 builds this evening. We plan a few further updates in the coming days, after which we will investigate back-porting to KNIME v 4.3 and 4.2.
As always, if you have any comments, suggestions or questions about these nodes, do please get in touch!