Hey @paetzold_s this looks like a bug to me. I've reproduce the issue and have filed an issue to get this resolved. For your reference, the issue number is FMEFORM-29210. We'll make sure to update you here when the issue has been resolved.
Wow, thank you for the quick response. I have found a similar problem with the BulkAttributeRenamer. I'll post it in a new question/thread.
Wow, thank you for the quick response. I have found a similar problem with the BulkAttributeRenamer. I'll post it in a new question/thread.
No problem! If you're able to tag me in the question that'd be great. I can take a look and see if the two issues are related.
No problem! If you're able to tag me in the question that'd be great. I can take a look and see if the two issues are related.
I wasn't sure how to tag/dm you (new to the Forum) so I'll post the link to the second question here:
https://community.safe.com/s/question/0D5Dm00000na4VYKAY/bulkattributerenamer-dynamically-rename-attributes
I notice that you have Feature Cashing active. Does the problem also occur when Feature Caching is off?
I notice that you have Feature Cashing active. Does the problem also occur when Feature Caching is off?
Yes this also happens if Feature Cashing is turned off (tested by writing the output to a csv file).
@paetzold_s
After some discussion with our developers, it looks like this is expected behavior with the FeatureReader. Attributes to expose only affects the authoring environment (the GUI you're editing the transformers in) and doesn't change at runtime. To change which attributes are exposed, you'll need to reopen the FeatureReader and click ok after changing the user parameter's value. As a result we've closed the ticket I shared above.
Let me know if you have any follow up questions or clarification.
Dan
@paetzold_s
After some discussion with our developers, it looks like this is expected behavior with the FeatureReader. Attributes to expose only affects the authoring environment (the GUI you're editing the transformers in) and doesn't change at runtime. To change which attributes are exposed, you'll need to reopen the FeatureReader and click ok after changing the user parameter's value. As a result we've closed the ticket I shared above.
Let me know if you have any follow up questions or clarification.
Dan
Thank you for the clarification. This behavior is a bit unintuitve.
If this is the expected behavior how can I model this functionality? I have csv files which don't have a common structure. So at the start of the workflow I prompt the user to set the column numbers for the relevant columns. Then I rename these columns and do further processing.
I have 2 potential workarounds:
1) - Set the columns to be exposed by the FeatureReader to e.g. "col0 col1 ... col999"
- rename the relevant columns in an AttributeManager
- filter out all other columns with an AttributeKeeper
2) - open the csv file as a txt file
- insert a new header at the top e.g. ;;;relevant_Col_1;;relevant_Col_2;;;;;relevant_Col_3
- expose the cols "relevant_Col_1", "relevant_Col_2" and "relevant_Col_3"
both solutions seem a bit inelegant. is there a better way I'm missing?
