Hi FME’ers,

Recent FME training courses have been conducted on FME2016.1.1 and the one question that everyone asks is “what’s that red line on the rejected ports”?

Rejected Port Red Line

So let’s take a closer look at it.

Rejected Port Red Line Closer Look

Sorry. Couldn’t resist that joke. But let’s seriously talk about this, because it can affect how an entire workspace operates.

EvangelistBanner7

Rejected Features

This is a great example of evolving functionality in FME, so it’s best to explain this new feature by tracing the story that led to its development.

In the past, say 2014 and earlier, if a feature was bad and caused a transformer to fail, then the translation would stop. For example, if I tried to use a character string (instead of a number) as the coordinate in a 2DPointReplacer (now the VertexCreator), the transformer would cause the translation to halt with an error, like this in 2013:

Rejected Feature Log Error

In one sense that’s good – because it is an error – but also bad because an entire translation would stop over just a single problem.

That’s why – in 2015 and 2016 – we started adding more <Rejected> ports to our transformers. That way a transformer could output bad features through those ports (like this 2015 VertexCreator) without stopping the translation:

VertexCreator Rejected Port

That was better, but it could get awkward if you did want to stop the translation, because you would have to go round to every <Rejected> port and attach a Terminator transformer:

Rejected Port Connected to Terminator

So, that’s why we added this new functionality. Think of it as automatically adding an optional Terminator transformer to every <Rejected> port.

That way the translation can still be stopped for an error, but you can turn off that behaviour if desired.

So let’s see how that works.

EvangelistBanner7

New Workspaces

Start Workbench in FME2016.1.1 and – in a new workspace – place a transformer that has a <Rejected> port. Here I dropped down a PointConnector:

PointConnector Rejected Port

It has the red “Terminator” line. Run the workspace and… oh! Parks are area features, the PointConnector only accepts points. So the Park features are rejected and the workspace terminates:

PointConnector Rejected Feature

In fact it terminates as soon as the first feature arrives. The message it provides in the log is:

      PointConnector_<Rejected>: Termination Message: 'PointConnector output a <Rejected> feature.'

So we know what happened and why.

But let’s say that I don’t want to terminate the workspace. The PointConnector is just a small part of a larger workspace and if it fails I want the rest of that workspace to continue. Well, there is a new parameter available in the Navigator window to do just that:

Rejected Feature Handling Navigator Parameter

In a new workspace, by default that parameter is set to Terminate Translation – which is why users in our training course creating a new workspace see the red line on <Rejected> ports – but it can also be changed to Continue Translation:

Rejected Feature Handling Parameter Values

If I change the Rejected Feature Handling parameter to “Continue Translation” then a <Rejected> feature won’t cause the translation to stop. The “red line” symbol disappears from all my transformers and the translation will continue regardless of such features.

Of course, if I do have a particular <Rejected> port that is more important, and I do want to stop a translation there – I can manually attach a Terminator transformer to it. But the point is that if I want all <Rejected> ports to fail, I don’t need to attach a Terminator transformer to every one of them.

EvangelistBanner7

Old Workspaces

For backwards compatibility it’s important that older workspaces run exactly the same as they did before. In this case we don’t want this new functionality to suddenly start terminating a workspace where that never happened before.

So… let me open an older workspace in FME, like this one in our training course created in 2016.0:

Rejected Feature Handling in Older Workspace

Ah! The parameter is set to Continue and there is no red line on the transformer.

In short, we deliberately don’t turn on this behaviour for old workspaces in order to preserve backwards compatibility. If you do want it, you can turn it on by yourself. Simple.

This is a trick we often use when adding new functionality. It’s turned on by default for new workspaces, but old workspaces retain the old way of working.

EvangelistBanner7

New Workspace Defaults

The only question remaining is this: “What if I don’t want this turned on in my new workspaces. Do I need to change that setting for every workspace I create?”

The answer, of course, is no. We wouldn’t make you do that. Instead simply open Tools > FME Options > Translation and change the option “Rejected Feature Handling Default” to “Continue Translation”:

Rejected Feature Handling Option

Then any new workspace you create will default to Continue Translation and you won’t see the red line in a workspace unless you change it in the Navigator window.

EvangelistBanner7

Summary

In summary we added this capability to make it easier for users to handle <Rejected> ports en masse. In particular it should be most useful when you’re publishing the workspace to FME Server. But we also made sure that it was possible to turn off the functionality if it’s not required.

There are a couple of potential future changes that might happen for 2017. The first is just visual: we’re very likely (I’d say 99% likely) to change the graphic from a red line to a red “stop” sign, something like this:

Rejected Port Possible Future Style

Secondly, it’s possible that we might change the default to “Continue Translation” for all new workspaces as well as old ones. I’d say this one is about 50:50 – we’re really not sure which is better. So if you have a preference, do let us know.

Regards

NewBlogSignature

ps: If you hadn’t heard, the keynote speaker at next year’s FME International User Conference is… Chris Hadfield! Yes, that Chris Hadfield. Not just astronaut, not just the best tache in Canada, but also a singer-songwriter (I’m listening to his album now, and it’s pretty good) and a very inspiring speaker. Of course our conferences are pretty amazing anyway, and a great FME learning experience, so be sure to check out the web site and register while the super early bird pricing still applies.

About FME FME Evangelist FME Options Navigator Rejected Feature Handling Terminator Workbench Workflow

Mark Ireland

Mark, aka iMark, is the FME Evangelist (est. 2004) and has a passion for FME Training. He likes being able to help people understand and use technology in new and interesting ways. One of his other passions is football (aka. Soccer). He likes both technology and soccer so much that he wrote an article about the two together! Who would’ve thought? (Answer: iMark)

Comments

2 Responses to “FME 2016.1 New Functionality: Rejected Feature Termination”

  1. Wow ! Another great functionality that saves time *and* takes into account an old FME user’s concerns (will FME still run on my FME 2012 workspace ? 🙂 )
    Did not have time to test it yet, but did you think of a default behavior that would turn the “rejected” port to “non-terminating” when it is connected to any further transformer ? (similar to an “exception” mechanism in java for example : if you catch the exception, then it is your responsibility to handle it properly)
    Regards,
    Fred

  2. Michael Habarta says:

    I vote for –> change the default to “Continue Translation”
    That’s what I expected since I got to know the “Rejected” port.

    If I want to stop it, I add a Terminator. Most likely however in my environment I would need to collect the “problem cases” and create messages about the evildoers in order to inform the user about the problems instead of leving him with a broken translation.

    Michael

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts