Be aware that the VariableRetriever / VariableSetter transformers don't support partial runs using feature caching.

Using VariableSetters / VariableRetrievers combined with FeatureCaching does not work well for me.

I'm using FeatureMergers with a value "1" in the requestor and supplier when I need this stuff and want to use FeatureCaching, but not sure if that is the best alternative.

I am trying to develop an approach to eventually use on much more complex FME workflow and was hoping to not use connected merger like the FeatureMerger. I really liked the elegant approach of the VariableSetter/VariableRetriever which allowed me to pass a variable without having to connect transformers. Thanks for the proposition, I will consider it.

I have the same problem when I run the whole workflow either with or without feature caching activated.

In that case it might be a question of feature order, i.e. in which order the Setter and Retriever is triggered. Try setting breakpoints before each transformer and see what happens.

I've just created an Idea for having the VariableSetter / VariableRetriever support feature caching, feel free to vote for visibility: https://community.safe.com/s/bridea/a0rDm000000CbI9IAK/variableretriever-variablesetter-should-play-nice-with-feature-caching

Great idea!! Thanks.

If you look at the workflow printscreen in the attached files, the setter is set before the retriever in a connected path. And also, the first retriever (the one straight up following the setter) works fine. But the second one (the one circled in green) does not. However, the two rerievers are configured exactly the same.

Unless some of the input feature types in the blue rectangle ("idec...") arrive before the VariableSetter gets triggered?

Great answers thus far concerning VaribleSetter/VariableRetriever...

Looking at your use-case specifically, you could use the following code in a scripted parameter to return the current date, which could be called in the workspace using a ParameterFetcher (or directly in your other transformers)

from datetime import datetime
 
date_time=datetime.today().strftime('%Y%m%d')
 
return(date_time)

The other thing to be aware of is the setting that was introduced in I think 2020, where Feature Order is not always preserved across ports, which can also upset the Variable Setter/RetrieverFeatures from the reader will hit the variable retriever circled in green possibly before it is set which i suspect is the issue. If you add a featureholder before your testfilter that should fix the issue (I think)

from datetime import datetime
 
date_time=datetime.today().strftime('%Y%m%d')
 
return(date_time)

Agreed, this is exactly what I do. You may not even have to use the ParameterFetcher, in most cases.

from datetime import datetime
 
date_time=datetime.today().strftime('%Y%m%d')
 
return(date_time)

That works like a charm!! Super easy to implement with minimal transformers. Much thanks! 

I would have one question though : Let's say I run the script at 11:59PM, do you know if the parameter will update during the run or will it settle to the first value it got at the moment the script was executed ?

The parameter is set before the translation runs; use a DateTimeStamper to reset the date during the translation.

Perfect! I need that date value to be fixed.