Hi All, I have a Child workbench which takes input as SDE FeatureClasses and Creates FGDB. i am passing all feature classes dynamically to the writer (all different types like points, polygons and polyline featureclasses). My SDE Feature Class has Long Attribute(Fields) Names and I required to create FGDB Feature Classes with Short Attribute(Fields) names. I have a web service which gives JSON output of Short Names. For each feature class, i need to connect to web service and get short names, create FGDB feature class with these short names. Could anyone have an idea how can I dynamically update FGDB feature class?
Solved
Dynamic Attribute Mapping
Best answer by david_r
Here's a sample workspace that shows how to leverage the FeatureReader and a PythonCaller to rename attributes in a dynamic workflow. You'll notice that the code in the PythonCaller has two main branches, one for the schema features and one for the data features.
You'll have to implement your own renaming function in the get_new_attribute_name() method, the current code is just for demonstration purposes. You may also have to adapt the rules on line 8 to make sure that necessary format attributes aren't renamed.
Let me know if anything is unclear.
When using a dynamic workflow, the default behavior is that FME uses the format attribute "fme_feature_type" for the output feature class. The value of "fme_feature_type" will be the feature class name from your reader. You can create a new attribute e.g. "new_fme_feature_type" which could be populated by an HTTPCaller which requests the short feature class name and then specify it like this on the output feature type:
Note that the schema definition name must reference the feature class name from your source dataset (fme_feature_type).
david_r wrote:
When using a dynamic workflow, the default behavior is that FME uses the format attribute "fme_feature_type" for the output feature class. The value of "fme_feature_type" will be the feature class name from your reader. You can create a new attribute e.g. "new_fme_feature_type" which could be populated by an HTTPCaller which requests the short feature class name and then specify it like this on the output feature type:
Note that the schema definition name must reference the feature class name from your source dataset (fme_feature_type).
david_r wrote:
When using a dynamic workflow, the default behavior is that FME uses the format attribute "fme_feature_type" for the output feature class. The value of "fme_feature_type" will be the feature class name from your reader. You can create a new attribute e.g. "new_fme_feature_type" which could be populated by an HTTPCaller which requests the short feature class name and then specify it like this on the output feature type:
Note that the schema definition name must reference the feature class name from your source dataset (fme_feature_type).
r8 wrote:
Sorry David, mistake was mine. i updated the question. I need to update the attribute names not feature class names.
If you need to dynamically rename attributes, I recommend that you read up on the so-called "schema feature": https://knowledge.safe.com/articles/1051/index.html
My recommendation would be to replace the classic reader with a FeatureReader (set to dynamic), which will automatically return both the schema feature (one per feature class) and all the features. You will then have to:
- On the schema feature, rename the relevant attribute names in the "attribute{}.name" list
- On the data features, you'll have to rename the attributes identically to the schema feature
I recommend that you send both the schema feature and the data features to a FeatureWriter, configured to use the schema from the schema feature (not the reader).
You can do the renaming of the schema feature and the data features using regular transformers, but personally I find it easier to use Python, it will depend on what you're more comfortable doing.
Also, feel free to vote for this idea, which would've made the whole thing a lot easier :-)
david_r wrote:
If you need to dynamically rename attributes, I recommend that you read up on the so-called "schema feature": https://knowledge.safe.com/articles/1051/index.html
My recommendation would be to replace the classic reader with a FeatureReader (set to dynamic), which will automatically return both the schema feature (one per feature class) and all the features. You will then have to:
- On the schema feature, rename the relevant attribute names in the "attribute{}.name" list
- On the data features, you'll have to rename the attributes identically to the schema feature
I recommend that you send both the schema feature and the data features to a FeatureWriter, configured to use the schema from the schema feature (not the reader).
You can do the renaming of the schema feature and the data features using regular transformers, but personally I find it easier to use Python, it will depend on what you're more comfortable doing.
Also, feel free to vote for this idea, which would've made the whole thing a lot easier :-)
david_r wrote:
If you need to dynamically rename attributes, I recommend that you read up on the so-called "schema feature": https://knowledge.safe.com/articles/1051/index.html
My recommendation would be to replace the classic reader with a FeatureReader (set to dynamic), which will automatically return both the schema feature (one per feature class) and all the features. You will then have to:
- On the schema feature, rename the relevant attribute names in the "attribute{}.name" list
- On the data features, you'll have to rename the attributes identically to the schema feature
I recommend that you send both the schema feature and the data features to a FeatureWriter, configured to use the schema from the schema feature (not the reader).
You can do the renaming of the schema feature and the data features using regular transformers, but personally I find it easier to use Python, it will depend on what you're more comfortable doing.
Also, feel free to vote for this idea, which would've made the whole thing a lot easier :-)
r8 wrote:
Hi David, using FeatureReader I am getting the schema, but I am not able to rename using PythonCaller. Could you please suggest how to proceed. Thank you.
Hi David,
Please find the attachment to know what I am doing. Let me know if you need any other info.
attributerename.png
- Best Answer
Here's a sample workspace that shows how to leverage the FeatureReader and a PythonCaller to rename attributes in a dynamic workflow. You'll notice that the code in the PythonCaller has two main branches, one for the schema features and one for the data features.
You'll have to implement your own renaming function in the get_new_attribute_name() method, the current code is just for demonstration purposes. You may also have to adapt the rules on line 8 to make sure that necessary format attributes aren't renamed.
Let me know if anything is unclear.
david_r wrote:
Here's a sample workspace that shows how to leverage the FeatureReader and a PythonCaller to rename attributes in a dynamic workflow. You'll notice that the code in the PythonCaller has two main branches, one for the schema features and one for the data features.
You'll have to implement your own renaming function in the get_new_attribute_name() method, the current code is just for demonstration purposes. You may also have to adapt the rules on line 8 to make sure that necessary format attributes aren't renamed.
Let me know if anything is unclear.
A different approach. If the source schema is known, you can create an external table to define mapping rule between source attribute names and destination attribute names and also destination schema, like this.
Once you have created such a table, you can use it as a schema mapping table ('OldAttribute' column and 'NewAttribute' column) for a SchemaMapper, and also as a workspace resource (schema definition table - all columns except 'OldAttribute') for a dynamic writer feature type.
The attached workspace demonstrates how it works.
dynamic-workflow-example-2.fmwt (FME 2017.0)
The method above is a variation of the "Destination Schema is Derived from a Lookup Table" method. See here to learn more. Dynamic Workflows: Destination Schema is Derived from a Lookup Table
takashi wrote:
A different approach. If the source schema is known, you can create an external table to define mapping rule between source attribute names and destination attribute names and also destination schema, like this.
Once you have created such a table, you can use it as a schema mapping table ('OldAttribute' column and 'NewAttribute' column) for a SchemaMapper, and also as a workspace resource (schema definition table - all columns except 'OldAttribute') for a dynamic writer feature type.
The attached workspace demonstrates how it works.
dynamic-workflow-example-2.fmwt (FME 2017.0)
The method above is a variation of the "Destination Schema is Derived from a Lookup Table" method. See here to learn more. Dynamic Workflows: Destination Schema is Derived from a Lookup Table
Please let me know if know any dynamic process. Thank you.
takashi wrote:
A different approach. If the source schema is known, you can create an external table to define mapping rule between source attribute names and destination attribute names and also destination schema, like this.
Once you have created such a table, you can use it as a schema mapping table ('OldAttribute' column and 'NewAttribute' column) for a SchemaMapper, and also as a workspace resource (schema definition table - all columns except 'OldAttribute') for a dynamic writer feature type.
The attached workspace demonstrates how it works.
dynamic-workflow-example-2.fmwt (FME 2017.0)
The method above is a variation of the "Destination Schema is Derived from a Lookup Table" method. See here to learn more. Dynamic Workflows: Destination Schema is Derived from a Lookup Table
david_r wrote:
Here's a sample workspace that shows how to leverage the FeatureReader and a PythonCaller to rename attributes in a dynamic workflow. You'll notice that the code in the PythonCaller has two main branches, one for the schema features and one for the data features.
You'll have to implement your own renaming function in the get_new_attribute_name() method, the current code is just for demonstration purposes. You may also have to adapt the rules on line 8 to make sure that necessary format attributes aren't renamed.
Let me know if anything is unclear.
Hey David. Would it be possible to get hold of this sample workspace (rename-dynamic-attributes.fmw) as I am facing similar issues getting my head around renaming dynamic attributes.
Cheers!
tdhughes wrote:
Hey David. Would it be possible to get hold of this sample workspace (rename-dynamic-attributes.fmw) as I am facing similar issues getting my head around renaming dynamic attributes.
Cheers!
@mark2atsafe Are you able to dig up this workspace from the old forums? Seems like it got lost during the migration, and I haven't got a local copy anymore.
+15- Safer
tdhughes wrote:
Hey David. Would it be possible to get hold of this sample workspace (rename-dynamic-attributes.fmw) as I am facing similar issues getting my head around renaming dynamic attributes.
Cheers!
Hi @tdhughes , I fixed the original link but also attached it to my comment for your convenience.
tdhughes wrote:
Hey David. Would it be possible to get hold of this sample workspace (rename-dynamic-attributes.fmw) as I am facing similar issues getting my head around renaming dynamic attributes.
Cheers!
Thanks @lizatsafe !
Reply
Rich Text Editor, editor1
Editor toolbars
Press ALT 0 for help
Helpful Members This Week
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.