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”?
So let’s take a closer look at it.
Sorry. Couldn’t resist that joke. But let’s seriously talk about this, because it can affect how an entire workspace operates.
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:
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:
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:
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.
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:
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:
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:
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:
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.
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:
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.
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”:
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.
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:
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
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.
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)
