Skip to main content

I have automations that read sql tables an read the filenames in specific tables. in order to iterate through the records the automation updates a flag (i.e. PF = 0, 1, 2, 3) The automation runs on an interval and gets the next record PF=0 and sets the flag according to how far it gets through the automation. 

It’s seems like it would take quite a bit to rig a method to get the PF=0 count and corelate that to how many times the automation runs. 

I am looking for suggestions on how i could determine there are no more pf=0 records and stop the automation. 

Is there a transformer for Flow that will use data to stop the automation?

Probably with python (right?) non python?

Hi @gisbradokla 

 

Maybe you cna use the transformer Terminator to stop the process.

 

 

Thanks in Advance,

Danilo


@danilo_fme  Trying to understand how to implement.

should i create another workspace and maybe have a query in it that only goes to the terminator once there is no feature that comes in? I use parameters to pass the filename through 3 different workspace as it is processed. This is the last workspace that writes the flag to 3 (complete) only if the feature makes it to here does it get written. if there is not another record with flag = 0 then there would not be a feature come into this workspace and it never runs. but there are other reasons why a feature would not come out of the previous workspace. So once the table has no values for flag that = 0 then i can terminate the automation. Do i need to write some python or something to go in the terminator? it just says terminate.


A Terminator does exactly what it says…

Terminate the process if a single feature goes in… with an error/failed process in the log.

 

So the logic of when to terminate is done before. Test if there are features, if not send a feature to the terminator.

Using a FeatureMerger you could set up some AND/OR/XOR/NOR situation if you need to.

I did not do much with the Automation capabilities but it sounds like the solution is more in the trigger of the automation than the workbench itself?

 


In general, automations have very few possibilities wrt. logic and testing.

If you require logic and testing in your automation, I will suggest creating small/modular workspaces, with automation writer outputs.

Have the workspace handle the logic and testing, using published parameters as input, and automation writer ports as output.


Reply