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.

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.

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

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''

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 = . 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.

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.