Skip to main content
Question

Controlling execution order - thwarted


lifalin2016
Contributor
Forum|alt.badge.img+29

Hi list.

I have a master workspace in Workbench, which starts with a Creator calling two SQLExecutors, and eventually calls two WorkspaceRunners.

Each SQLExecutor fetches a list of tables in a dataset, adding their feature count (numbers of rows).

I specifically tell FME to process the smaller dataset (i.e. its SQLExecutor) first, but each “thread” also have a (blocking) Sorter transformer (sorting by feature count) before calling (its) WorkspaceRunner.

It seems that the result from the two blocking Sorter transformers are processed by FME in the wrong order regardless of which order the features have arrived.

How can I ensure that the Sorter for the smaller dataset (i.e. VAT above) executes first, before the Sorter for the larger dataset ?

As is seen, I tried to rename the Sorters, so the smaller was alphabetically listed before the larger, but it didn’t change anything. The Logger logged the larger dataset first.

7 replies

takashi
Influencer
  • May 2, 2025

Hi ​@lifalin2016 ,

I think you can remove the Sorters, if you use ORDER BY clause within the SQL statements to sort the output features.


lifalin2016
Contributor
Forum|alt.badge.img+29
  • Author
  • Contributor
  • May 2, 2025
takashi wrote:

Hi ​@lifalin2016 ,

I think you can remove the Sorters, if you use ORDER BY clause within the SQL statements to sort the output features.

True in this case, but it’s a work-around, not a solution. After posting the question I did in fact do this.

But it might not be possible in all cases, so I’d still like an answer to my question.


nielsgerrits
VIP
Forum|alt.badge.img+54

Not sure if I understand correct, but right clicking on one of the connections from the Creator will let you set connection runtime order.


takashi
Influencer
  • May 2, 2025

Do you perhaps want to determine the order of triggering the two SQLExecutor with some condition or criteria at run-time? If so, can you please explain what the condition is.


lifalin2016
Contributor
Forum|alt.badge.img+29
  • Author
  • Contributor
  • May 6, 2025
nielsgerrits wrote:

Not sure if I understand correct, but right clicking on one of the connections from the Creator will let you set connection runtime order.

Yes, and I did that. But FME ignores that order when passing features on from the blocking Sorter transformers. Why this happens is the essence of my question.


lifalin2016
Contributor
Forum|alt.badge.img+29
  • Author
  • Contributor
  • May 6, 2025
takashi wrote:

Do you perhaps want to determine the order of triggering the two SQLExecutor with some condition or criteria at run-time? If so, can you please explain what the condition is.

The order is determined by the order of the two connections from Creator.

The lower connection is 1 of 2, and the upper is 2 of 2.


nielsgerrits
VIP
Forum|alt.badge.img+54
lifalin2016 wrote:
nielsgerrits wrote:

Not sure if I understand correct, but right clicking on one of the connections from the Creator will let you set connection runtime order.

Yes, and I did that. But FME ignores that order when passing features on from the blocking Sorter transformers. Why this happens is the essence of my question.

OK. I was confused by:  

lifalin2016 wrote:

As is seen, I tried to rename the Sorters, so the smaller was alphabetically listed before the larger, but it didn’t change anything. The Logger logged the larger dataset first.

 

But ontopic, I think I have seen this behaviour before. (transformer after sorter ignoring sorted order) In my case it was SQLExecutor, Sorter, PythonCaller where the PythonCaller processed features randomly, not from small to big as I preferred. I worked around it but if I must guess it probably has to do something with the ‘newer’ bulk data handling. This can be tested with a transformer which breaks bulk mode, I think that de Deaggregator does this, but I am not sure.


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings