How do I set a User Parameter in AttributeCreator | Community

I have a very simple workspace with just an AttributeCreator transformer, which adds a new attribute called 'MyNewAttr' to my input dataset.

But rather than having the attribute name 'MyNewAttr' defined in the transformer, I'd like to do it by Published Parameter.

In the AttributeCreator Parameter window, when I try to create a new user parameter from this new attribute, I get the prompt to create a new user parameter.

But once I click OK, it does not actually create the user parameter, and my transformer parameter is showing red.

The same happens when I use AttributeRenamer or AttributeManager. I simply don't seem to be able to set a attribute name using a user parameter. What am I missing? What am I doing wrong? Is there another way of setting an attribute name using a user parameter?

The main reason for asking this question is because I am discovering the power of Custom Transformers, but every time I am struggling with this issue.

(I am using FME Desktop v2016.1)

Page 1 / 1

I get the same result.

However, if you manually add the published parameter this seems to work.

I find I have much better luck in in custom transformers using the StringConcatenator rather than the AttributeCreator.

The AttributeCreator propagates the parameter as $(param_name) instead of the value of the parameter, whereas the StringConcatenator correctly resolves it.

attributenamesct.fmw

I get the same result.

However, if you manually add the published parameter this seems to work.

@erik_jan: You're right. How bizarre !?

I find I have much better luck in in custom transformers using the StringConcatenator rather than the AttributeCreator.

The AttributeCreator propagates the parameter as $(param_name) instead of the value of the parameter, whereas the StringConcatenator correctly resolves it.

attributenamesct.fmw

A very simple and elegant solution. My Custom Transformer now works exactly as I wanted by simply replacing my AttributeCreator by a StringConcatenator.

I find I have much better luck in in custom transformers using the StringConcatenator rather than the AttributeCreator.

The AttributeCreator propagates the parameter as $(param_name) instead of the value of the parameter, whereas the StringConcatenator correctly resolves it.

attributenamesct.fmw

Having said all that, I still feel like there is a bit of an 'imperfection' (dare I say 'bug'?) in the AttributeCreator transformer and its siblings. Or am I misunderstanding something? Maybe someone at Safe can check (@Mark2AtSafe?)

Having said all that, I still feel like there is a bit of an 'imperfection' (dare I say 'bug'?) in the AttributeCreator transformer and its siblings. Or am I misunderstanding something? Maybe someone at Safe can check (@Mark2AtSafe?)

Agreed, there is a bug in the AttributeCreator introduced in 2016 (2015 generates a published parameter as expected). The AttributeRenamer is a different issue, in that there is no independent parameter for the parts, but rather a concatenation of OutAttr, InAttr, Default.

That does seem odd. I will file a problem report with the developers.

For me, I almost always create my published parameters manually and then connect them to where I need them. You get much more control over the type of parameter that way.

That does seem odd. I will file a problem report with the developers.

For me, I almost always create my published parameters manually and then connect them to where I need them. You get much more control over the type of parameter that way.

Though not all parameter types are available in the manual creation process. ListAttribute comes immediately to mind.

That does seem odd. I will file a problem report with the developers.

For me, I almost always create my published parameters manually and then connect them to where I need them. You get much more control over the type of parameter that way.

Filed as PR#75490

That does seem odd. I will file a problem report with the developers.

For me, I almost always create my published parameters manually and then connect them to where I need them. You get much more control over the type of parameter that way.

Fixed in build 17239 - so it will be in 2017.0

Fixed in build 17239 - so it will be in 2017.0

Is there a PR for resolving the published parameter on all transformers that produce attributes?

That does seem odd. I will file a problem report with the developers.

For me, I almost always create my published parameters manually and then connect them to where I need them. You get much more control over the type of parameter that way.

I have still no luck with this one.

Using FME Desktop 2018, trying to let the user determine the name of the attribute....

I have still no luck with this one.

Using FME Desktop 2018, trying to let the user determine the name of the attribute....

Hi @HarmenKampinga, It seems to be working for me using 2017.1 and above, in AttributeCreator. Can you tell me what transformer are you using for your workflow?

Hi @HarmenKampinga, It seems to be working for me using 2017.1 and above, in AttributeCreator. Can you tell me what transformer are you using for your workflow?

Thank you @XiaomengAtSafe : I am using the AttributeCreator also, but nothing happens.

Simple Workspace attached :

create attribute name.fmw

Thank you @XiaomengAtSafe : I am using the AttributeCreator also, but nothing happens.

Simple Workspace attached :

create attribute name.fmw

@HarmenKampinga it works but the attribute is not exposed, check in the inspector:

You can select a published parameter in the AttributeExposer to expose it more dynamic.

Dynamic attributenames can have a steep learning curve. Depending on what you need the SchemaSetter custom transformer can help to generate a schema feature which can be used to write to a dynamic schema.

@HarmenKampinga it works but the attribute is not exposed, check in the inspector:

You can select a published parameter in the AttributeExposer to expose it more dynamic.

Dynamic attributenames can have a steep learning curve. Depending on what you need the SchemaSetter custom transformer can help to generate a schema feature which can be used to write to a dynamic schema.

errh.... yes....

It was that simple indeed, thanks @nielsgerrits

Added an AttributeExposer in my case.

@HarmenKampinga it works but the attribute is not exposed, check in the inspector:

You can select a published parameter in the AttributeExposer to expose it more dynamic.

Dynamic attributenames can have a steep learning curve. Depending on what you need the SchemaSetter custom transformer can help to generate a schema feature which can be used to write to a dynamic schema.

Hello @nielsgerrits, I tried your solution for my own problem with your sugestion to use the published parameter I used for the attribute creation in the exposer to make it usable. Unfortunalty if I do that, I only get an empty attribute named $(NameOfPublishedParameter). Do I have to use a different published parameter than I used for the attribute creation?

Hello @nielsgerrits, I tried your solution for my own problem with your sugestion to use the published parameter I used for the attribute creation in the exposer to make it usable. Unfortunalty if I do that, I only get an empty attribute named $(NameOfPublishedParameter). Do I have to use a different published parameter than I used for the attribute creation?

@erikboehm not sure what your issue is. If you add a sample workspace we can see what is happening and point out the issue. Even better is to start a new question, because this one is already answered.

Reply