Return a Component Configuration Node to Default Value after Execution?

I have a Boolean Configuration Node in a Component that needs to be turned off after execution. It is a standalone component that needs to return to its “Disabled” setting to avoid being triggered by “Execute all” when the main workflow is run. Any way to avoid remembering user setting changes to that individual node, or trigger a reset to the default value of a configuration node upon execution?

Hey @iCFO (again :wink: )

Sorry, I’m not fully understanding what you are trying to achieve here - why use a configuration if you want the boolean to be false all the time? There is the Variable Creator – KNIME Hub for constant flow varaibles :slight_smile:
image
If you connect that to the last node of your workflow that you want to have executed, you have that false boolean available.

But this is related to your other topic, right? So maybe your case is resolved with the active branch inverter already?

If not, please let me know!
Cheers,
Lukas

1 Like

Hello @iCFO and @LukasS,

seems both topic are coming from a use case described in this topic?

Which, to be honest, I don’t understand… But solving that one would maybe make this and linked one not needed?

Br,
Ivan

2 Likes

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 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.

(My other question where I was trying to “Isolate” nodes / components from being run via “Execute all”, while still allowing them to be run individually is an alternate approach to accomplish this same challenge.)

2 Likes

Ah, so basically you want to execute a component to get result A (read backup, sendemail, …), then execute the node again to get Result B (read default, no email, …), without touching the configuration of the component, right?

I would argue that there can’t be an easy solution there: this is against the concept of KNIME itself. It sort of breaks the “deterministic” and self documenting nature of a Node (…which components sort of are) in that you execute a node with the same input twice, without touching the settings, and getting different results. This is why its not easily achievable to let the components logic change the settings of the component itself: its a conceptual break (in a way, you try to create a circle in your workflow).

I’ll think of how you could actually still pull it off and will answer if I get an idea :slight_smile:

Greetings,
Lukas

2 Likes

I knew it would be a challenge. My dynamic workflow needs and User Interface approaches are likely pretty atypical vs most users. My next approach is to do a manual change to the underlying code via regex replace on the node’s “settings.xml” file for that specific configurations node at the end of the process to return it to the default value. It is basically my nuclear option! :rofl:

1 Like

No luck… It appears that the “settings.xml” files don’t hold the active node configuration settings. So much for the nuclear option!

1 Like

I think this challenge would likely come down to writing custom versions of the configuration nodes that listen for an execute event and trigger a settings overwrite with the default values, assuming that is even possible…

Hopefully someone will come up with a solution for this. The ability to easily handle isolated one-off tasks within a larger workflow would be a really powerful tool.

1 Like

No luck… It appears that the “settings.xml” files don’t hold the active node configuration settings. So much for the nuclear option!

Pretty nuclear indeed :sweat_smile: this probably won’t work since the settings are loaded into RAM when you open a workflow… tinkering around there would be next level nuclear, I guess :wink:

Maybe there is a less hacky way - what about working with good ol’ sentinel files? You could create an (empty) “file_opened.lock”, “email_sent.lock” or “backup_read.lock” file (maybe in the workflows data?) area whenever the one time action is completed. In the workflow, you can use a “list files/folder” node and a case switch combination to select the respective branch. To trigger the action again, you could delete the “*.lock” file. Or you have a string configuration with which the user can define the name of the lock file - whenever this changes (and the lock file does not exist), a “reset” is triggered. Or a boolean config that whenever is toggled triggers the one time action… What do you think?

1 Like

I’m not the KNIME sales team but doesn’t KNIME server / web portal essential solve this? every execution of a workflow happens with the default settings. The user in the web portal can before the run, if he needs to, adjust the settings and then execute the workflow. If he needs to run it again it will load with default settings again. (because running create a copy of the “template” workflow).

of course this poses other problems like file access and the pesky “open excel after execution” thing.

The real answer is probbaly to code a proper web application that may use KNIME workflows in the background via REST calls to KNIME server (or just code everything and don’t use knime). I really like KNIME but it’s not an “application framework” and extensive user interaction and business rules scream for a custom application and not a workflow tool.

1 Like

I will eventually migrate to server, but in the mean time I have to creatively push the desktop version as far as I can take. (I am transitioning our system over from Alteryx)

I had a much simpler solution. Rather than base the operation on the Boolean configuration value itself, I am going to log the prior setting / compare the 2 / then base the operation on a “change in the value”. That way any change represents a 1 time action! I will try it out today.

2 Likes

Hi @iCFO
I am not sure if this can help… but aiming to handle logical switches, I frequently use ‘Empty Table Switch’ in my workflows as it is easy to create a condition of this type and shoot an empty value; then generate two different workflows and collect the resolution with an ‘End IF’ node.

2 Likes

@iCFO
would be really interested in your solution. Can you share the workflow afterwards?
br

1 Like

My last strategy worked. I logged the prior config setting to a relative path table file and then used a formula to calculate when a change had been made. I put the component up on my public hub as well. Here is my initial solution.

Relative Excel Opener.knwf (153.0 KB)

3 Likes

My goal with the Boolean Widget node was to force an auto re-execution on changes to the config settings, but I haven’t been able to pull it off without breaking the boolean configuration node input yet…

FYI - The flow variable is not necessary except for timing the file open at the end of “execute all” runs. It works fine as a standalone node if you execute it after each change. If I can get it to auto re-execute on close of the configuration window, then it will 100% be isolated from “execute all” runs.

I think that I may try customizing a version of the Boolean Configuration node by adding the re-execution code from the Boolean widget node to get to a 100% standalone / 1 time event node setting that was restricted to solo execution. That way saving a change would auto trigger re-execution and then immediately place it back into bypass mode.

In the mean time, I just added the “control-ok” execute on config close shortcut to the node setting instructions. Works fine for me during the buildout. Thanks for the help brainstorming these workarounds!

1 Like

Hi @iCFO

I am not exactly sure what the node does and if it really fits your problem, but maybe worth checking it out: Kill Configure – KNIME Hub

4 Likes

Thanks @Alice_Krebs

That seems to be another way of disabling downstream nodes similar to the “enable-disable node” approach that I used in my component.

I think that the cleanest solution will be for me go ahead and tackle modifying the Boolean configuration node by adding a re-execution / return to default value listening event. I will try to add the widget Boolean re-execute upon a change of the value (with the additional test that it does not match the default value), and then apply a change of the value setting back to default. That will clean up the user interface dramatically so that settings always represent their action, and ensure that events are 100% isolated from execute all.

The more that I have thought about it, the more important this node functionality is in other areas for efficiency / user error avoidance and user friendly controls.

Send out summary reports via email

Write changes to CRM

Email software support representative - In the event of a connection issue or export error from a platform.

Email client contact to verify data methodologies

And the biggest ones…

Write changes to local database & and write changes to server - Operating these as standalone 1 time user triggered events will ensure that users can freely experiment with dialing in formulas and settings without the risk of accidentally overwriting data with errors until after it is reviewed and tested. I think that I will also add a simple “password” test as well for certain actions. I know that it would not be “secure”, but it would serve as a warning not to proceed and help deter quick thoughtless actions by less proficient users.

I will share the node if I can pull it off.

2 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.