Skip to main content

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.



 

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.

I wouldn’t have thought of using a conditionnal value on an AttributeCreator to replace the parameter with a potentially missing attribute, which the date functions ignore as normal.

Not the most intuitive solution, but it works very well. Thank you.

Community Stats

32,026
Posts
121,631
Replies
39,648
Members

Latest FME

Terms & ConditionsCookie settingsAccessibility statement
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.