Skip to main content

Hi there

I'm wondering if there is a way to start the same FME-workspace within a loop (input different parameters) and to ensure that the next iteration waits for the translation of the previous one to complete?

I have a Python programm that basically looks like this:

fcList = Â'A', 'B'] # List of feature classes
for fc in fcList:
process = subprocess.Popen(fme.exe workspace --featureClass 'fc')
process.wait() 

 

The purpose of my FME workspace is to write some data into a database. The Python program starts this workspace with feature class 'A' in the first iteration. However, as soon as FME is initialized and starts the actual translation, the process seems to be done for Python and it begins with the second iteration. This causes the initialized workspace to stop and to re-inizialize with feature class 'B'. In the end, there is only the final class 'B' in my database.

I have also tried 

for fc in fcList:
log = subprocess.check_output(fme.exe Workspace --featureClass 'fc')
while "TRANSLATION DONE" not in log:
pass

together with a Python Shutdown Script in FME that writes "TRANSLATION DONE" in the end. Again, the next iteration starts to early and stopps the previous one too early because 'log' gets "TRANSLATION DONE" before the data is written to the database.

Does anyone know how to solve this problem?

Best regards,

 

André

Is there a particular need to do this in python? Could you not have a controller workspace that produces one feature for every item in your list, and sent them to a workspace runner with wait for job to complete set to yes?


I use a windowsbatch for that, setting and reading environment variables.

Fclistentry cold be stuffed in an ev and passed as

The workspacerunner that did the same always ran into some waiting cyle and ended in time-outs in windows scheduler on a network server.

(Hav'nt gotten around to do it in Fme_server yet. Manual is staring at me on my desk...)


As a lot more logic is contained in the Python script, it offers more flexibility compared to the WorkspaceRunner. However, if it is not possible to start several workspaces sequentially otherwise, I would consider WorkspaceRunner as an alternative.

@gio I didn't quite get your proposed solution. Could you explain it to me?


As a lot more logic is contained in the Python script, it offers more flexibility compared to the WorkspaceRunner. However, if it is not possible to start several workspaces sequentially otherwise, I would consider WorkspaceRunner as an alternative.

@gio I didn't quite get your proposed solution. Could you explain it to me?

I think what @gio is trying to say is that if you do it in a Windows batch file (.bat) it will automatically run the workspaces sequentially. There's some options for looping in batch files too, see here for some examples.
I think what @gio is trying to say is that if you do it in a Windows batch file (.bat) it will automatically run the workspaces sequentially. There's some options for looping in batch files too, see here for some examples.
Ah ok, thanks. Yes, that is true: When I tried to write the commands in a bat file instead of giving them to subprocess, it worked. But is this workaround with the bat file necessary? Doesn't FME provide a return value when the translation is finished completely?

 


Ah ok, thanks. Yes, that is true: When I tried to write the commands in a bat file instead of giving them to subprocess, it worked. But is this workaround with the bat file necessary? Doesn't FME provide a return value when the translation is finished completely?

 

Not completely necessary, unless you're trying to do something exotic a WorkspaceRunner would probably do the trick as well and that has the benefit of Passed/Failed output ports so if you want you can do your error checking more easily.

 

 


Have you tried subprocess.call? From what I read about it:

Popen
 doesn't block, allowing you to interact with the 
process while it's running, or continue with other things in your Python
 program. The call to 
Popen
 returns a 
Popen
 object.

call
 does block. While it supports all the same arguments as the 
Popen

 constructor, so you can still set the process' output, environmental 
variables, etc., your script waits for the program to complete, and 
call
 returns a code representing the process' exit status. 

(Thanks StackExchange!)


Yes, I tried check_call() and call() before popen(). However, for all iterations but the last one, cmd opens for a few seconds, prints "translation successfull" and the return value "0" and then closes again before any feature was written. Only for the last Iteration (the last feature class), cmd stays open until all features are in the database and then outputs the return value "0".


Reply