Dynamic Workflows: Destination Schema Contains Different Feature Type Names

Liz Sanderson
Liz Sanderson
  • Updated

FME Version

  • FME 2022.0

Introduction

The previous article showed how any dataset in any format can be used as the template for the destination schema. In that scenario, the dynamic writer needs to be able to find that schema definition by name. So what happens if a new Feature Type name is used to write out the data?

In this situation, use a parameter inside the Writer Feature Type called 'Schema Definition Name'. This parameter informs the writer of the correct name to use when searching the source for a matching schema.

This can come in handy if:

  • The schema source and destination dataset have different Feature Type names.
  • The schema source and destination are databases and the Feature Type names contain the Table Qualifier (e.g. <prefix>.<table_name>). This is a common challenge with dynamic workspaces.

 

Workspace and Data

A finished version of the workspace created in this example can be found in the zip file attached to this tutorial, titled "3-FeatureTypeName". 
 

Step-by-Step Instructions

In this example, an updated city schema is provided as a database, which contains generic Feature Type names. To create a dynamic workflow and write out the data using this schema, the database must be added as a Workspace Resource. We will then change the output dataset names to include the city as a prefix (i.e. Vancouver_BusStops).
 

1. Add the Source Dataset

Open a new FME Workspace. From the Readers menu, select "Add Reader" and configure it as follows:

  • Format: OGC Geopackage
  • Source: <Tutorial Download>\resources\CityDatabase.gpkg
  • Parameters > Table List: BusStops, CityParks, Roads
  • Workflow Options: Single Merged Feature Type

OGCReader.png
 

2. Add the Destination Dataset

From the Writers menu, select "Add Writer" and configure it as follows:

  • Format: MapInfo TAB (MITAB)
  • Dataset: <Tutorial Download>\output
  • Table Definition: Dynamic (Advanced)

MapInfo.png 

 

3. Add the Database as a Resource

In the Readers menu, select "Add Reader as Resource"
ReaderAsResource.png

Configure it as follows:

  • Format: SpatiaLite
  • Dataset: SchemaDatabase.sl3

SpatialLite.png


Once the database is added, an entry is placed in the Navigator pane in FME Workbench:

image
 

4. Create the New Table Name Attribute

To append the city name to the feature type names, add a StringConcatenator transformer after the reader. Double-click it to open the parameters. Set the Expression Results to Create New Attribute and the New Attribute to NewName. 
Next, for String Parts:

String Type String Value
Constant Vancouver_
Attribute Value @Value(fme_feature_type)

StringConcat.png

 

5. Map the Schema

Configure the workspace to map the source to the new schema contained in the database. Add an AttributeManager between the StringConcatenator and the writer feature type. In the parameters rename the following attributes: 

  • PRIMARYINDEX -> PID
  • class -> ROAD_CLASS
  • featureID -> FEATUREID
  • numberOfLanes -> ROAD_LANES
  • routeNumber -> ROUTE_NUM
  • routeType -> ROUTE_TYPE
  • type -> TYPE
  • name -> PARK_NAME
  • name_alt -> NAME_ALT
  • STOPABBR -> STOP_ABBR
  • STOPNAME -> STOP_NAME

ex5-5.png
 

6. Set the Schema Definition in the Writer Feature Type

Open the writer feature type parameters and set Table Name to the attribute containing your new names (NewName). In the image below, the SpatiaLite database has been entered as the 'Schema Source'. Use the original fme_feature_type attribute for the 'Schema Definition Name' so the writer can find the table names inside the SpatiaLite database. If you don't do this, the writer will look for your concatenated name in the database and be unable to find the correct feature types.
NewNameOutput.png
 

7. Run the Workspace

Run the workspace and check that the output datasets have the correct schema.


Maintaining the Workspace

At this stage, any updates can be added to this workflow without changing the existing workspace layout. Changes can also be made to the database schema outside of the FME environment and the workspace will handle the new schema automatically.

Note that in this example, if the database schema did change, a user would need to update the AttributeManager transformer to provide the correct attribute mapping. However, using a SchemaMapper transformer in this scenario would provide an external method to handle any mapping issues, making workspace changes unnecessary. For complex workflows, this is a perfect way to alleviate maintenance issues in the future. This is discussed further in Advanced Technique - Using the SchemaMapper.
 

Additional Resources

A full SchemaMapper tutorial can be found here: SchemaMapper Transformer Tutorial

 

Data Attribution

The data used here is adapted from data made available by the City of Vancouver, British Columbia. It contains information licensed under the Open Government License - Vancouver.

Was this article helpful?

Comments

0 comments

Please sign in to leave a comment.