Hi, It seems to me that there might be an issue when I'm trying to fetch a parameter value of a Custom Transformer, from a PythonCaller inside that Custom Transformer. If I do so, I obtain an error. When I try to do so in the main workspace, or when I add the name of the CT in the parameterfetcher, I don't get an error, and it works. See below screenshot and the attached demo workspace for an example.This seems like a bug to me, but it would be nice if the community can have a look alongside me. Kind regards, Thijs Ps. as a sidenote, I came across this Community Question in which the best practice for accessing parameter values inside a PythonCaller is discussed. In it, it is mentioned that best practice is to use param = fme.macroValues[‘parameterName’] in favour of param = FME_MacroValues[‘parameterName’] Additionally, it is mentioned that DaveatSafe created a problem report 4 years ago to make sure that this best practice is also honoured in the script editor for the PythonCaller/Creator. What's the status on this problem report? It seems that the script editor still uses FME_MacroValues[‘parameterName’] by default in FME 2022.1

Fetching a parameter of a Custom Transformer in a PythonCaller (of that CT), results in error

Userlevel 3

+17

Failure to fetch a parameter value from a PythonCaller that is located inside a custom transformer is a known issue (eg. also mentioned here). The reason being user parameters in custom transformers are prefixed with the custom transformer name to avoid collisions with the main workspace parameters as mentioned here. You have already found one workaround for this behaviour. I would also recommend voting on this Idea here.

While using the FME_MacroValues[‘parameterName’] syntax does still work to fetch a parameter value, best practice is to use the syntax fme.macroValues[‘parameterName’]. Updating the syntax for fetching a user parameter in a PythonCaller/PythonCreator script editor is tracked as FMEDESKTOP-4949. I will check in with our development team for an update on this.

Userlevel 4

Hello @thijsknapen

Failure to fetch a parameter value from a PythonCaller that is located inside a custom transformer is a known issue (eg. also mentioned here). The reason being user parameters in custom transformers are prefixed with the custom transformer name to avoid collisions with the main workspace parameters as mentioned here. You have already found one workaround for this behaviour. I would also recommend voting on this Idea here.

While using the FME_MacroValues[‘parameterName’] syntax does still work to fetch a parameter value, best practice is to use the syntax fme.macroValues[‘parameterName’]. Updating the syntax for fetching a user parameter in a PythonCaller/PythonCreator script editor is tracked as FMEDESKTOP-4949. I will check in with our development team for an update on this.

Personally I simply use a ParameterFetcher inside the custom transformer, then read the resulting attribute inside the PythonCaller, before removing it after.

Not ideal, but at least it's very transparent about what's going on.

T

+3

Hello @thijsknapen

Failure to fetch a parameter value from a PythonCaller that is located inside a custom transformer is a known issue (eg. also mentioned here). The reason being user parameters in custom transformers are prefixed with the custom transformer name to avoid collisions with the main workspace parameters as mentioned here. You have already found one workaround for this behaviour. I would also recommend voting on this Idea here.

While using the FME_MacroValues[‘parameterName’] syntax does still work to fetch a parameter value, best practice is to use the syntax fme.macroValues[‘parameterName’]. Updating the syntax for fetching a user parameter in a PythonCaller/PythonCreator script editor is tracked as FMEDESKTOP-4949. I will check in with our development team for an update on this.

Hi @debbiatsafe and david_r,

Thanks for the reply and additional info. I wasn't aware that this was a known issue.

@david_r I agree that a ParameterFetcher would be a good workaround for most cases. However, in some rare cases I suppose that might not be very efficient. E.g. if you need multiple parameter values and/or the features would be multiplied/exploded before entering the PythonCaller.

I was a bit triggered by the comment of jdh in the mentioned community question, where he states that:

There is currently no way to determine the custom transformer instance name and thus the actual parameter name (instancename_parametername) when there are multiple instances of the custom transformer.

I don't fully agree to that notion, as I think this is possible. See e.g. the attached example workspace where I use a LogMessageStreamer to fetch the name of the CT Instance. Whether that's efficient and the way to go is a different matter of course ;)

Update: jdh rightfully commented that there was an oversight in below demo workspace. Please see the other thread for an updated version of the below workspace (I don't see how I can remove it).

Kind regards,

Thijs

Userlevel 4

Hi @debbiatsafe and david_r,

Thanks for the reply and additional info. I wasn't aware that this was a known issue.

@david_r I agree that a ParameterFetcher would be a good workaround for most cases. However, in some rare cases I suppose that might not be very efficient. E.g. if you need multiple parameter values and/or the features would be multiplied/exploded before entering the PythonCaller.

I was a bit triggered by the comment of jdh in the mentioned community question, where he states that:

There is currently no way to determine the custom transformer instance name and thus the actual parameter name (instancename_parametername) when there are multiple instances of the custom transformer.

I don't fully agree to that notion, as I think this is possible. See e.g. the attached example workspace where I use a LogMessageStreamer to fetch the name of the CT Instance. Whether that's efficient and the way to go is a different matter of course ;)

Update: jdh rightfully commented that there was an oversight in below demo workspace. Please see the other thread for an updated version of the below workspace (I don't see how I can remove it).

Kind regards,

Thijs

I must say that I cannot see any reason why the ParameterFetcher should influence the number of features entering the PythonCaller, at least that's never been an issue for me. Sure, the extra attribute is going to consume a minuscule amount of memory for a brief moment in time, but I'd be surprised if that was enough to break anything.

T

+3

Hi @debbiatsafe and david_r,

Thanks for the reply and additional info. I wasn't aware that this was a known issue.

@david_r I agree that a ParameterFetcher would be a good workaround for most cases. However, in some rare cases I suppose that might not be very efficient. E.g. if you need multiple parameter values and/or the features would be multiplied/exploded before entering the PythonCaller.

I was a bit triggered by the comment of jdh in the mentioned community question, where he states that:

There is currently no way to determine the custom transformer instance name and thus the actual parameter name (instancename_parametername) when there are multiple instances of the custom transformer.

I don't fully agree to that notion, as I think this is possible. See e.g. the attached example workspace where I use a LogMessageStreamer to fetch the name of the CT Instance. Whether that's efficient and the way to go is a different matter of course ;)

Update: jdh rightfully commented that there was an oversight in below demo workspace. Please see the other thread for an updated version of the below workspace (I don't see how I can remove it).

Kind regards,

Thijs

Hi @david_r

I also don't see how a ParameterFetcher can influence the number of features entering the PythonCaller. All I wanted to say is that that the extra resources required (how minuscule they may be), may potentially add up in case you need to fetch multiple parameters in the custom transformers.

Also, the effect may add up in case you are dealing with a lot of features. Additionally, I meant to say that the number of incoming features in the custom transformer may be smaller than the number of processed features in the custom transformer. For example in situations where you have a Cloner or a ListExploder in the custom transformer. So that might be another case in which the small amount of resources could accumulate into a more significant amount/effect.

Also, as said, I agree with the notion that generally the ParameterFetcher is probably the way to go.

I do have a bit of a hard time placing your comment 'it won't break anything'. The fact that something works (doesn't break anything), to me doesn't mean that it's the best c.q. most efficient way to go forward.

Userlevel 4

Hi @debbiatsafe and david_r,

Thanks for the reply and additional info. I wasn't aware that this was a known issue.

@david_r I agree that a ParameterFetcher would be a good workaround for most cases. However, in some rare cases I suppose that might not be very efficient. E.g. if you need multiple parameter values and/or the features would be multiplied/exploded before entering the PythonCaller.

I was a bit triggered by the comment of jdh in the mentioned community question, where he states that:

There is currently no way to determine the custom transformer instance name and thus the actual parameter name (instancename_parametername) when there are multiple instances of the custom transformer.

I don't fully agree to that notion, as I think this is possible. See e.g. the attached example workspace where I use a LogMessageStreamer to fetch the name of the CT Instance. Whether that's efficient and the way to go is a different matter of course ;)

Update: jdh rightfully commented that there was an oversight in below demo workspace. Please see the other thread for an updated version of the below workspace (I don't see how I can remove it).

Kind regards,

Thijs

Indeed, I very much agree with these arguments.

Userlevel 4

Hello @thijsknapen

Failure to fetch a parameter value from a PythonCaller that is located inside a custom transformer is a known issue (eg. also mentioned here). The reason being user parameters in custom transformers are prefixed with the custom transformer name to avoid collisions with the main workspace parameters as mentioned here. You have already found one workaround for this behaviour. I would also recommend voting on this Idea here.

While using the FME_MacroValues[‘parameterName’] syntax does still work to fetch a parameter value, best practice is to use the syntax fme.macroValues[‘parameterName’]. Updating the syntax for fetching a user parameter in a PythonCaller/PythonCreator script editor is tracked as FMEDESKTOP-4949. I will check in with our development team for an update on this.

Hi @debbiatsafe, it would be great to get some traction on this issue. This has been a known problem since about 2015 and, in my opinion, it should be relatively easy to address. We also have several clients contacting us directly on this topic, so it's definitely something many users are waiting for. The few workarounds that exist are not a viable long-term option.

Userlevel 3

+17

Hi @debbiatsafe, it would be great to get some traction on this issue. This has been a known problem since about 2015 and, in my opinion, it should be relatively easy to address. We also have several clients contacting us directly on this topic, so it's definitely something many users are waiting for. The few workarounds that exist are not a viable long-term option.

Hello @david_r , I have asked our development team for a re-evaluation of this issue. I will let you know if they decide to move forward with this.

Fetching a parameter of a Custom Transformer in a PythonCaller (of that CT), results in error

8 replies

Reply

Community Stats

Reply

Community Stats

Sign up

An FME Account is required to contribute

Login to the community

An FME Account is required to contribute

Scanning file for viruses.

This file cannot be downloaded