I have a workspace that is generating a couple of shape files returned in a zip file through datastreaming.
It works as expected in dev, test and production environment but not in education. In education it only returns one of the files unzipped.
I have confirmed that it returns several files and I have resubmitted the exact same workspace that works in the other environments.
What other parameters can cause this? Some set up on the education fme server?
Hi @hannesfpaulin, just to confirm, are all of your FME Server instances running the same version of FME Server?
Hi @hannesfpaulin, just to confirm, are all of your FME Server instances running the same version of FME Server?
Update, I'm seeing this behaviour on FME Server 2018.1 and newer, so it looks like something changed in the Data Streaming service to change its behaviour from returning a zip file if multiple output files are created to returning one of the files unzipped. We're investigating this on our end as this behaviour should not have changed.
Update, I'm seeing this behaviour on FME Server 2018.1 and newer, so it looks like something changed in the Data Streaming service to change its behaviour from returning a zip file if multiple output files are created to returning one of the files unzipped. We're investigating this on our end as this behaviour should not have changed.
Hello Laura. Thanks for confirming that. Yes all servers are FME Server 2018.1.1.1 - Build 18578 - win64 .
I have found a temporary solution which is to publish the script from FME 2015.1 workbench to FME server 2018. But if I publishing it from a 2018.1 workbench it stops working. Meaning we can't remove FME 2015.
Update, I'm seeing this behaviour on FME Server 2018.1 and newer, so it looks like something changed in the Data Streaming service to change its behaviour from returning a zip file if multiple output files are created to returning one of the files unzipped. We're investigating this on our end as this behaviour should not have changed.
Any updates on this one?
Any updates on this one?
Hi @hannesfpaulin, this issue is atop the list of bugs right now and hopefully we will have an update for you soon.
If you would like to receive more timely updates on any progress, please contact our Support Team (Live Chat, or Submit a Case) and reference this Q&A and FMESERVER-13111 - you can be linked in our issue tracking system and receive notification upon resolution. (We will update this Q&A thread with comment as well, but it is more reliable to have a support ticket open!)
Hi @hannesfpaulin, just to help better understand your scenario, what does your overall workflow look like for this? What is the reason you are using the data streaming service instead of the data download service?
Hi @hannesfpaulin, just to help better understand your scenario, what does your overall workflow look like for this? What is the reason you are using the data streaming service instead of the data download service?
@lauraatsafe how is that relevant? Shouldn't it work to zip files with data streaming?
@lauraatsafe how is that relevant? Shouldn't it work to zip files with data streaming?
@hannesfpaulin It should work for zip files, for sure. We're not actually aware of too many users who use Data Streaming for zip files though. Data Download is the one that's used most frequently, so I was interested in learning a bit more about how you were using it in this context.
Through testing we have discovered that this affects the Folder User Parameters.
An available workaround is to include a trailing forward slash character / in the value for the parameter when it is published to FME Server – please note that a backslash \\ character will not resolve this issue.
For example, instead of "C:\\temp" the value should be "C:\\temp/".
If you need assistance implementing, or have concerns with, this workaround, please contact your account manager or create a support ticket so that we can help you. It will be helpful to reference the issue number FMESERVER-13111 and the URL of this Q&A thread.
I recognize that this is going to be a pain and extra overhead, so if it affects many of your workspaces – I highly recommend reaching out to us through the means mentioned above.
Through testing we have discovered that this affects the Folder User Parameters.
An available workaround is to include a trailing forward slash character / in the value for the parameter when it is published to FME Server – please note that a backslash \\ character will not resolve this issue.
For example, instead of "C:\\temp" the value should be "C:\\temp/".
If you need assistance implementing, or have concerns with, this workaround, please contact your account manager or create a support ticket so that we can help you. It will be helpful to reference the issue number FMESERVER-13111 and the URL of this Q&A thread.
I recognize that this is going to be a pain and extra overhead, so if it affects many of your workspaces – I highly recommend reaching out to us through the means mentioned above.
Hi, I was wondering if this issue is resolved in 2020? I just have the same problem both using 2018.0 and 2020.0.2 servers. I want the streaming service to return zip-files as the user clicks on a link on my FME-made ATOM-feed.