Skip to main content
  • EN

Hi

 

 

Related to this earlier question https://knowledge.safe.com/questions/4957/python-startup-script-to-terminate-workspace.html I want to cleanly terminate the creation of a Private Scripted Python Parameter. Throwing an exception pollutes the log with the script from the exception and confuses the user (and author sometimes!)

Then discovered the sys.exit() function and this gives me a better result:

import sys
val = FME_MacroValuesp'INPUT_TEST']
if val == 'Fail':
    print 'You chose {} \nProgram Terminating\nTranslation FAILED.'.format(val)
    sys.exit(0)
else:
    return 'all ok'

Could do with a sanity check from resident Python Jedi that have any comments or any detrimental issues for use with FME?

*Note only tested on FME Desktop NOT Server!

Try calling abort() https://docs.safe.com/fme/html/FME_Objects_Python_API/index.html

 

 

Try calling abort() https://docs.safe.com/fme/html/FME_Objects_Python_API/index.html

 

 

 

Hi @rrdlpl Do you mean os.abort() ? If so that causes a Microsoft Visual C++ Runtime error.

If you get the results you want, then it's good. FME Desktop will shut down the Python process when the workspace finishes, so there should be no detrimental issues.

@DaveAtSafe I get the results I want. The Python Scripted parameter is shutting down the Python process with sys.exit(), so is FME Desktop happy enough with that? The Workspace doesn't show as finished in the log - this is the complete log from Workbench as actually there is no log file created which seems a little strange.

@mark_1spatial, there are two steps to running a workspace - the first step parses the workspace into a script, the second runs the script. The parsing step replaces the parameters with the user supplied values, which includes running the scripted Python parameter code. If you exit at this stage, the workspace is not actually run at all, hence the abbreviated log file.

If you want to test the user parameters during the run itself, you can do this in the Startup Python, which is executed during the run process. Or you can test them within the workspace logic as well - there is a lot of flexibility.

@mark_1spatial, there are two steps to running a workspace - the first step parses the workspace into a script, the second runs the script. The parsing step replaces the parameters with the user supplied values, which includes running the scripted Python parameter code. If you exit at this stage, the workspace is not actually run at all, hence the abbreviated log file.

If you want to test the user parameters during the run itself, you can do this in the Startup Python, which is executed during the run process. Or you can test them within the workspace logic as well - there is a lot of flexibility.

Perfect Thanks!

 

 

Just throwing this out there for all the FMExperts: What would happen if you did use the "sys.exit()" on FME Server? I'm working on a similar workspace, where I'm using Private Scripted Parameters to execute a Python script that publishes to ArcGIS Online. I got it working, and the translation says it's successful, but it never finishes running and I always have to abort it. The script has run successfully by that point, so it's fine, but the only way I've been able to get it to complete (have the red square in Workbench return to the green arrow) is to use "sys.exit()" at the end of the Python script. Which gives a similar log file to what @mark_1spatial mentioned; there's nothing there except the messages the Python script outputs. As I understand, "sys.exit()" ends the "fme.exe" process. But there's an "fme.exe" running on FME Server continually, is that correct? If I include "sys.exit()" in the script and run it on the Server, will it mess things up?

Reply


Community Stats

30,159
Posts
114,479
Replies
37,803
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.