An "Application Context" for Knime

In Java (specifically using the Spring Framework), there is the concept of an Application Context. This would typically contain singleton classes related to configuration of your application.

Is there something similar in Knime? My typical use case is the database connection. Consider a workflow with multiple nodes (say 20), 10 of them need a database connection, 10 others don’t. As it is at the moment, I need to link the database connection node to the 10 nodes that need it. Or, if I want to avoid having a node connected to 10 different nodes across my workflow (since this might clutter the workflow), I would have to pass the database connection along my different metanodes so that whoever needs it can use it.

If there was something similar to an Application Context in Knime, I could put this node in the “application context” of my workflow, so that any node that needs this node, would access it from there somehow without having to explicitly making a connection that could clutter my workflow.

Is there something similar in Knime? This would significantly declutter my workflows as well as make such nodes that are constantly being re-used across different nodes easily available and easy to use.

Hi @alanvella,
Welcome to the KNIME Forum! I actually also wished for such a feature a couple of times already! You are definitely right that this would be useful. Currently, we do not have such a feature in KNIME. However, I also think a bit of the understandability of a workflow may be lost if some input ports had some magic invisible input that comes from the workflow context. I also think that this would require quite a lot of changes to the codebase of KNIME core to make it work nicely. The context had to be basically an extra workflow that is executed before the main workflow, offering some kind of node similar to a component output that I can connect all the contained nodes to. Then those outputs would need to have names that I could then reference in my normal workflow. I terms of debugging workflows this sounds a bit like a nightmare :smiley: How would you envision the context to be built and selected?
Kind regards,

1 Like

Hi @AlexanderFillbrunn, sorry for the late reply but I only just saw this today! Thank you for answering back.

To be really honest, the more I have been using Knime, the less I am feeling the need for what I had initially requested :sweat_smile:. I also agree with you that it might actually hamper the understandability of the workflow.

If I had to think about how such a thing could look from a user’s perspective, this is one simple way I thought of:

Every workflow you create has a context workflow that is created for you automatically. The user has access to such a context workflow. In this context workflow, he can create standalone and independent “context components”. Context components are normal components like any other, but the fact that they reside within a context workflow makes them context components.

The main restriction is that no two “context components” within the same context workflow can have the same type of outputs (i.e. there cannot be two context components within the same context workflow that, for example, both have 2 data outs).

Any component in your normal workflow can make use of any of the context components found in the context workflow linked to that workflow.



Hi Alan,
Thanks for the detailed description and glad to hear you are getting more familiar with KNIME :smiley:
I think while for professional users this solution might bring a couple of benefits, new users would probably be quite confused by this “magic”. It would also require quite a lot of changes, especially on KNIME Server, e.g. when an error occurs in either the workflow or the context workflow, or when comparing workflows. For this reason I believe we won’t have something like that in the near future. But that’s just my personal opinion. Maybe someone else has an opinion on this?
Kind regards,

1 Like

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