Skip to main content
  • EN
I have a python caller inside a custom transformer wich has a user parameter named ratio

 

 

In the python caller I do:

 

 

 

  
 import fmeobjects def myFunction(feature):     ratio = FME_MacroValuese'ratio']
 

 

 

 

And I got the following error:

 

 

2015-02-02 13:40:27| 1.3| 0.0|ERROR |Python Exception <KeyError>: 'ratio'

 

2015-02-02 13:40:27| 1.3| 0.0|ERROR |Error encountered while calling function `myFunction'

 

2015-02-02 13:40:27| 1.3| 0.0|FATAL |PythonFactory failed to process feature

 

 

What could be the problem? Im using FME Desktop 2015
Is the macrovalue 'ratio' existant when the pyhtonscript is called?
Yes, I see it in the left window under the published parameters in the python caller window
if i set :class or funtion to process feature" (on the pythoncaller interface) to "myFunction" i get no error.

 

 

(of coourse with just those lines i get no result either...)
Have you put your python caller inside a custom transformer and defined the user parameter on the custom transformer?
This has value of parameter "ratio"as output.

 

 

import fme

 

import fmeobjects

 

# Template Function interface:

 

def myFunction(feature):

 

    ratio = FME_MacroValuesc'ratio']

 

    feature.setAttribute("ratio", ratio)

 

 
of course don't  forget to expose it...
ok still not working here
did you set this?

 

the problem is: if the user parameter is defined in the custom transformer, you cant access it in the python caller, but if the user parameter is defined in the main workbench, you can acess it in the python caller
lol...i assumed you did have it accesable....or it being existant...

 

 

 
Gio: I guess it suppose to be accessible but it is not, probably a bug though
Hi,

 

 

Internally, FME Workbench adds a unique prefix to parameter names defined in a custom transformer. I think the reason is to avoid conflict among parameter (macro) names that are defined in the main workspace and custom transformers.

 

 

The traditional macro syntax seems to be available. i.e.

 

-----

 

def myFunction(feature):

 

    ratio = $(ratio)

 

    # Do something with ratio

 

----- 

 

 

In my observation, Workbench seems to transform "$(ratio)" into a preferable prefixed macro name when interpreting the workspace.

 

But this usage not documented explicitly, so I think it's safer to get the parameter value by the ParameterFetcher or the AttributeCreator before the Python processing.

 

 

For example, after storing the parameter value as a feature attribute (e.g. "_ratio"):

 

-----

 

def myFunction(feature):

 

    ratio = feature.getAttribute('_ratio')

 

    # Do something with ratio

 

-----

 

 

Takashi

 

the "best practice" way of accessing published parameters inside a custom transformer is to use a ParameterFetcher and then access the parameter value as an attribute inside the PythonCaller, as shown by Takashi above. After the PythonCaller, add an AttributeRemover to get rid of the temporary attribute.

 

 

You will see this pattern used a lot in custom transformers available on the FME Store, e.g. the DateConverter (https://store.safe.com/transformers/DateConverter.htm).

 

 

David
yes, as i said, you identify the customtransformer where the parameter is....

 

 

Or use a fetcher, if you like to.

 

 

This issue has been asked before and is in the solved questions library...actually i think the answer was given by...David R.. 😉
Gio,

 

 

prefixing the parameter with the name of the custom transformer works well if you only have one instance of the custom transformer, and if you never rename it in the master workspace. For all other instances this method will fail.

 

 

This is because the prefix is bound to the instance of the custom transformer, and not the defintion of the custom transformer.

 

 

Using the ParameterFetcher will let you ignore this subtle distinction.

 

 

David
oki, i see.

 

I did indeed not take into account using multiple instances of same customtransformer.

 

Then fetcher is obviously the way to go.

 

Or rename the customs...wich is not very handy indeed.

 

 

Though neither of you did argument this in your posts..
..on the other hand if this parameter is private, then using instances will yield same parameter value anyway, or is it not?

Reply


Community Stats

30,108
Posts
114,295
Replies
37,744
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.