Maintenance Methodology

Maintenance methodology is weak when a workspace's design doesn't allow easy updates or expansion. Some key indicators indicate design weakness.

Duplicated Transformers

Duplicating the same transformer again and again – maybe creating multiple streams to do so – indicates a weak design.

For example, the multiple AttributeManager transformers here will cause maintenance problems:

The first problem is that each additional year to be supported requires a new transformer to handle it. The second problem is that a small change in the AttributeManager requires each transformer to be individually edited.

We can also say that this layout results in a style that is not as compact as it should be.

The solution here is to replace all of the above with a single AttributeValueMapper transformer (or possibly a SchemaMapper) to allow scaling with the minimum number of edits.

The general solution is to watch for instances of multiple transformers and try to assess whether there is a better design.

Complexity

A workspace design is weak when it is more complex than necessary. Complexity means a solution becomes harder to maintain and harder to scale, especially when carried out by someone other than the original author.

There are various types of complexity to watch for:

• Excess Scripting: The use of Python scripting when an equivalent transformer already exists
• Low-Level Complexity: The use of FME functions and factories when an equivalent transformer already exists
• Multiple Workspaces: When multiple workspaces are chained in a way that is unnecessary
• Workspace Style: When workspace style is so convoluted it is difficult to understand

Before putting a project into production, it is worth asking a colleague to evaluate it for clarity. Sections of workspace they cannot easily understand are points that future authors will also find difficult to maintain.

Database Connections

Database formats require connection parameters. Sometimes these parameters need to be applied multiple times in the same workspace, and sometimes the parameters need to be changed when switching platforms (for example from testing to a live environment).

It is possible to embed database connection values inside a workspace, adding that information wherever it is required. However, a better solution involves a tool in FME called Database Connections.

Database Connections are a pre-defined set of connection and authentication parameters, stored under a single name. Once created, a connection name is used instead of the actual parameters.

Creating a Database Connection

When using a database format and prompted for connection details, choose the option to add a connection:

A new connection is defined by selecting the database type, entering connection parameters, and giving the connection a name:

Now, whenever a database connection is required (here in an SQLExecutor transformer) the pre-defined connection is selected:

Now the repeated use of a database does not require repeated entry of the same credentials, and if the credentials change only one connection needs to be edited. Both of these features benefit the maintenance and scaling of a workspace.

Another benefit is that of security. Embedded connection information is stored inside the workspace file, posing a potential security risk. Database Connections are stored securely, outside of the workspace, and can not easily be accessed by someone else. If the workspace is passed to another user, they will have to set up their connection with their own parameters.