Skip to main content
Solved

How do I set a User Parameter in AttributeCreator

arnold_bijlsma
Enthusiast
Forum|alt.badge.img+14

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)

Best answer by jdh

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

View original
Did this help you find an answer to your question?

18 replies

erik_jan
Contributor
Forum|alt.badge.img+17
  • erik_janContributor
  • Contributor
  • January 25, 2017

I get the same result.

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

jdh
Contributor
Forum|alt.badge.img+28
  • jdhContributor
  • Contributor
  • Best Answer
  • January 25, 2017

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

arnold_bijlsma
Enthusiast
Forum|alt.badge.img+14
  • arnold_bijlsmaEnthusiast
  • Author
  • Enthusiast
  • January 25, 2017
erik_jan wrote:

I get the same result.

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

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

 

arnold_bijlsma
Enthusiast
Forum|alt.badge.img+14
  • arnold_bijlsmaEnthusiast
  • Author
  • Enthusiast
  • January 26, 2017
jdh wrote:

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.

 

arnold_bijlsma
Enthusiast
Forum|alt.badge.img+14
  • arnold_bijlsmaEnthusiast
  • Author
  • Enthusiast
  • January 26, 2017
jdh wrote:

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?)

 

jdh
Contributor
Forum|alt.badge.img+28
  • jdhContributor
  • Contributor
  • January 26, 2017
arnold_bijlsma wrote:
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.

 

 

mark2atsafe
Safer
Forum|alt.badge.img+43
  • mark2atsafeSafer
  • Safer
  • January 26, 2017

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.

jdh
Contributor
Forum|alt.badge.img+28
  • jdhContributor
  • Contributor
  • January 26, 2017
mark2atsafe wrote:

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.

 

 

mark2atsafe
Safer
Forum|alt.badge.img+43
  • mark2atsafeSafer
  • Safer
  • January 26, 2017
mark2atsafe wrote:

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

 

 

mark2atsafe
Safer
Forum|alt.badge.img+43
  • mark2atsafeSafer
  • Safer
  • January 30, 2017
mark2atsafe wrote:

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

 

 

jdh
Contributor
Forum|alt.badge.img+28
  • jdhContributor
  • Contributor
  • January 30, 2017
mark2atsafe wrote:
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?

 

 

harmen_kampinga
Forum|alt.badge.img+2
mark2atsafe wrote:

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....

xiaomengatsafe
Safer
Forum|alt.badge.img+3
harmen_kampinga wrote:

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?

harmen_kampinga
Forum|alt.badge.img+2
xiaomengatsafe wrote:

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

nielsgerrits
VIP
harmen_kampinga wrote:

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.

harmen_kampinga
Forum|alt.badge.img+2
nielsgerrits wrote:

@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.

 

 

erikboehm
Contributor
Forum|alt.badge.img+3
  • erikboehmContributor
  • Contributor
  • July 6, 2020
nielsgerrits wrote:

@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?

nielsgerrits
VIP
erikboehm wrote:

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


Helpful Members This Week

Community Stats

30,942
Posts
117,252
Replies
38,742
Members

Latest FME

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie 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.