Hi FME’ers,
There’s one piece of new functionality in FME2010 that wasn’t mentioned at the user conference, and which I only found recently. However, it’s one that a number of users have asked about before, so I wanted to mention it.

Most of us will be familiar with published parameters for prompting users to enter data at runtime and with the Custom Parameter introduced in FME2009 (a published parameter not tied to any particular transformer or writer).

“Choice with Alias” is a new type of Custom Parameter and helps a workspace author to simplify parameter dialogs with a drop-down list of different options.

So if you’re interested in making parameter prompts more legible for the end-user, then read on…

Choice with Alias is a custom parameter designed for when you want to substitute the selected entry in a drop down list with a completely different value. In effect it’s a lookup table: the user picks one entry from a list and a lookup table determines which value this returns to FME.

This is a great benefit where the returned value needs to be used directly within a writer parameter.

For example, I created a workspace which translates to MicroStation Design (DGN) format. One of the parameters for the DGN writer is Cell Library File. A Cell Library defines symbols to use on a map or CAD drawing.

I have four Cell Libraries for different map scales. They are:

I want the end user of this workspace (for example someone accessing it via FME Server) to be able to select which set of map symbols to use on the output, but I don’t want them to have to pick from the list of files, whose names would be fairly meaningless. I want them to select from:

So this is where Choice with Alias comes in. I simply define the parameter as a mapping between what the actual values should be, and what I want the end user to see:

Now when a user runs the workspace and selects “1:2500 Scale Map Symbols” the parameter actually returns the value “C:MyDataProjectDGNSourceCellsCellLib2500.cel” for me to use in the writer.

This technique would work for any parameter in any reader or writer.

Creating a Choice with Alias Parameter
That’s the theory, and creating such a parameter in practice is just as simple:

Firstly I right-click in an empty part of the Navigator Window and choose the option to Add Published Parameter (click on all the following screenshots to enlarge them):

Then I choose the parameter type Choice with Alias and hit the configuration button

Now I get a dialog in which to enter my mappings.

When I run the workspace I get this dialog:

At this point you might be asking, “but how does the value get passed to the writer?” Good point. The Custom Parameter still needs to be married to the actual writer parameter. This is actually existing functionality (i.e. it isn’t tied to the Choice with Alias parameter alone) but we’ll show it anyway.

To link the two I simply locate the actual writer parameter, right-click it and choose the option Set to Publish Parameter.

Then when prompted I select the newly-created Choice with Alias parameter, in this case I called it CellLibParam:

Now the two parameters are shared, so that when the workspace is run the mapped value of the custom parameter (the true cell file name) is returned directly to this writer parameter. Simple.

More Common Scenarios
There are a number of use cases we see for this. Here are a few of them:

Format Type
Format Type is the big use-case for this functionality, because to pass a format onto the generic writer it has to be the official FME keyword such as SHAPE, OGCKML, DGNV8, etc. These keywords are not what you really want to present for a user to select from.

But the really great thing here is that you don’t even have to define these in the lookup table; the Choice with Alias dialog has predefined lookups selectable from the formats gallery. Here (below) I can choose from a writer format instead of entering my own text into a blank row:

This option brings up the formats gallery where I choose (for example) KML:

…and here it is in the configuration dialog:

Now because my users probably don’t know who or what the OGC is, I will rename the format to something they are more likely to recognize:

Coordinate System
Coordinate System is another type of alias which has a predefined lookup, though of course here it will let you select from the Coordinate System Gallery, rather than the Formats Gallery:

Again an alias is useful because you don’t want to present your end users with options such as AZHP-CIF or AZHP-CF.

Schema Type
There are very many things you could do involving the Choice with Alias parameter, but one of the most intriguing is for schema selection.

For example, I use FME to create spatial datasets with different structures for different departments in my organization. I’d like to allow users to run the process on FME Server but there’s a workspace for each department, and it’s not easy to define schema.

Well how’s this for a prompt? It would let the user pick what schema to write the data in without having to know the technical details:

The question is, how do I use this response within a workspace to define the output schema?

Well, one way would be by creating multiple feature types and routing the data to the correct one with a Tester. However, now we have Dynamic Schema functionality I can map the user input to a value which represents a specific schema definition.

It’s still a little uncertain how this would work, but I think that you could probably read the value into the fme_feature_type attribute which would define how to write the output. You would just need to have a schema source with the same name defined in the workspace.

So with a Generic Reader, Generic Writer, and Dynamic Schema I have the holy trinity of interoperability: I can read any data in any format, can write it out to any format, and can specify the schema (or data model) by which to structure the output data.

As you can see, the Choice with Alias function makes it really easy for a user to select which format, which coordinate system and which schema the output should be in, since the phrasing of the prompts can be matched to local terminology.

This functionality is most useful for reader or writer parameters. Where this parameter won’t make much difference is when you are prompting for a parameter value to be used in the workspace itself, for example retrieved with a ParameterFetcher. That’s because you could put the alias’ directly into a plain Choice parameter and map the values with a ValueMapper transformer; rather than defining an alias type parameter.

However, in that scenario, I would still switch to the Choice with Alias option anyway, because it’s easier to define your list inside the parameter than by searching a huge workspace for a particular ValueMapper. Plus you can define the parameter once and use it in several places in a single workspace (for example I might want to map a certain action to a specific database username/password used in multiple transformers).

Also, this functionality is currently incompatible with FME Server. Integration is, however, scheduled to be implemented by FME2010, so Server support for this parameter type should be in the next official release.

Update: This has been implemented so is supported by FME2010 and FME2010 Server.

More Info
For more information on this subject:

This Edition of the FME Evangelist…
…was written to the music of Carl Weathersby. His style of blues is epitomized by this recent jam session.

And I will be there, eating ribs and grooving out, when he performs at Kingston Mines in Chicago next Monday. That’s the unofficial start to my vacation (I still have a training course to give in Toronto) but I will be out of the office till mid August. So have a fun summer and I will be back with more FME stuff later.

About FME Data Interoperability DGN Dynamic Schema FME Desktop Parameters Usability

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 are closed.

Related Posts