Hi @1spatialmary Are you on FME 2017.1?
I might be way off here... but I'll ask you to try this.
Get rid of PYTHONPATH environment variable.
Then in your FME Workspace - FME Options > Translations > Add a new customer Interpreter.
Finally, back in the Workspace Parameters > Scripting make sure the python compatibility is set correctly. This should work for all users then (but I do have one concern that it may not).
Hi @1spatialmary Are you on FME 2017.1?
I might be way off here... but I'll ask you to try this.
Get rid of PYTHONPATH environment variable.
Then in your FME Workspace - FME Options > Translations > Add a new customer Interpreter.
Finally, back in the Workspace Parameters > Scripting make sure the python compatibility is set correctly. This should work for all users then (but I do have one concern that it may not).
. So my suspicion was correct. I was way off. I did a little digging and spoke with our lead developer. The above solution won't work where you want this to affect all users...(to allow you to run this via task scheduler) as it will only affect the current user that sets this. This setting is stored in the HKEY_CURRENT_USER registry.
Although the above would be recommended if you wanted to run the workspace with your current logged on user or set Windows Task Scheduler to user your current logged on user’s credentials it won’t work for other users.
In FME 2017 there are 2 things we set in FME Workbench... the python compatibility and the python interpreter.
The python interpreter setting (in this case a custom python interpreter) is saved in the registry and is for the current logged in user. Meaning it cannot be pushed to the system level where all users would know what python interpreter to use on the system.
The python compatibility can be set in the workspace and thus mobile with the workspace if it were run by a different user or on a different system.
So in this case, one way to get the service account to know what the custom python interpreter is would be to grant a temporarily log in and opening FME Workbench to set the interpreter in FME Options. This would create the necessary registry parameter. However, typically service accounts are headless (a person cannot use the account to log into a system) and thus, would make this step a security no-no (but not impossible).
We are investigating if we could import a .reg file into a service account profile using the Windows Task Scheduler and running a batch file point to the reg file.
The PYTHONPATH will be picked up by FME, however it doesn't matter as FME will make use of the FME Python interpreter as seen in the service account's registry - which says "use FME's Python Interpreter". As you know, this will present a problem if the python your are attempting to run needs to run via the custom python interpreter.
Are you running FME Workbench 2017?
In FME 2017 there are 2 things we set in FME Workbench... the python compatibility and the python interpreter.
The python interpreter setting (in this case a custom python interpreter) is saved in the registry and is for the current logged in user. Meaning it cannot be pushed to the system level where all users would know what python interpreter to use on the system.
The python compatibility can be set in the workspace and thus mobile with the workspace if it were run by a different user or on a different system.
So in this case, one way to get the service account to know what the custom python interpreter is would be to grant a temporarily log in and opening FME Workbench to set the interpreter in FME Options. This would create the necessary registry parameter. However, typically service accounts are headless (a person cannot use the account to log into a system) and thus, would make this step a security no-no (but not impossible).
We are investigating if we could import a .reg file into a service account profile using the Windows Task Scheduler and running a batch file point to the reg file.
Thanks @SteveAtSafe - it's FME 2017.1.0.0 build 17539. I've not got direct access to the environment, so it will take me a little time to arrange it to try these out. I think it's probably best if I raise a support ticket as then I can provide logs etc. and then we can post the findings back here when done
UPDATE: This customers issue turned out being resolved by setting the workspace compatibility parameter to ‘ArcGIS Desktop Python 2.7’ as they didn't really need a custom interpreter.
