I wonder if there is any way (or let’s call it maybe a “best practice”) to create a clean interface to a (wrapped) metanode.
This is my situation: I want to encapsulate a certain functionality into a metanode and share it with other people. However, the functionality of my metanode requires certain data/columns to be present in its input stream. How can I ensure this?
(In object oriented programming this would be an interface definition)
Maybe I am even approaching the problem from the wrong side and there is a different way to do this within ETL tools…? So I would appreciate any comments on this!
Good question.
I think the best thing you can do to ensure the metanode is used properly is to clearly document the requirements in the metanode description.
If you want to programmatically check the input table(s) you can use a Table Validator node. You can make the metanode fail if the table doesn’t meet your requirements.
If the metanode fails, there is currently no mechanism for displaying a user-friendly error message to the user of the metanode (this would be a nice feature for KNIME, but probably more complex to implement than it sounds). Instead, the user will need to open the metanode and identify the failing node and the reason for failure.
This is a good idea. You can use the nodes Try and Catch Errors which can be found in Workflow Control/Error Handling to catch the failing nodes and display an error message. This way you would not have to open the metanode and identify the reason for failure.
@Jeany Yes, you make a good point. I also recognized Try Catch as the best way to implement a user-friendly metanode error reporting mechanism. But I hesitate to recommend it because it’s complex. Attached is the solution I came up with (still being tweaked). It’s not what I would call an elegant solution. It’s probably better described as a hack (but probably the only elegant solution would be native support from the KNIME app). It requires the metanode designer to fill out an error translation table that identifies the name of the failing metanode (but can’t seem to specify node ID#), the exact error message, and the corresponding friendly message.
In the end, you cannot show an error message in the same way other nodes do. What I did was inactivate the outport, write the friendly error message to the console and rename the outport to the friendly error message.
An alternative is to alter the outport table to show a simple table with the error message, but I disfavor that method.User Friendly Metanode.knwf (42.2 KB)
