Question

VariableSetter and VariableRetriever Run Order


Badge

I have 4 workspaces that follow the same process (they each just calculate different fields on different feature classes). Within these workspaces, I use a VariableSetter and a Variable Retriever. In order to get the Setter to run before the Retriever, I have Set the Connection Runtime Order (as recommended in this post), as well as adding a Sorter in front of the VariableRetriever. This has worked in 3 out of the 4 workspaces, but for some reason, is not working in the 4th. Again, these workflows have an identical setup, they each just manage different attributes in an AttributeManager (that runs after the Variable Retriever). Has anyone had experience with additional methods of getting the Retriever to run AFTER the Setter (other than Set Connection Runtime Order and adding a Sorter)? Thanks.


9 replies

Userlevel 4
Badge +25

You might be able to add some more control over the flow and order by adding a FeatureHolder between the VariableSetter and VariableRetriever.

Userlevel 2
Badge +17
Is the source dataset also identical through all the four workspaces?

 

 

Badge
Is the source dataset also identical through all the four workspaces?

 

 

@takash no, the source data is slightly different between the 4 datasets. They each represent one type of rebate for our water conservation program. Each feature class was built at the same time using 1 FME workspace (same writer). I have been unable to identify anything that differentiates this feature class or workspace from the others. Additionally, it does not appear that the Connection Runtime Order is functioning properly, as the transformer that is supposed to run second, continues to run first.

 

Badge

Takashi's comment got me wondering if something was actually wrong with the source data, so I moved all 4 feature classes into a different SDE geodatabase. Sure enough, it worked. I didn't do anything else to the source feature classes (other than move them), so I have absolutely no clue what was going on, but it worked. Thank you @takashi and @redgeographics for the input.

Badge

While I thought we had the answer, I was wrong. After moving the feature classes to another enterprise geodatabase, the same issue started on two of the other feature classes. I then decided to go ahead and try using FME 2018 (I have been on 2017.1). Not only did that not solve the issue, it also caused the issue to come back on the original feature class/workspace I was struggling with, and now I can't get it to work correctly in 2017 either. I'm perplexed. How do I get FME to consistently run the same each and every time? The transformer run order is critical in these particular workspaces.

Userlevel 2
Badge +17

Generally these factors affect the order of features. Firstly make sure that these are set correctly as you intended.

  • Order of readers (from top to bottom in Navigator window), if two or more readers exist.
  • Runtime order of transformers with no input ports (Creator, PythonCreator, SQLCreator, etc.), if two or more those transformers exist.
  • Connection runtime order at output ports having two or more branch connections.

See also here to learn more about controlling runtime order of feature flow:

Controlling Transformer Flow at Runtime

The solution would be different depending on the actual workspace design. If you need a more specific solution, please explain specifically how you have configured runtime order and the VariableSetter/Retriever in your workspace. A screenshot of relevant part of your workspace might help us to understand the situation correctly.

Badge

Thank you everyone for the help. I received some awesome support from a consultant we are using for another project. He helped me identify a way to avoid the VariableSetter and VariableRetriever completely. Basically it involves creating a single variable for each feature using the StatisticsCalculator but writing it to each line (using the complete port vs the summary port). It's just another example where changing your frame of reference and thought process can result in an equal, if not better solution (something I need to work on). Cheers to FME for being so amazingly versatile. Thank you @takashi for the awesome list of factors that affect run order. I know this is going to be helpful on other projects and workflows. You all are awesome.

Userlevel 2
Badge +12

Thank you everyone for the help. I received some awesome support from a consultant we are using for another project. He helped me identify a way to avoid the VariableSetter and VariableRetriever completely. Basically it involves creating a single variable for each feature using the StatisticsCalculator but writing it to each line (using the complete port vs the summary port). It's just another example where changing your frame of reference and thought process can result in an equal, if not better solution (something I need to work on). Cheers to FME for being so amazingly versatile. Thank you @takashi for the awesome list of factors that affect run order. I know this is going to be helpful on other projects and workflows. You all are awesome.

Glad, you got a resolution for the issue.

 

 

Badge
Glad, you got a resolution for the issue.

 

 

Thanks again @erik_jan for the help!

Reply