Hi @dms2
You can use the custom trnsformer AttributeTransposer and after the AttributeExposer:
Thanks,
Danilo
Hi @dms2
You can use the custom trnsformer AttributeTransposer and after the AttributeExposer:
Thanks,
Danilo
I don't need an AttributeTransposer because I already have attributes named _Visit_1, _Visit_2, _Visit_3, [any other name] ...
The thing is that the only source to know these attribute names are my _count attribute values but I can't use them in the Attributes To Expose parameter in AttributeExposer transformer.
The big question is why do you want to do this dynamic? It makes no sense because you already can write them dynamic and Transformers cant use "to be determined" attributes.
The big question is why do you want to do this dynamic? It makes no sense because you already can write them dynamic and Transformers cant use "to be determined" attributes.
What do you mean with 'It makes no sense because you already can write them dynamic'?
I create the new attributes with AttributeCreator (I also tried using AttributeManager and AttributeTransposer) based on the values in _count attribute but they are not automatically exposed so I'm looking for a way to expose them. No luck so far.
What do you mean with 'It makes no sense because you already can write them dynamic'?
I create the new attributes with AttributeCreator (I also tried using AttributeManager and AttributeTransposer) based on the values in _count attribute but they are not automatically exposed so I'm looking for a way to expose them. No luck so far.
Yes I understand, I encountered the same problem once, then I realized there is no need to expose them dynamic because you can not configure Transformers to work with Attributes which are not exposed yet... You can output unexposed attributes without a problem (Writers and FeatureWriters have several options to write unexposed attributes to dynamic schemas.) so that is not the reason you are looking for a solution to expose Attributes dynamic. Why do the Attributes need to be exposed to work with them?
Yes I understand, I encountered the same problem once, then I realized there is no need to expose them dynamic because you can not configure Transformers to work with Attributes which are not exposed yet... You can output unexposed attributes without a problem (Writers and FeatureWriters have several options to write unexposed attributes to dynamic schemas.) so that is not the reason you are looking for a solution to expose Attributes dynamic. Why do the Attributes need to be exposed to work with them?
The answer is that I need these attributes to update an XML with the XMLUpdater transformer. So the next step is to aggregate these and many other attributes (coming from other process steps) in one unique feature which will be connected to the Update port of the XMLUpdater transformer.
What do you mean with 'It makes no sense because you already can write them dynamic'?
I create the new attributes with AttributeCreator (I also tried using AttributeManager and AttributeTransposer) based on the values in _count attribute but they are not automatically exposed so I'm looking for a way to expose them. No luck so far.
FME Workbench won't automatically expose attribute names that will be determined at run-time. You will have to expose them manually with the AttributeExposer if necessary.
The answer is that I need these attributes to update an XML with the XMLUpdater transformer. So the next step is to aggregate these and many other attributes (coming from other process steps) in one unique feature which will be connected to the Update port of the XMLUpdater transformer.
Does the AttributeExploder works for you?
The answer is that I need these attributes to update an XML with the XMLUpdater transformer. So the next step is to aggregate these and many other attributes (coming from other process steps) in one unique feature which will be connected to the Update port of the XMLUpdater transformer.
If the records will be entered to an XMLUpdater via its Update port and you just need to refer the value of an attribute whose name is stored in the "_count" attribute, you can do that with this expression set in the Value field.
@Value(@Value(_count))
Alternatively, this XQuery expression is available too if you set XML/XQuery as Value Type.
fme:get-attribute(fme:get-attribute("_count"))
FME Workbench won't automatically expose attribute names that will be determined at run-time. You will have to expose them manually with the AttributeExposer if necessary.
I run into a similar scenario as dms2. I needed to resolve a coded catalog value and merge a coded label to the data rows to a corresponding ID. This works basically like an subtype or attribute domain in an ESRI geodb only this catalog is for a non ESRI aware software context. There seems no sense in opting for a complexer approach as of SchemaMapper and PythonCaller when data is already available to the workflow.
In my case I wished for
- either an option to expose attributes in an AttributeExposer using @Value(ATTRIBUTE) where ATTRIBUTE contains the needed column name
- or a possibility to choose for exposure in transformers that have the ability to create new attributes such as AttributeCreator (New Attribute) or AttributeManger (Output Attribute) using the @Value(ATTRIBUTE) expression.
