If I am understanding the question in the right way you can just run the workbench via batch script. Then you don't have the open and close problem.

Thanks for the suggestion. Technically your suggestion would do the trick. However, I think some of our users would not be that comfortable in creating and running a batch file. Also, they would need to edit the parameters before each run, and would prefer to do this in FME Workbench.

The users wouldn't need to create a batch file, they just need to run it. If you use the fmequicktranlsator.exe with the workspace name as parameter it will show the Quick Translator interface, although it still won't close it afterwards.

Just being curious here: would FME Server be an option for you? Your users will not need to worry about Workbench at all but access the workspace through a web interface.

Yes, you are correct. The users would not need to create a batch file, but they would need to alter the parameters each time before a run. For less advanced users of FME this can be daunting and may introduce more scope for error than using the FME Workbench interface.

Thanks for the suggestion. I am currently evaluating FME Server and whilst this would also avoid this issue, it would be useful to have something we could use straightaway.

The Quick Translator option only shows the User Parameters window, surely that can't be more daunting than the full Workbench?

If your users won't even need to change parameters you can just use the command line that's mentioned at the top of the logfile. Simply set up a desktop shortcut that runs that command line and you're done. No options for the users to change anything.

Hi @rhartley

The following Python Code, when used as a Shutdown Python Script, will close down FME Workbench for you. The Python code essentially invokes Taskkill on the Parent ProcessID of the application running the Workspace. Now, there are two methods to close an application using Taskkill; a nice way and the forceful way.

Using the Force switch (/F) with Taskkill does come with a caveat when it's used in FME Workbench though:

If you have AutoSave switched on, doing a Force close will leave a recovery file behind. The next time the Workspace is opened the user will be warned about the recovery file. The user is not necessarily going to be expecting that, or even know what it is.

If, on the other hand, you choose not to use the Force switch in the Python code, then the user will get prompted to Save the Workspace, before it is closed, if any changes have been made to it since it was opened. This is okay, unless the user clicks Cancel and then FME Workbench stays open, defeating the point somewhat.

Here is the Python Code to be pasted into the Workspace Parameters | Scripting | Shutdown Python Script dialog:

import subprocess
import os

parentPid = os.getppid()
taskKill = subprocess.Popen(t'Taskkill.exe', '/PID', str(parentPid), '/F'],
				stdin=None, stdout=None, stderr=None, close_fds=True)

Now, if we go down the route of the answer suggested by @redgeographics then we get a much cleaner solution using FME Quick Translator to run the Workspace. If we open a Workspace that contains the above Python code in the Shutdown Python Script and run it using FME Quick Translator, then both of the above problems go away! Clean exit from the application and license returned!

Hope this helps.

Thanks,

Simon

import subprocess
import os

parentPid = os.getppid()
taskKill = subprocess.Popen(t'Taskkill.exe', '/PID', str(parentPid), '/F'],
				stdin=None, stdout=None, stderr=None, close_fds=True)

Thank you @sipsysigh for your comprehensive answer. This works a treat especially when used with the FME Quick Translator!

Just to note that Python compatibility needs to be set to Python 3.4+ for this to function. 

Thank you for the suggestion to use FME Quick Translator. This works perfectly with the script provided by @sipsysigh