Skip to main content
Question

Pros and Cons of using System Caller to Run Python

  • June 10, 2026
  • 1 reply
  • 23 views

matthewb
Contributor
Forum|alt.badge.img+11

Hi everyone,

While reviewing one of our workspaces, I noticed that one of my developers used the SystemCaller to launch a Python script as an external process instead of using the PythonCaller transformer. The workspace runs fine today, but I'm worried about unforeseen consequences down the road, and I'd like to hear from people who have run both approaches in production.

I'm wondering about maintainability (the scripts live outside of FME), Error handling and logging and versioning.

If you've dealt with this situation, I'd really appreciate hearing how it played out.

1 reply

hkingsbury
Celebrity
Forum|alt.badge.img+71
  • Celebrity
  • June 10, 2026

There’s a lot of nuances with this - more often than not, I’m of the view of keep it all in one place (use the PythonCaller), however sometimes this may not work (rare, but possible).

Often I find the reason the user is calling it externally is they’re using their own Python install with nonstandard libraries and they don’t realise you can install these libraries in FMEs Python (Installing Python Packages to FME Form)

The one big disadvantage of using the system caller is that the script is external to the workspace, that means instead of migrating/managing/administering one file (the workspace) you also need to do the same with the .py file. You also need to make sure the location of the python install isn’t changed.

The system caller is also more a trigger to run the script - FME doesn’t have visibility of what its doing, its a very binary approach, run it, and it either runs or fails.

However using the PythonCaller give you much tighter integration into FME, it can interface directly with your data instead of just triggering something.

 

There’s a lot more I could talk about, but the above is the short of the long