I have a workflow on knime server (4.5 on linux) which contains linked meta nodes. When I select the workflow in the web frontend I get an Load Error with http response code 403. The URL to the meta node displayed in the error message is correct. If I use the URL I can retrieve the meta node manually from my local machine (since I am authenticated I guess), but the server seems not to be authenticated against the rest endpoint.
Is there any specific configuration which has to be set, so that the server can retrieve linked meta nodes? I have the server and executor on the same machine, but I had to set "com.knime.server.canonical-address" in the knime-server.config since the server URL was resolved incorrectly before.Ā
Can you please post the URL of the metanode? (At least the general URL format). Is the metanode template stored on the same server as your KNIME Server? We currently have a ticket open for problems when executing a workflow on server A that uses metanode templates stored on server B. Can you please verify whether this also applies to you?
I have been receiving a very similar error, that could be related to either of the two problems you're mentioning.
I have been testing WebPortal with two accounts (mine, and a separate one for testing whether it will work for our other users). I'm using the latest version of KNIME Server, 4.6.1.
When I execute a workflow on my account, as the author, it works fine. When I execute on the second, takes a long time to start, and then it fails if there are any linked metanodes that are on the same server -- the error message is "Could not update linked metanodes in [my workflow's name] Server returned HTTP response code". The second user used to have different permissions to the shared metanodes folder, but I updated the folder permissions so now both accounts have read & execute access -- however, the problem did not go away, it still fails to execute with the same error.
IMHO I was very surprised it is evenĀ checking to update linked metanodes -- this is usually something I do interactively when editing the workflows, rather than something I'd expected the server to do on ever execution of a workflow. Is there any way to turn that off?
Is there any additional information about this type of issue and workarounds?
Hi there, Itās possible to disable checking linked metanodes for updates upon execution on the server. The option in knime-server.config is com.knime.server.executor.update_metanodelinks_on_load=
by default the option is set to false, if it is set to true in your case, setting it to false should solve that issue.
Hi Jon ā this was exactly what was happening. I donāt recall editing this file before ā itās possible an old version of KNIME server may have had different defaults. Anyways, Iāve changed it to āfalseā instead and so far in all of my testing the workflows are running great again. Problem solved!
The xxx.xxxx.xxxx.xxx is the IP of the server (it is not showing 127.0.0.1 or localhost).
I checked and com.knime.server.executor.update_metanodelinks_on_load=true is set. Setting it false resolves the problem. But I guess then I have to update the linked nodes manually if I change any of them.
I just tried to reproduce this. I had no problems executing workflows with metanode templates on the WebPortal, and I was also able to update a template when executing.
To investigate this further, can you please send the full error message you see when you try? If there are any entries in the server logs (most likely in localhost.yyyy-MM-dd-log)
i really like the idea of shared metanodes, but I struggle a lot with them.
My set up are two server (productive and test server), which should use the very same workflows and accordingly the same shared metanodes. I have in each server a folder SharedMetanodes in the higest level of the workspace containing the nodes and the same structure locally.
When I create a workflow locally I just drag the metanode from my local SharedMetanode to my local workflow, but after uploading the workflow the webportal says the node canāt be found on the server.
Could you please provide me with a step by step explanation to make sure the meta nodes are found and working locally and on both server after used from local repository.
When you drag a metanode from your repository to a workflow, you create a link to the template. Since you take the template from a local workspace, the link points to a local file as well. I.e., it will not be accessible from a workflow run on a remote server.
The key point is that the template has to be in a location that can be accessed from the server. In your case, the recommended procedure is to develop your metanode locally, and then save it as template in a location on the server. You would then drag the template from the server repository to use it in a workflow, which then can be uploaded to the server.
thank you for your quick answer. I think I tried before what you suggested. If I remember right, the result was that it worked this way only on one server (server 1), but the same workflows on the other server (server 2) complained about missing nodes and pointed in the error message to the server 1.
What I would expect is that if I drag a node locally from my repository folder, it will create a Mountpoint relative path like knime://knime.mountpoint/SharedMetanodes/path_definition_helper and the behavior is that it is never relevant if I am on the server or working locally, since the files are always available under this path.
Please help me to accomplish to use the same workflows (including the shared metanodes) on two different servers without creating a second set of the same workflows by hand and replace all shared metanodes.
Thanks a lot
Lars
PS: I just discovered the (new?) option in the menu of a shared metanode which allows to change the path to a mountpoint relative path as needed. With that change both server do not complain anymore - it just works as expected.
Where do you find the menu and how did you manage to change the mountpoint? What knime server and desktop versions are you running?
We have similar problems with scheduled workflows that uses wrapped metanodes deployed to a server. We are upgrading the server and have installed a new version as a test server, and copied over the workflows. These workflows wonāt start on the test server because of the link to the original server.
I am working in KNIME 3.5.3 at the moment. The menu is shown in the local KNIME installation if you right-click on a metanode and then select the submenu āmetanodeā (ā> change link path)
The way it does work for me is:
save the metanode as shared metanode (template) in a local folder - if I am asked I select āmountpoint relative pathā
I make sure that all servers have the same structure of folders and files as my lokal KNIME (regarding the shared metanodes and the workflows)
Each time I want to use a shared metanode from my local folders as a new node in a workflow I have to make sure I manually change the path via the option menu from an āabsolute pathā to a āmountpoint relative pathā. (These option is not provided if you drag the node from the server in your workflow)
I hope this helps
Lars
PS. I had to replace all nodes/path in all workflows which used them
PPS. We struggled a long time with a second issue: the server URL which was addressed by the KNIME server itself in order to find the shared metanode differed slightly from the one the server was actually using. Thats why beforehand nodes were not found even if dragged from the server and only used in one workflow - KNIME support figured that out.
Thanks for this, I think I understand what you have done, but this option is not available for server deployed template nodes,
I show what I mean by the screen shot. Iām looking at a wrapped metanode template āError loggerā dragged down a server, RiskKnime2 -> Nodes -> Error Handling.
The Change Link Type in the submenu is greyed out. This is for knime desktop version 3.5.3, the same as yours.
We are using RiskKnime2 to test our workflows for compatibility to 4.6.5.
We took a copy of the workflows (running zip to copy from the RiskKnimeās worfklow folder to the RiskKnime2ās workflow folder).
When RiskKnime2 tries to load the copied workflows we get the following error
When we dug into this we find the server deployed template nodes have an absolute link to the server URL http://HALvKnime.xxx-xxx.co.uk in the xml files for the template nodes.
Have you seen this and is there a solution you are aware of?
what you describe looks like what we were facing before with a similar setup. That is why I did the above steps instead. What did the trick was to replace all nodes from a !local! resource (drag the node from the server to a local folder and from there to the workflow to replace the old one - then you get the option I mentioned before). Its hell of work to do, but it finally worked for us. All I can say here give it a try on one example workflow. I am not aware of a faster way, maybe KNIME does know one.
Iāll throw my 2c in here as well. Similar sounding issue - I have a significant number of metanodes that I am tasked with maintaining. I need updates to them to be pushed to workflows I intend to run via the REST API. When I try this (or even normal remote execution) I get an error that says no template found (log below).
com.knime.enterprise.client.filesystem.FileSystemCoreException: Could not update linked metanodes in NamePrefixParse_tests: Can't read metanode/template directory D:\knime_server\workflow_repository\runtime\runtime_knime-rmi-50101\...<path_to_template> at com.knime.enterprise.client.filesystem.KnimeRemoteWorkflowInMem.loadWorkflow (KnimeRemoteWorkflowInMem.java:190) at com.knime.enterprise.client.filesystem.KnimeRemoteFileStore.loadWorkflow (KnimeRemoteFileStore.java:558) at com.knime.explorer.server.ServerExplorerFileStore.loadWorkflow (ServerExplorerFileStore.java:708) at com.knime.explorer.server.internal.view.actions.ServerExecuteAction$1.run (ServerExecuteAction.java:242) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run (ModalContext.java:119)
Hey Aaron, it might be no answer for you, but you just raised a question: If I have established a connection between the workflow and the shared metanode template,both stored on the server and I overwrite the shared metanode template on the server - are then all workflows automatically updated if excecuted? I am asking since I always download the workflows to get the local update option and then I upload it again. If it would work like described above I would finally understand why I need the templates on the server and it would save me a huge workload.
That is what I am assuming/hoping is supposed to happen. It makes sense that they would support this in the case where shared metanodes are deployed to support a set of KNIME Server webservices. It would be a big pain to resync each workflow manually.
This doesnāt currently seem to work but with Jonās comment about the server option it seems like this is something that they have thought of. Maybe there is a bug? Letās see what the KNIME folks say - hopefully we are doing something wrong.
Thanks for the detailed use case report. I think that @RolandBurger has been in touch via email to discuss a bit further. In short, your use case isnāt something that we can easily deal with at the moment. Iāve added a ticket so that we will look into possible solutions, and if youāre happy to be contacted, weād like to run the proposed solution by you once we have it, thatās something for us to address post December 2018 release.
In the meantime, there is a hacky solution to edit XML files in repository once it has been migrated, but before the server will be restarted. Itās not pretty, but itās probably the best option at the moment when there are more than a handful of workflows to migrate.
The default setting on the KNIME Server is not to check for updates. It is possible to enable that globally for all workflows on the KNIME Server by adding:
com.knime.server.executor.update_metanodelinks_on_load=true
to the knime-server.config file in the config directory of the .
In that case then all metanode links in a workflow are updated before the execution of the workflow.
