Since we migrated from KNIME Analytics 4.2 to 4.5 with the appropriate compatible version of KNIME server, we observed a strange behavior on the web portal for the file upload widgets:
When the default files are used, after clicking the “Next” button, the workflow is immediately set to “executed” stage. In order to run the workflow appropriately on the server all files have to be uploaded again even when they are the same as the default files. This is annoying, particularly when there are files in the workflow that rarely change. It was different in the previous KNIME version.
Is there any way how this behaviour can be avoided, i.e. that the workflow could be executed correctly already with the default files (provided they exist)?
Hi @sscholz ,
I just tried to reproduce the behavior you describe with this very small workflow on KNIME AP 4.5.2 (Server 4.14.2):
When I click “Next”, I get the output of the default file on the second page, without having to upload the file again.
Does that example come close to your workflow? Do you mind sharing/rebuilding a minimal working example to illustrate the issue?
I could imagine that you address the file with an absolute link in the File Upload Widget, which is then not necessarily accessible on the KNIME Server. In my example, I referenced a file in the workflow data area via
knime://knime.workflow/data/test.csv which then gets uploaded together with the workflow and is accessible from the Server.
Could that be the case and if so, could you use relative paths in a similar fashion?
thanks for the quick response…and it’s exactly as you indicated. I am using an absolute link. The reason is that I am referring to files on my or the users local machine. Some of these files do not change when a workflow is reexecuted. Hence, it would be good of the full path can be stored and used, but that seems to be difficult. Or is there an alternative possibility that avoids saving a file on the server? I modified your workflow to reproduce my problem with the absolute link.
FUW test absolute link.knwf (23.5 KB)
you’d have to make sure that the Server has access to the file at runtime - using a file stored on the local machine of the user like
Z:\dummy\test.csv is indeed rather difficult, since the server doesn’t have access there.
I would suggest to either
- store the default file on a fileshare where the server also has access to, and then use e.g. a SMB Connector and the respective Reader Node to read the file. With a construct like the following:
you can make sure that an upload still works, as then this is passed along. Here is the modified workflow.
- or you upload the workflow with the reader that reads the default file already executed - this way, the default data will also be available at runtime, but the data is again stored with the workflow. Is there any reason why you don’t want the data to be on the server?
Would any of this help you?
thanks for the suggestion. Storing of files within the workflow (and uploading it partially excecuted) is not an option as occasionally the user have to replace the file by a new one and different users need different files.
The smb option could work but seems rather complicated to me. But I will try to find out the syntax for or instutes file share.
And I am still wondering why this was not an issue with the previous version of the KNIME server. Apparently in the previous version apparently the file path was stored so that default files could be used without problems.
indeed, I’m now also interested in how it used to behave - maybe there is something we can learn. I’ll investigate by installing a KNIME Server 4.11 and try the example there. I’ll come back to you!
the File Upload Widget used to work in the previous version most likely due to a change of the default of the local file system access from
false. This allowed the workflow to access your default file, which was available on the server under e.g.
Z:\dummy\test.csv. This happened due to security concerns: you generally don’t want a workflow to alter the KNIME Server itself. And thanks to the revised file system handling this setting is generally not needed anymore. You can, however, activate it again, as described in the docs.
Hope that helps!
thanks for careful checking. According to our server admin, the value was set to true already. But we have to investigate this again and provide feedback (will take a bit longer due to holiday season).
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.