Skip to main content

Hopefully easy question: what is the easiest way for me to check if a workbench is running on FME Form or on FME Flow?
On Form, when testing, I want to read the source data from my C-drive. But when on Flow, I want to read the official data uploaded on the server.

You could use an EnvironmentVariableFetcher to fetch the COMPUTERNAME


Or use the FME parameter $(FME_ENGINE).


@ebygomm : That works, but it does require to hard-code the name of the server in order to distinguish it from any user machine. It wouldn’t be portable across different servers though (not that I had plans on doing so!)

@nielsgerrits : That was my initial solution as well: checking if any of the FME Flow Parameters has a value. The only issue was that if you check it, it exposes that flow parameter asking for a value at runtime. But I managed to avoid that by putting the AttributeCreator / ParameterFetcher inside an embedded custom transformer.
And because this solution distinguishes the software instead of the machine, it’s got my preference.

Thank you both!


Different approaches possible for this stuff. I know some use config files. We use a choice parameter for environment (Dev/Test/Prod) combined with scripted parameters and the parameter FME_ENGINE to do this. What this does is:

  • If workspace is run on fme server test, it uses the test parameter.
  • If workspace is run on fme server prod, it uses the prod parameter.
  • If workspace is run locally, it will use the environment choice to choose the parameter. (local, test or prod).

This way, you will never have to change anything in the workspace when publishing to test or prod, it will automatically choose the right parameter. Also, when developing, it is possible to easy switch between dev and test. And in the case of an issue, it is also easy to debug what is happening in prod.

Sample workspace attached.


@nielsgerrits - have you looked at using deployment parameters instead now they’re available? I’ve not had chance to fully test that approach yet


@nielsgerrits - have you looked at using deployment parameters instead now they’re available? I’ve not had chance to fully test that approach yet

No not yet, I’m not sure when this was introduced but I believe our server version is not new enough for it. Also our current approach works really well for us.


Reply