Detect when "Execute all executable nodes" is used?

[iCFO]

I would like to detect when “Execute all executable nodes” is used to run a workflow, so that I can use it to control a conditional flow variable that toggles a “Enable-Disable Flow” within a Component. My idea is to use this method to isolate stand-alone components / nodes so that they are not triggered with the main workflow, and can only be executed individually separate from the main workflow.

[LukasS]

Hi @iCFO!

This might be be a case for the Active Branch Inverter – KNIME Hub. You can connect that to your component you like to deactivate so that is excluded from the “regular” run like so:

Hope that helps!
Best regards,
Lukas

[bruno29a]

Nice one @LukasS , I was unaware of this node. Thanks for sharing

[iCFO]

This node only seems to enable the downstream workflow if it is connected to “Inactive” nodes… It doesn’t isolate it from the workflow while still allowing it to be run individually. I would need it to enable or disable the downstream nodes based on whether a node was “actively executed” during the “current execution action”.

This solution seems similar to the “Enable-Disable Flow”. The only way that I can get it to work is to manually connect and disconnect it from the component and remove any “Merge Variables Nodes” that are in place. Either way they require a secondary action by the user, which is what I was trying to avoid.

[iCFO]

Concept of what I am trying to achieve / use cases.

The reason that I am attempting to “Isolate” nodes from execute all… I would like to accomplish a “temporary” aspect to component configuration nodes to handle one time actions. Changes to that configuration node’s settings would only effect the next execution run, and then the node would return to its default value state. This would avoid the inevitable errors and hassles caused by forgetting to return a value to its default state after a one time action is necessary.

Current Projects where it would be of benefit:

Open File Location: The setting to activate this should impact the next “execution”. Permanent settings would cause confusion and possible errors from multiple files opening simultaneously on an “Execute All” run.

Revert settings from backup file: The selection of a backup file should only impact the next “execution”. After that, the component settings should return to normal default and continue to operate from the primary source file location.

Email for review: This one time action would send an email with a summary of changes and a notification that a workflow was ready for review.

(The primary approach to this problem can be found here…)

Return a Component Configuration Node to Default Value after Execution?

Concept of what I am trying to achieve / use cases. I would like to accomplish a “temporary” aspect to component configuration nodes to handle one time actions. Changes to that configuration node’s settings would only effect the next execution run, and then the node would return to its default value state. This would avoid the inevitable errors and hassles caused by forgetting to return a value to its default state after a one time action is necessary. Current Projects where it would be of ben…

[Daniel_Weikert]

Some of those features sound like configurations for jobs on KNIME Server. I do not have access to one so I can say for sure.
br

[iCFO]

I posted my current approach at a workaround on this issue here…

Return a Component Configuration Node to Default Value after Execution?

Concept of what I am trying to achieve / use cases. I would like to accomplish a “temporary” aspect to component configuration nodes to handle one time actions. Changes to that configuration node’s settings would only effect the next execution run, and then the node would return to its default value state. This would avoid the inevitable errors and hassles caused by forgetting to return a value to its default state after a one time action is necessary. Current Projects where it would be of ben…

It basically tests the current config settings against the prior settings, and then only proceeds when a change has been made. This isolates the component from successive executions unless it is triggered by a change to the configuration setting. At that point it only functions 1 time, and then returns to bypass.