Skip to main content

CustomTransfomers: A word of warning (Parameter Usage)


virtualcitymatt
Celebrity
Forum|alt.badge.img+39

Likely known by many here, however, I can’t see it documented officially so I’m going to spell it out.

If you have created a CustomTranformer or are working with one you need to be very careful how you use/reference parameters.

There are many gotchas when working with CustomTransformers but this is the one that trips me up the most. 

If you define a parameter in a Custom Transform with an attribute value this will not always be treated as a Global Parameter inside the transformer. I.e., depending on what happens in the Transformer the value will not always be accessible.

I saw a great comment by ​@ctredinnick in this thread from a couple of years ago: 


where they mention that Parameter Values defined by an attribute value will be treated in a similar way to unexposed attributes.

I had always assumed that Parameter values were somehow ‘locked in’ of defined for every feature when they went in but that’s not true. Anytime the parameter is referenced inside a CustomTransformer it will just resolve the @Value(<attribute-name>). 

It actually just seems so obvious now that I’m explaining it but often when you’re initially building a CustomTransfomer it’s not an issue - for example you could have a CustomTransformer which includes a FeatureReader or an SQLExcecutor follow by a tester to filter features further based on a parameter value. Unless you make sure that you merge attributes this wont work if you’ve defined the parameter with an attribute value.

I’ve come to the conclusion that if I’m building a CustomTransformer it’s almost the safest option to just always use a ParameterFetcher right at the start to fetch them all - but this is obviously annoying because it’s really nice to just be able to reference an parameter value, this is also nice because you can easily see where the value is referenced.

Anyone feel my pain on this one?
 

 

 

3 replies

david_r
Celebrity
  • July 4, 2025

Coming from “real” programming I can totally sympathize: the FME model of working with local parameters in custom transformers can be really confusing. E.g. just try referencing a local parameter inside a PythonCaller.

It would be fantastic if it could be more predictable.


virtualcitymatt
Celebrity
Forum|alt.badge.img+39
david_r wrote:

Coming from “real” programming I can totally sympathize: the FME model of working with local parameters in custom transformers can be really confusing. E.g. just try referencing a local parameter inside a PythonCaller.

It would be fantastic if it could be more predictable.

Oh yes, the PythonCaller in a CustomTransformer is yet another gotcha - good point


alexbiz
Enthusiast
Forum|alt.badge.img+13
  • Enthusiast
  • July 4, 2025

OOOOw You just made me realize one of my struggle

I’ve developed the good habit of, whenever I need to create parameters that should be at least partly driven by attributes, managing them directly in the custom transformer’s ‘Input’ entry.

 

Those added attributes will create text user parameters that would work every time, I know why now. 


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings