Skip to main content

When I create a Custom Transformer in FME, and (manually) create parameters within that custom transformer, it seems that I can't assign an attribute value for these parameters from outside of the custom transformer.

 

So for example, I created 3 distinct parameters (text, number and (single) choide) inside of a custom transformer, all of them with the setting 'Disable Attribute Assignment' unchecked.

imagethen outside of the custom transformer I don't get an option to provide an attribute value for each of these parameters;

imageInterestingly, if I expose attributes at the input port of the custom transformer, like so;

image 

then a text parameter is automatically created (in this case 'ATTR1'), whose value can be set outside of the custom transformer:

imageIt seems like a bit of a bug to me. I'm using FME 2021.2.2.0 (b21806 - win64).

 

I found some ways to work around this, like in case of the text parameter, you can open the Text Editor window, and manually type @Value(attr1) (also in the Text Editor window, in the top right no attributes appear, so you really need to manually type it). Or you can just directly type this in the parameter value field without opening the Text Editor.

 

For the Number parameter, this is not possible, because FME seems to think that this is not valid, and you can't confirm the value;

imageimageFor the Number parameter you can go into the custom parameter, and set the attribute value for the default value there, and then it will work;

imageimageFor the (Single) Choice Parameter this is not an option though. :S

 

Am I doing something wrong, or is this indeed an issue with FME?

Hi @thijsknapen​ , I noticed the same issue before. Interestingly attribute value setting for the parameter will be available, once you refer the parameter somewhere in the custom transformer definition. Try setting the parameter to a parameter of a transformer (e.g. ParameterFetcher) within the custom transformer.

It's not so critical, but I agree that it could make the user confused.


Hi @thijsknapen​ , I noticed the same issue before. Interestingly attribute value setting for the parameter will be available, once you refer the parameter somewhere in the custom transformer definition. Try setting the parameter to a parameter of a transformer (e.g. ParameterFetcher) within the custom transformer.

It's not so critical, but I agree that it could make the user confused.

Hi @Takashi Iijima​ ,

 

Great to see get a response from my personal FME hero 🙂

I just verified that your method, (i.e. first adding some kind of reference to the user parameter in the CT) indeed works and allows for selection of an attribute value outside of the CT.

If you know this method, it indeed makes it manageble, but if you don't I also agree that it is quite confusing (which is why I created the case).

 

Tnx again for sharing your (FME) wisdom with us!


Behaviour is same with FME 2022.1.1.0. Hopefully someone will debug this soon. I've just spent some hours in tracking down some misconfiguration on my side that obviously never has been there! Maybe you remember this workaround if you deal with CT regularly, but it's definitely not obvious when you dive into this topic every view month!


That thing is still present in FME Desktop 2022.2.3.0

 

Even, the workaround presented here does not work


This problem is still present in FME 2023.1.1.1 build 23636.

 

I've also noticed that further care needs to be taken when you have custom transformers inside other custom transformers. If a parameter from a "parent" custom transformer is passed into another "child" (linked) transformer, @Takashi Iijima​ 's solution needs to be applied to the same parameter in the linked child transformer - that is, both the parent and child custom transformers must be updated. And after you modify the child transformer, you need to reopen the parent transformer and save it again so that the changes filter through. I hope that makes sense, I'm unfamiliar with the best terminology to use in these circumstances.

 

@xtian79​, perhaps that was why the work-around didn't work for you?

 

I've only tested this with linked transformers, but the same might hold for embedded transformers.


This problem is still present in FME 2023.1.1.1 build 23636.

 

I've also noticed that further care needs to be taken when you have custom transformers inside other custom transformers. If a parameter from a "parent" custom transformer is passed into another "child" (linked) transformer, @Takashi Iijima​ 's solution needs to be applied to the same parameter in the linked child transformer - that is, both the parent and child custom transformers must be updated. And after you modify the child transformer, you need to reopen the parent transformer and save it again so that the changes filter through. I hope that makes sense, I'm unfamiliar with the best terminology to use in these circumstances.

 

@xtian79​, perhaps that was why the work-around didn't work for you?

 

I've only tested this with linked transformers, but the same might hold for embedded transformers.

I've also discovered that if a FeatureReader is added to a custom transformer, and the PostGIS reader type is used, and the Connection is set to a user parameter, that same user parameter cannot be assigned by a attribute value outside the custom transformer. Not even Takashi's work-around will fix it. It may be necessary to expose the user parameter with the ParameterFetcher and set the Connection to the attribute created by the ParameterFetcher. This problem may also apply to other reader types used by the FeatureReader, and possibly similar settings in the FeatureWriter (and perhaps other FME transformers as well?). This issue is present in FME 2023.1.1.1 build 23636.


I've also discovered that if a FeatureReader is added to a custom transformer, and the PostGIS reader type is used, and the Connection is set to a user parameter, that same user parameter cannot be assigned by a attribute value outside the custom transformer. Not even Takashi's work-around will fix it. It may be necessary to expose the user parameter with the ParameterFetcher and set the Connection to the attribute created by the ParameterFetcher. This problem may also apply to other reader types used by the FeatureReader, and possibly similar settings in the FeatureWriter (and perhaps other FME transformers as well?). This issue is present in FME 2023.1.1.1 build 23636.

The problem also occurs if the parameter is used as the Connection for an SQLExecutor transformer.

 

Also some additional information for my comments above "And after you modify the child transformer, you need to reopen the parent transformer and save it again so that the changes filter through"... when you reopen the parent transformer, if you had already applied Takashi's fix using a ParameterFetcher, you may also need to recreate the existing ParameterFetcher (and expose the same parameter as an attribute) and then re-save the parent custom transformer.

 

Are we having fun yet? I hope this helps someone else out there.


I've also discovered that if a FeatureReader is added to a custom transformer, and the PostGIS reader type is used, and the Connection is set to a user parameter, that same user parameter cannot be assigned by a attribute value outside the custom transformer. Not even Takashi's work-around will fix it. It may be necessary to expose the user parameter with the ParameterFetcher and set the Connection to the attribute created by the ParameterFetcher. This problem may also apply to other reader types used by the FeatureReader, and possibly similar settings in the FeatureWriter (and perhaps other FME transformers as well?). This issue is present in FME 2023.1.1.1 build 23636.

Another comment with regard to using FeatureReader transformers when attribute values are assigned to the user parameters. If you want to continue to use the same parameters in your translation after the features are output from the FeatureReader, it is important to set the Accumulation Mode to 'Merge Initiator and Result' so that the parameter values aren't disposed of by the FeatureReader.


Reply