Solved

Setting a single DateTime parameter on run initiation?

  • 10 March 2023
  • 5 replies
  • 16 views
afod
Rank
Badge +3

Is there a way to automatically set the datetime within a parameter and use it to fanout a dataset so that does not then create a folder for every minute the workspace was running.

 

I just want the initial date time the workspace was run. The default date time parameter is not really ideal for this as it defaults to midnight and requires user input. I'm hoping to not have to use a workspace runner.

 

Using DateTimeNow seems to create multiple folders as the outputs are written.

icon

Best answer by david_r 10 March 2023, 10:23

View original

5 replies

nielsgerrits
Rank
Userlevel 6
Badge +32

There are different ways to solve this.

  • Pure FME: Put the DateTimeStamper in the very beginning of the workspace, initiated by a Creator. Then you have only one datetime at the start of the workspace. You can then continue the workspace using FeatureReaders to merge this attribute to all features. As an alternative, you can add this attribute to all feature just before writing using a FeatureMerger set with Requestor = 1 and Supplier = 1.
  • Python: Use a Scripted User Parameter. This is a easier way to get it done and will be faster as not all features will have to drag the datetime attribute through the process. Working sample:
import datetime 
return datetime.datetime.now().strftime("%Y_%m_%d__%H_%M_%S")

 

redgeographics
Rank
Userlevel 5
Badge +25

There are different ways to solve this.

  • Pure FME: Put the DateTimeStamper in the very beginning of the workspace, initiated by a Creator. Then you have only one datetime at the start of the workspace. You can then continue the workspace using FeatureReaders to merge this attribute to all features. As an alternative, you can add this attribute to all feature just before writing using a FeatureMerger set with Requestor = 1 and Supplier = 1.
  • Python: Use a Scripted User Parameter. This is a easier way to get it done and will be faster as not all features will have to drag the datetime attribute through the process. Working sample:
import datetime 
return datetime.datetime.now().strftime("%Y_%m_%d__%H_%M_%S")

 

I generally use (and recommend) the Pure FME option,  but I like the Python one too, I'm going to try that out!

david_r
Rank
Userlevel 4

Here's another pure FME pattern that avoids using a FeatureMerger. Only downside is that the VariableSetter/Retriever doesn't always play nice with feature caching.

imageMy preferred solution is using the Python scripted parameter, however. It's very efficient, as it's only evaluated a single time when the workspace starts.

jkr_wrk
Rank
Userlevel 3
Badge +17

There are different ways to solve this.

  • Pure FME: Put the DateTimeStamper in the very beginning of the workspace, initiated by a Creator. Then you have only one datetime at the start of the workspace. You can then continue the workspace using FeatureReaders to merge this attribute to all features. As an alternative, you can add this attribute to all feature just before writing using a FeatureMerger set with Requestor = 1 and Supplier = 1.
  • Python: Use a Scripted User Parameter. This is a easier way to get it done and will be faster as not all features will have to drag the datetime attribute through the process. Working sample:
import datetime 
return datetime.datetime.now().strftime("%Y_%m_%d__%H_%M_%S")

 

Creator -> VariableSetter -> FeatureReader -> VariableRetriever is my solution

Sample: Every Nth Feature (N=1)
afod
Rank
Badge +3

Thanks all!

 

I totally forgot about the ability to set a global variables within a workspace, this is what I ended up going for.

 

The DateTimeStamp transformer was an option as well, but as I had multiple output streams within the workspace that already required a different DateTime for their output name I was hoping not to clutter the workflow with more joins than required.

Reply


Community Stats

28,669
Posts
109,364
Replies
36,531
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.