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.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
+60- Celebrity
- 3703 replies
You might be able to add some more control over the flow and order by adding a FeatureHolder between the VariableSetter and VariableRetriever.
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.
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.
- 7843 replies
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.
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.
+22- Contributor
- 2179 replies
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.