Skip to main content
Solved

Published parameters value in python caller in custom transformer


Hi! I'm new to FME and I have an issue with published parameters in a CustomTransformer.

I created a CustomTransformer name "TeamsConnector" which need to use the published parameters "Message" in a pythoncaller:

 

 

 

Now in my main flow I use twice my custom transformer with different published parameters value.

 

"Message 1" as a value for the first use of my transformer:

 

 

 

 

"Message 2" as a value for the second use of my transformer:

 

 

My issue is when I run the flow instead of having "Message 1" and "Message 2" as expected, I have twice "Message 1":

 

Best answer by jdh

It is a known issue with python parameters in a custom transformer. 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.

 

 

The workaround is to use a parameterFetcher in the custom transformer, and in the python code retrieve the value of that attribute instead of the parameter directly.

 

 

 

See https://knowledge.safe.com/content/idea/21410/python-caller-user-parameters-automatically-prefix.html
View original
Did this help you find an answer to your question?

8 replies

jdh
Contributor
Forum|alt.badge.img+28
  • Contributor
  • Best Answer
  • May 20, 2020

It is a known issue with python parameters in a custom transformer. 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.

 

 

The workaround is to use a parameterFetcher in the custom transformer, and in the python code retrieve the value of that attribute instead of the parameter directly.

 

 

 

See https://knowledge.safe.com/content/idea/21410/python-caller-user-parameters-automatically-prefix.html

jwarren
Contributor
Forum|alt.badge.img+5
  • Contributor
  • January 19, 2021
jdh wrote:

It is a known issue with python parameters in a custom transformer. 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.

 

 

The workaround is to use a parameterFetcher in the custom transformer, and in the python code retrieve the value of that attribute instead of the parameter directly.

 

 

 

See https://knowledge.safe.com/content/idea/21410/python-caller-user-parameters-automatically-prefix.html

This seems quite a large flaw in the software. I've found discussions on the same issue from 2016 at least so it's been known about for quite a long time.

@safesoftware safesoftware​ is there any plan to fix this?


jdh
Contributor
Forum|alt.badge.img+28
  • Contributor
  • January 19, 2021
jwarren wrote:

This seems quite a large flaw in the software. I've found discussions on the same issue from 2016 at least so it's been known about for quite a long time.

@safesoftware safesoftware​ is there any plan to fix this?

If you vote on this idea, it may gain traction. https://community.safe.com/s/idea/0874Q000000Tl1UQAS/detail

 

Or propose an alternate solution. One possibility would be an fmeobject method that returns the instance name of the PythonCaller/PythonCreator.


andreaatsafe
Safer
Forum|alt.badge.img+12
jwarren wrote:

This seems quite a large flaw in the software. I've found discussions on the same issue from 2016 at least so it's been known about for quite a long time.

@safesoftware safesoftware​ is there any plan to fix this?

Hi @jwarren​ ,

Thanks for your feedback and for voting on the idea that @jdh​ linked!

 At this time we don’t have plans to address this, however, we would be interested to better understand your scenario to see if there are other workarounds.

-Andrea


thijsknapen
Contributor
Forum|alt.badge.img+10
  • Contributor
  • December 9, 2022
jdh wrote:

It is a known issue with python parameters in a custom transformer. 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.

 

 

The workaround is to use a parameterFetcher in the custom transformer, and in the python code retrieve the value of that attribute instead of the parameter directly.

 

 

 

See https://knowledge.safe.com/content/idea/21410/python-caller-user-parameters-automatically-prefix.html

Hi @jdh​ ,

 

I also came across this issue, see also this question on the FME Community. Although I agree with your idea and also voted for it, I don't fully agree with your notion:

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.

 

See also my latest comment on that community question, in which I attached a sample workspace that demonstrates that this is possible (using a LogMessageStreamer).

 

Whether it's the way to go and the most elegant/efficient solution is a different matter. I think in most cases a ParameterFetcher is a more straightforward workaround.

 


jdh
Contributor
Forum|alt.badge.img+28
  • Contributor
  • December 9, 2022
thijsknapen wrote:

Hi @jdh​ ,

 

I also came across this issue, see also this question on the FME Community. Although I agree with your idea and also voted for it, I don't fully agree with your notion:

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.

 

See also my latest comment on that community question, in which I attached a sample workspace that demonstrates that this is possible (using a LogMessageStreamer).

 

Whether it's the way to go and the most elegant/efficient solution is a different matter. I think in most cases a ParameterFetcher is a more straightforward workaround.

 

Hi @thijsknapen​ ,

 

I first encountered this problem in 2015 or thereabouts, and I'm not even sure if the LogMessageStreamer even existed as a transformer then. While I applaud you creativity, I experimented with the workspace you posted in the other message, and I'm not getting reliable results.

 

If I run your workspace (Build 22765) both the add and add_2 transformers return the results of the add paramenter, even if add is not connected. It's only if add is disabled that add_2 returns to correct results.

 

Additionally if both custom transformers are attached to the same inspector then the FeatureMerger throws an error:

add_FeatureMerger_<Rejected> (TeeFactory): add_FeatureMerger_<Rejected>: Termination Message: 'add_FeatureMerger output a <Rejected> feature. To continue translation when features are rejected, change 'Workspace Parameters' > Translation > 'Rejected Feature Handling' to 'Continue Translation''

 


thijsknapen
Contributor
Forum|alt.badge.img+10
  • Contributor
  • December 9, 2022
thijsknapen wrote:

Hi @jdh​ ,

 

I also came across this issue, see also this question on the FME Community. Although I agree with your idea and also voted for it, I don't fully agree with your notion:

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.

 

See also my latest comment on that community question, in which I attached a sample workspace that demonstrates that this is possible (using a LogMessageStreamer).

 

Whether it's the way to go and the most elegant/efficient solution is a different matter. I think in most cases a ParameterFetcher is a more straightforward workaround.

 

Ah, my bad. I see there was an oversight in my code. This attached sample workspace should work.

 

Note however, I expected the LogMessageStreamer to start streaming from the moment it was ~'initialized' by wrapping it inside the custom transformer, but it seems that it streams from the start. So this implementation doesn't seem to be fit for production purposes... Maybe a workaround could be to read the last couple lines from the fysical .log file to fetch the name of the CT Instance (i.e. text FeatureReader, Read Bottom Up = Yes, Max Features to read = X). Even better might be to use the FMELogFile class from FME's Python API to fetch the last couple of log messages, but Python is not my strong point.

 

Then again, in most cases the ParameterFetcher will probably be the most suitable workaround.

 


thijsknapen
Contributor
Forum|alt.badge.img+10
  • Contributor
  • December 12, 2022
thijsknapen wrote:

Hi @jdh​ ,

 

I also came across this issue, see also this question on the FME Community. Although I agree with your idea and also voted for it, I don't fully agree with your notion:

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.

 

See also my latest comment on that community question, in which I attached a sample workspace that demonstrates that this is possible (using a LogMessageStreamer).

 

Whether it's the way to go and the most elegant/efficient solution is a different matter. I think in most cases a ParameterFetcher is a more straightforward workaround.

 

A small update, I came across the following article from Safe; How to extract and use log information in Workbench. Although it's a bit older, it might form a more efficient method to deal with this. See for example the below workspace in which only specific log lines are send to the callBack method of FMELogFile class of FME's Python API.

 

Note however that Python is not my strong point. So some things might be handled more efficiently.

 

 


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