I hit a problem when trying to build a component that could take as input multiple conditional branches. I was looking to build a single component that could behave as an “End IF”, but with additional functionality such as logging the details of the flows that came along each branch.
For the purposes of demonstrating the problem though, here is a simplistic example.
Suppose we have the following flow:
In reality, the IF would be controlled by a variable, but here we have it set to only execute the lower flow.
If we wish, we can convert the two Case Converters into a single metanode which would accept two branches and always convert the upper branch to Upper case, and convert the lower branch to Lower case.
But if we decide that instead of a metanode we want to convert to a component, so that perhaps later we can add configuration and share it, we hit a problem:
Although only one input branch is inactive, on the inside of the component it treats both as inactive, and the component is blocked.
A workflow demonstrating this is available on the community hub:
This is the same in both versions of KNIME AP I have tried it in: KNIME 4.7.8 and KNIME 5.3.3.
I believe this is expected behaviour. A component is supposed to behave like a normal node. And a normal node can not be executed if any of it’s input is disabled.
A metanode on the other hand is only a visual grouping of nodes with no further logic added. This means all the branches inside the metanode are independent.
That’s a shame, as I had a cunning plan for building a pair of components that work together like an IF - End If where they would encapsulate the beginning and end of a condition branch, to do some logging or other things.
(i.e. The opening component would contain the If, plus some other logic and the closing component would contain additional “closing logic” plus of course the End If)
It sounds like this isn’t possible, which is a pity, and the “branch terminating logic” will always have to remain as separate components for each branch, plus an End If node.
What I really need then is some form of “shared metanode” and I guess the closest to that would be “wrap a metanode” as a component (ironically similar to what components used to be called ) for storage on the hub, and then expand it back to a metanode on the target workflow so it can work, but of course its a faff, and also doesn’t get the benefits of updates.
No matter, I’ll move onto to thinking about something else. thanks again.
Perhaps you could incorporate the if switches inside the component, but control them via flow variables or via formulas from an additional component input. I have some components that use this approach to expose the IF switch logic controls. The only real downside is there is no visual feedback to the flow/processing within the component, so it requires some testing for confidence.
You can also use something like the Row splitter in a component (instead of IF Switch) to direct the entire table to the correct component output by your IF logic, then pass an empty (or dummy value) table through the other. That way both components stay active and the processing only occurs on the selected branch between them. Then you filter the dummy table (if dummy values were used to avoid errors) when you concatenate back together in the 3rd component. That workaround requires 3 components though…
) for storage on the hub, and then expand it back to a metanode on the target workflow so it can work, but of course its a faff, and also doesn’t get the benefits of updates.