Hi Paul,
It seems to me you are doing it correctly, the only suggestion I can think of is to upgrade FME, since there are bound to be some major improvements from 2009 to 2013.
Hi Paul,
it won't make any difference if you upgrade FME, the behaviour is the same in FME2013.
The easiest solution is to use a ParameterFetcher to get the parameter as an attribute. You can then get the value the same way as your other attributes inside the PythonCaller.
I also recommend using an AttributeRemover at the end of the custom transformer to remove this temporary attribute (best practice).
David
I'm bound at 2009 untill the customer upgrades. I've implemented the parameterfetcher and this indeed works! Thanks for the suggestion.
I'm running in another small issue now, I log a closing message in close(self). However it seems close is called only when the whole model ends, so I get multiple close messages at the end of the log from the different custom transformers. Is this expected behaviour and is there a way to fix this?
Hi Paul,
the close(self) method will be called at the end of each PythonCaller processing. It's normal behavior. When do you need to log messages?
Takashi
Hi Takashi,
I need to log messages at the start and end of the pythoncaller.
the pythoncaller uses the python logger to log to an external log file and looks something like:
class CustomLogger(object): def __init__(self): path = <logfile location> logging.basicConfig(<>) self.logger = logging.getLogger("test1") #self.logger.info("start test log") def input(self,feature): <do something> self.pyoutput(feature)
def close(self): self.logger.info('end test log')
this is in a custom transformer, that is used twice. When i look at the output log file, it shows
start test log
start test log
end test log
end test log
instead of
start test log
end test log
start test log
end test log
I assume all features are passed through a transformer before they continue to another transformer?
>I assume all features are passed through a transformer before they continue to another transformer?
- It really depends on how you connect things and what transformers are used. You can find some input on this behavior here:
http://fmepedia.safe.com/articles/FAQ/Group-Based-Transformers
Also a good way to investigate how features are passed around is using inspection points in FME Workbench.
If, for example, the two custom transformers are connected in series with a sorter in between you might get the second behavior:
>start test log
>end test log
>start test log
>end test log
Hi Paul,
Peter is right. That is concerned with how features flow. def input(self, feature): <do something> self.pyoutput(feature) This coding does process and output features one by one, so features can go to the next transformer before processing of this transformer finishes. The following example behaves like Group-Based transformer, it would generate your expected result if you connect two transformers in a series. But, note this might cause decline in efficiency a little. class CustomLogger(object): def __init__(self): ... self.logger.info("start test log") self.featureList = ] def input(self, feature): <do somthing> self.featureList.append(feature) def close(self): self.logger.info('end test log') for feature in self.featureList: self.pyoutput(feature)
Takashi
Ah ok now I understand, was under the impression it would always go through the transformers 1 by 1.
I will do some tests to see how big the effect on performance is. At least now I can explain why the order of entries in the logfile might look unexpected.
Thanks all,
Paul
