Skip to main content
  • EN

I’m trying to use conditionnal parameters in one of my FME workbenches, and I’m running into a problem where I can’t seem to be able to handle the the <Unused> value that results in trying to read a disabled parameter.

Here I have a workbench with 2 parameters, one checkbox that determines whether to verify that values have been reported for the date where the flow is running, and a conditionnal field where one timestamp can be entered (as I normally use FME Flow’s “Event Timestamp” as input for this field).

Within FME Form, if FME_LAUNCH_TIME is disabled, it will have the value “＜Unused＞” (it’s a text string, reported as such by PythonCaller and ParameterFetcher). This is… inconveinient because “＜Unused＞” (I can’t even type it in the community forums, the system thinks it’s an HTML tag) is not considered null/missing/empty/not-a-value by conditional operators, but it is also a reserved value, meaning you’re often forbidden from even writing it.

I am literally unable to write that final “>”

That’s definitely an inconveinience, but since I have a checkbox, I figured it wouldn’t be very hard to use that as a predicate to skip trying to parse the missing timestamp.

Imagine my surprise...

AddExpectedDates: Failed to parse '<Unused>' as a datetime value. For FME datetime syntax, please see http://docs.safe.com/fme/html/FME_Desktop_Documentation/FME_Workbench/!Transformer_Parameters/standard_fme_date_time_format.htm . For ISO datetime syntax, please see http://docs.safe.com/fme/html/FME_Desktop_Documentation/FME_Workbench/!Transformer_Parameters/standard_fme_date_time_format.htm#ISO-8601-Duration-Format

Not only do I get this warning despite the expression being in a branch that the user parameter would fail to enter (the checkbox has the default configuration, so ticked equals “YES” and unticked equals “NO”), I get that warning even in this screenshot, where you may notice that AddExpectedDates has no input features.

So I’m stuck here. My flow doesn’t crash, but I have no idea how to get rid of that very alarming-looking warning my best attempt was using something like @DateTimeCast(@Evaluate($(CHECK_TODAY_LOGS_EXIST)==YES ? "$(FLOW_LAUNCH_TIME)": "10010101"), date), but that fails to parse FLOW_LAUNCH_TIME correctly when it should because it somehow drops zeroes in the timezone before passing it to DateTimeAdd.

So what’s the correct way of testing for/manipulating unused/disabled conditionnal parameters, then?

Note that I’m using FME 2024.2 (due to OS version support), in case that’s just a bug that was fixed in 2025.

Hi ​@vlroyrenn ,

I think it's an ignorable warning message, but just annoying indeed. I was able to reproce the same behavior with FME 2025.1.2 - the latest official release version.

A possible way to prevent that:

  1. Tester: Send the features to the subsequent process only if $(CHECK_TODAY_LOGS_EXIST) is YES.
  2. AttributeCreator:
    • The 1st row: Create a new attribute called e.g. "_datetime" and assign $(FLOW_LAUNCH_TIME) if $(CHECK_TODAY_LOGS_EXIST) is YES, No Action otherwise.
    • The 2nd row and later: Configure the date/time expression using the attribute "_datetime" as an argument.

See also the scrrenshot blow.

Hope this helps.

Yip, not a fan of this value in conditional parameters

I use the NullAttributeMapper after I fetch every parameter And yes, I can’t close it out either in the workspace, but I probably could make it less greedy with this:  ^<Unused.$

 

Yeah - I’ve used the “Contains <Unused” in the past - definitely frustrating to work with. I’ve actually revered back to YES / NO drop downs for this specific reason.



 

Community Stats

31,853
Posts
120,982
Replies
39,485
Members

Latest FME

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.