I am asking for Safe Software to develop a best practise in FME for moving workbenches scripts through Dev/Test/Prod. A quick search has not found this best practise. We all do this (or should): build a script in Dev and/or Test enviornment, then move to production. Each time, I grab the .fwm from Dev/Test and transfer it using fileservices to PROD. Then reconfigure and run. It's easy, but has a risk of error. Other users have suggested python scripts, ini files etc to allow configuraiton to be set by environment, so each script doesn't change. WHich is very clever, but still an add-on that itself has risk - does the python script have error handling? How do we know it worked? What if my python skills are very low? I bet the smart people at Safe can figure this out. It literally might save the world one day.
A best practise for moving workbench scripts through Dev/Test/Prod
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
My take is that the best practice solution is to use the FME Server projects functionality for this:
https://docs.safe.com/fme/html/FME_Server_Documentation/WebUI/Projects.htm
From the documentation:
The primary benefit of projects is the ability to migrate them between FME Servers. This feature is especially useful when deploying an FME Server scenario through the enterprise life cycle, from development to testing/staging to production.
- Participant
Since I want to use multiple version of a workbench at the same time (e.g. local development, dev, acceptance test, prod), the in-built version control doesn't quite suffice.
I'm currently deploying the same script with different names (e.g. scipt_dev, script_prod) such that different environments of my application can call their own version of the script.
Updating is currently done by publishing from the desktop version manually. We're going to try using the rest api soon to automatically push the workbench with the correct git tag to the correctly named workbench during deployment.
The relevant parameters are set from FME server parameters, so updating those is not required when uploading with a different name.
That sounds like a slightly different scenario, I'm guessing you're looking for something like continuous integration?
I believe the official stance from Safe is to avoid using the REST API to publish workspaces, as the publishing wizard does some additional stuff with the workspace before publishing which the REST API doesn't. It might be prudent to contact Safe support first, just to be sure to avoid any surprises.
+29- Enthusiast
I agree with @david_r in that using projects sounds like your best bet, unless you're ta
I'm creating a "best practices" document, and one of the things I found while in my research and thinking about workflow ease is that it's easier to keep all the readers/writers (dev/test/prod) in the same workflow, but just disable the production ones when you're in test and then disable the test ones when you're in production.
+40- Contributor
You duplicate all of your readers/writers? Doesn't that get messy, particularly when there are many featureReaders/Writers scattered throughout the workflow?
My process has generally been to create a set of private parameters for the things that change between environments, and then use concatenated parameters/attributes to build the full path.
So I would have something like
$(ServiceRoot)
$(RootDir)
So an HTTPCaller might have a requestURL like $(ServiceRoot)/a.svc/rest/b
and a Reader\\Writer might have a dataset like $(RootDir)\\dir1\\a.txt
Then all I need to do is change the parameters, when I move between environments.
For some webconnections, I don't even need to do that, just make sure that they are already present on FMEServer, each with the appropriate settings for that environment.
Sounds slightly risky, having to manually reconfigure the workspace before each deployment.
I would rather recommend the process outlined by @jdh.
+29- Enthusiast
@donatsafe I have found the BEST and most intuitive method that NEEDS to be in literally EVERY SINGLE PRODUCT is from your fellow Canadian friends over at Geocortex/VertiGIS: https://www.youtube.com/watch?v=haYMJHjt2uA It just makes sense and is super intuitive and would potentially require only 1 server. Could potentially see customers though where it might make sense for them to specify a server for development, a server for testing, and a server for production logging in through 1 url.
+11- Safer
Hi @runneals, Thanks for sharing this video! There is definitely a lot we can learn from their implementation. (I think you've mentioned Geocortex to me before, seeing it just make it so much more clear). Cheers, Xiaomeng
+11- Safer
Hi @grahammorris, @arjanboogaart,
We are kicking off a project to improve our understanding of our users' needs and challenges, when it comes to managing different workspace versions. We would love to chat with you. Your input will have a direct impact on FME's future.
If you have 20-30 minutes to chat between April 13th - 15th, please pick a time on this form.
In addition to helping us shape FME's future, you'll also be taking part in a fun Safe tradition: "Innovation Daze". As some of you may know, every year around this time, Safers spend a week working on projects they normally don't have time to work on. Many of FME's great innovations are results of the work we do during "Innovation Daze". See this blog, if you want to learn more about this tradition. It's Innovation Daze at Safe this coming week. And, one of our projects' goal is to better understand our users' needs and challenges around workspace version management. So, by talking to us, next week, you'll be joining us in this fun Safe tradition!
(Sorry, @runneals @david_r and @jdh for possibly spamming your inbox.)
Login to the community
No account yet? Create an account
An FME Account is required to contribute
LoginEnter your E-mail address. We'll send you an e-mail with instructions to reset your password.