What can I do to expose attributes on only the Transformer Input for which they pertain?
I am more concerned with keeping the inbound attributes straight per feature pipeline, than using published parameters. Thanks!
I am using FME 2014 SP4 and I see that the behavior of Custom Transformer Inputs differs from previous versions of FME. I have 3 transformer inputs which all show the same attributes- however each of these input lines should have different attributes. When I Edit Transformer Input to expose Attributes, the checked attributes get applied to all 3 Transformer Inputs. If I uncheck Publish on Transformer Input- I loose all attributes.
Page 1 / 1
In thoses cases I explicitly use an AttributeExposer inside the custom transformer, rather than checking them on the Input.
Thanks JDH. To do that in this case, it looks like I would start by leaving Edit Transformer Input>Published as checked. Then unselect all External Attributes to Expose. Then add an AttributeExposer after each Transformer Input- within which I would need to type in all the attribute names that should be found on each pipeline. If that is right, then I am still doing a lot of work to set things right inside the custom transformer. My workaround was to do an BulkAttributeRenamer and set a prefix to each pipeline of attributes outside the custom transformer. Then inside the custom transformer, I would drop the attributes that do not pertain per pipeline- as easily distinguished by the prefix. Still, I wonder if there is a setting that would avoid workarounds and use the behavior I'd seen in earlier versions. Thanks again!
I now understand that FME 2012? changed the way Custom Transformers handle Attribute References. You can choose Handle with Published Parameters or Advanced-Fix Manually. Somehow the Custom Transformer at issue was either created or changed to Handle with Published Parameters, and I prefer Advanced-Fix Manually because it distinguishes between multiple transformer inputs. I'd like to know how to fix this after the fact. I may just need to make a new custom transformer to replace this one.
You only need to expose the attribute names you'll actually be using inside the custom transformer, the rest will silently carry through and still be available on the main canvas
Hi,
If you once expose attributes by checking on their names in the Input port properties dialog (External Attributes to Expose), Published Parameters and internal attributes corresponding to them will be created. At run-time, the custom transformer will receive values through the parameters, and store the values into the internal attributes.
Although the internal attribute names will be the same as the external attribute names at the time when you exposed them, this doesn't mean that the external attributes will be refered directly in the custom transformer. The internal attributes will store values received through the Published Parameters always. Therefore, you don't need to modify them when you use the transformer in the different contexts. You can pass required values to the internal attributes through the parameters anywhere.
If you don't want to use the external attribute names in the custom transformer, you can also define Published Parameters manually and fetch their values inside of the custom transformer. In fact, this had been the traditional way before the "External Attributes to Expose" functionality was added to Input port properties, and also it's still a frequently being used way to create generic custom transformers.
Many of FME Store transformers use the traditional way. I think they are good examples to learn how a custom transformer receives values through published parameters and stores them into internal attributes. I would recommend you to see some of them.
Takashi
Thanks Takashi for helping me understand the purpose and value of the Published Parameters inside custom transformers. From my frame of reference, custom transformer published parameters/attributes seemed to make things more difficult. Since I am not concerned with reusing the custom transformer in another context (really just using to simplify main workbench canvas), I am more interested in more easily seeing which attributes are on each transformer input. It seems now- that to even get the attributes inside the custom transformer, you must publish them. Then once published - they are exposed on all transformer inputs within the custom transformer. It does not matter which input I edit (inside the custom transformer) - any attribute/parameter I check to expose- then gets applied to all other custom transformer inputs inside the custom transformer. My original question was asking if there was a way to make use of published parameters/attributes- but only have them grouped on the custom transformer input (inside the custom transformer) which they pertain to.
So if I have 2 transformer inputs- each is from a separate input source-- Then I use a FeatureMerger inside the custom transformer, I need to know which join attributes to use from each input. All attributes/parameters appear available on both the requestor and the supplier. You are permitted to select an attribute/parameter that may not really exist on the Requestor and/or Supplier. The FeatureMerger seems to not have a problem with this (no red cog), but when you run it, you may have a logic problem. I have some old custom transformers living in several workbenches which probably date to FME 2011? which simply carry exposed attributes from outside to inside the custom transformer via separate custom transformer inputs. A FeatureMerger within those will only allow you to select join fields for the Requestor and the Supplier which pertain to their input ports, which are downstream of separate custom transformer inputs.
I would like to be able to still opt for this way of passing attributes into a custom transformer for times when I care more about following the logic/attributes/pipelines than about using the same custom transformer in other places. I think it is harder to author and troubleshoot a custom transformer when all the input attributes/parameters are showing as valid for 2 or more custom transformer inputs. It leads you to think attributes are available on inputs/pipelines which they really don't travel through.
"It leads you to think attributes are available on inputs/pipelines which they really don't travel through"
No it does not. ;)
Currently in custom transformers, any attribute exposed on one input port will show up on all of the input ports for the custom transformer.
of a transformer. The functionality was
removed around FME 2013, as when one would copy and paste a transformer, the
internals of that transformer changed.
In older versions of FME (pre FME 2013), if custom transformers were only used once in the workspace, they automatically showed what was being input, leading to different attributes on different input ports.This only worked when there was a single instance
of a transformer. The functionality was
removed around FME 2013, as when one would copy and paste a transformer, the
internals of that transformer changed.
As I'm stuck the same way cdavid was and the different answers make me understand a solution i would like to share it with you.
Actually, custom transformer is NOT what respond to our research, in fact most of the transformers doesn't presume on what is the column format of the inputs whereas our preoccupation is to correctly have the input column structure in the correct input connector inside the custom parameter. And what i didn't understand is that when i change the attribute for 1 input it change for others too. Even more, that i don't need those attributes as published one.
So my thought was simply to replace the custom transformer by a bookmark that encompass all i've put in my transformer, here the attributes are correctly passing to the next transformer as there is no border between previous and next transformer.
I'm sure many of you will not understand what i'm talking about, cause it's more misunderstanding then a problem/bug, so you can see in the picture attached my structure where i replace J_update(custom transfo) by bookmark J_Update; but i also think that this could help others.
Last, the only thing that is not so easily manageable is when i want to make a change inside the bookmark. Not only becouse it's big and deform all my fme structure but cause i use it 5 times, so 1 change have to be reverberate 5 times, except by developping it for 1 and copy to others when i'm sure of the process.
As I'm stuck the same way cdavid was and the different answers make me understand a solution i would like to share it with you.
Actually, custom transformer is NOT what respond to our research, in fact most of the transformers doesn't presume on what is the column format of the inputs whereas our preoccupation is to correctly have the input column structure in the correct input connector inside the custom parameter. And what i didn't understand is that when i change the attribute for 1 input it change for others too. Even more, that i don't need those attributes as published one.
So my thought was simply to replace the custom transformer by a bookmark that encompass all i've put in my transformer, here the attributes are correctly passing to the next transformer as there is no border between previous and next transformer.
I'm sure many of you will not understand what i'm talking about, cause it's more misunderstanding then a problem/bug, so you can see in the picture attached my structure where i replace J_update(custom transfo) by bookmark J_Update; but i also think that this could help others.
Last, the only thing that is not so easily manageable is when i want to make a change inside the bookmark. Not only becouse it's big and deform all my fme structure but cause i use it 5 times, so 1 change have to be reverberate 5 times, except by developping it for 1 and copy to others when i'm sure of the process.
I think this is an opportunity for us to improve FME (it may even be an outright bug, depending on how you look at it) and in fact is already filed with our developers as FMEDESKTOP-5437.
I'm hoping this has a high priority to get fixed. In the meantime, your solution may work, but I urge you to treat it as a temporary workaround. Duplicating the same set of transformers multiple times is not good practice, and a custom transformer with a single definition is usually the recommended solution.
I hope that I will have news of a fix in the near future.