Writer Feature Types are objects on the Workbench canvas that define the schema of the data being written. Most importantly they define two specific things: they define the layers being written to a destination dataset and the attributes that those layers are to possess.
Let's first look at attribute definitions.
Each Writer feature type has a tab labelled User Attributes. This tab allows you to define the attributes that will be associated with this feature type. Attributes can be defined by either editing an existing feature type (as we saw in the chapter on Data Transformations) or can be defined when a new feature type is added to a workspace (as we will see shortly).
There are three options as to how attributes can be defined:
These options are Automatic, Manual, or Dynamic. We’ll look at Manual definitions first, since they are the easiest to understand.
A manual attribute definition is simply when the workspace author manually enters attribute names, and manually selects the attribute types, like so:
In this example, we are starting to define an address table. We have entered the definitions for two attributes, and are just entering a definition for the third.
In the Workbench canvas, the feature type would look like this:
An automatic attribute definition is when Workbench itself automatically defines the list of attributes, depending upon what Reader feature types are connected.
Here – when the user chooses the Automatic option - the attribute definition fields are left empty and uneditable, like so:
Similarly, on the canvas the feature type is also empty initially:
Now, what makes the definitions automatic is the action that occurs when a Reader feature type is connected:
Notice that all of the attributes defined on the Reader feature type are now copied over to the Writer feature type automatically.
Because this operates automatically, if the Reader feature type is removed, and another one connected, the list of attributes on the Writer feature type will be immediately updated to match. Or, if a second Reader feature type is connected, then the list of attributes updates to become a union of the two types:
This is really useful because it means that multiple streams of data can be merged into a single feature type, and all attribute definitions are taken care of.
However, what this won’t do is handle the scenario where you change the Reader dataset parameter to read data with a different set of attributes. In other words, the Writer attributes will only be defined by what is connected, not what actually exists in the source data. For that scenario you need dynamic attributes.
Specifying dynamic attributes also causes the Dynamic Properties option (in the General tab) to be selected:
Like an automatic definition you don’t see attributes on the initial feature type. However, neither do you see attributes when Reader feature types are connected! A dynamic feature type truly has no definition in advance. Instead, it dynamically takes its attribute definitions from either whatever data is fed to it when the workspace is run, or another set of schema definitions selected by the user.
######TIP To clarify, the “automatic” setting takes its attribute definition from whatever is connected to it in the workspace. If the Source Dataset parameter is changed, it will have no effect. The “dynamic” setting is different. If the Source Dataset parameter is changed, a dynamic schema will (by default) take its attribute definition from whatever source data is being read.
Having looked at attribute definitions, now let's look at how to manage the feature type objects themselves.
As we have already seen, the Writer schema defines "what we want" as a destination dataset. So if you want to write data to a particular layer, in a particular dataset, then you have to ensure that the layer is defined as a feature type in the canvas.
In some cases this happens automatically. When you generate a workspace the source dataset(s) you choose are scanned and all of the layers within get matching feature type objects in the workspace - both on the Reader and the Writer.
######TIP When FME adds Writer feature types as part of a new workspace, those feature types will get a fixed (manual) attribute definition that is taken from the selected source dataset. These attributes can then be manually edited, as demonstrated in the chapter on Data Transformation.
However, in most cases you need to manage Writer feature types separately, because "what you want" is not the same as "what you have". For example, perhaps you want to divide an incoming layer of data into two layers in the output dataset (in which case you will need to add a new Writer feature type).
Adding a Writer feature type manually has this effect on the hierarchy diagram. Your output was designed to have only a single layer; now it will have two.
Feature Types can be added manually to a writer using Writers>Add Feature Type on the menubar.
######TIP At least one writer must exist in the translation hierarchy; else this option will be greyed out.
Choosing to add a feature type adds one to the translation, and then causes the Feature Type Properties dialog to appear in order to edit the feature type properties.
As when editing the schema, the General tab can be used to define the new feature type’s name.
######TIP Remember, with format-specific terminology, instead of "Feature Type" this dialog's labels may state "Feature Class," "Layer," "Sheet," or whatever terminology is specific to the format of data you are writing.
As usual, the User Attributes tab can be used to define the new feature type’s attribute schema.
When a new Writer is being created the option is provided to add new feature types:
Addition of feature types can be completed in a number of ways:
- Automatic: Adds a new feature type with the attribute definition parameter set to automatic
- Manual: Adds a new feature type with the attribute definition parameter set to manual
- Copy from Reader: Adds a new feature type with the attribute definition parameter set to manual, but pre-defined to the schema of an existing Reader feature type
- Import from Dataset: Adds a new feature type with the attribute definition parameter set to manual, but pre-defined to the schema of an external dataset (just like using the Import Feature Types tool)
- Dynamic: Adds a new feature type with the attribute definition parameter set to dynamic
- None: Does not add any new feature type
When adding a Writer it's possible to create a new feature type whose attribute schema is pre-defined to that of an existing Reader. However, if you already have a Writer, you can still carry out the same procedure of copying a Reader schema. This is simply done by selecting the required Reader feature types, right-clicking them, and using the option Duplicate (on Writer).
The command causes duplicates of the Reader feature types to be added to the writer, and source/destination feature types to be automatically connected.
Again, at least one writer must exist in the translation hierarchy; else this option will be greyed out.
The remove feature types tool is found on the menubar, and simply removes one or more feature types from the Writer.
Another way to do this is to select the feature type on the canvas and press the keyboard delete key.
For example, if there is a destination dataset layer that the user wishes to no longer write, then they would delete the matching feature type from the workspace.
Whenever all feature types are deleted from a Writer then FME will prompt the user to decide whether to remove the Writer component as well.
This makes sense because if there are no feature types you wish to write, why would you still wish to write the dataset at all?
If you answer No, then the feature types are all removed, but the Writer is left in the translation. We call this a "dangling” Writer, because it has no children in the hierarchy.
######TIP A dangling Writer isn’t as much of a problem as a Reader, since there is no data to be written, although it can cause a loss of performance depending on other (advanced) factors such as the order of Writers.