Standalone Published Parameters

From Fmepedia

aka Custom Parameters or Independent Parameters


Table of contents


Introduction

Published Parameters have been a part of FME since the inception of Custom Transformers.

With FME 2008 it is now possible to create published parameters that are not initially (or at all) related to a particular transformer setting.

This is a really huge step forward in the ability to create workspaces customized to your particular translation needs, and set up for non FME users to make use of. Using this type of functionality is definitely part of what we call FME Best Practice.


Creating a Standalone Parameter

To create a standalone published parameter right-click on the Navigator pane and choose the option to "Add Published Parameter".

You will be provided with a dialog in which to enter the type of parameter, name, label and default value. You can also choose whether this parameter is to be optional or compulsory.


Using a Standalone Parameter

Once created you can use the parameter by either...

  • Right-clicking on the parameter and choosing 'apply to' to apply that parameter to another setting
  • Right-clicking any setting in the navigator, choosing 'set to published parameter' and selecting the newly created parameter
  • Using the ParameterFetcher transformer with the parameter name specified


Types of Parameter

The range of parameters you may create is quite extensive.

  • Choice: A pick list of values
  • Float: floating point number
  • Integer: An integer number
  • Text: A text string
  • Password: A text string whose value is hidden
  • Filename: The name (and path) of a file
  • Directory: The name (and path) of a directory
  • List: An FME list attribute??? [note to self - check what this does!]
  • Color Picker: An FME color value
  • Coordinate System Name: A coordinate system


Any type that is "... or choice" allows the user to either pick from a list or enter a different value.

  • Choice or Float: Either enter a floating point number or select one from a pick list
  • Choice or Integer: Either enter an integer number or select one from a pick list
  • Choice or String: Either enter a text string or select one from a pick list


Example 1

Let's take the example of a workspace including a LineGeneralizer transformer.

The workspace creator wishes the generalizer to be optional according to user requirements.

Previously he would have to publish the tolerance setting for the transformer, and rely on the user to set it to zero if he wished to have no generalization occur. With the new functionality he can create a standalone published parameter with a drop down list of choices of either yes/no.

The user can then be prompted Generalise: Yes Please/No Thanks.



Above: User prompt


The response to the prompt can be assigned to an attribute using the ParameterFetcher transformer, and this attribute used in a Tester to check for a Yes value.



Above: The full workspace showing ParameterFetcher and Tester.


If the test passes the generalizer is used, if the test fails it is bypassed.


Above: When the Generalizer is used


Above: When the Generalizer is not used


Existing Published Parameters

Existing Published Parameters will work as they always did, but now have unrestricted sharing abilities.

In other words, there was a previous restriction that published parameters could only be shared with parameters (eg transformer settings) of the exact same type. This limitation has been removed in builds 5098 or greater.

This gives the user greater scope by allowing - for example - an integer type parameter to be shared with a float type setting.


Example 2

For example, a company wishes to create its own database table to record the history of its FME translations. A sort of metadata table created by an FME workspace.

Rather than save the log file in the table the user will be prompted for a location for the log, and that location recorded to the table.



Above: The workspace. The main part of the workspace is irrelevant. The important part is the metadata section where date and log file location are set


Previously the workspace developer would have to prompt for the log file location twice; one for the log location and once for the info to record to the table. This is because parameters of different types (ie filename and text) could not be shared.

Now, because published parameter sharing is no longer limited to a single type, the parameter can be set up as a filename type and shared with a text attribute.



Above: The published parameter (red) is being shared by two parameters (blue) of different type. Versions of FME prior to FME2008 (build 5098) would not permit this action.



Above: The output in the metadata table.


NB: Example 2 is also a good example of relative dates using the DateFormatter. An attribute is given a value of "today". The DateFormatter interprets "today" relative to the current time and provides the correct date. Notice in the output screenshot how 'today' has been interpreted as a real date. The "format" setting on the DateFormatter determines the structure of that date.


FAQ

Q) Are there any limitations?

A) No - but that itself is a thing to be careful of! Because we no longer force parameter types to match when being shared, the onus is on the user to ensure that (s)he is providing values that are consistent with the parameter type.

For example, an integer or float type of parameter is the obvious source for a Bufferer transformer buffer size, but there's no safety mechanism to stop you providing a Filename or text value! The problem would only surface once you run the translation and it fails.

We're allowing this because we believe the potential benefits of sharing mismatched types outweighs the potential problems that could occur. But as they said in Hill Street Blues, "hey - let's be careful out there".


Q) What Version of FME is this new function in?

A) FME 2008. Builds 5086 or greater have the ability to create standalone parameters. Builds 5098 or greater have unrestricted sharing of parameters (more below).


Q) When I share a custom parameter of type choice with a regular FME parameter of the same type, whose values take precedence?

A) In FME 2008 it would be an intersection, in FME2009 the custom parameter wins.
For example, if you share a custom parameter (with values A,B,C) with the Feature_Types_To_Read parameter (with values C,D,E) then in 2008 the list of values would contain C (the only common value), whereas in FME2009 you would get A,B,C (because the custom parameter wins out).

Attached Files
filesizedate
example1.fmw15.7 kB10/09/07
example1a.jpg32.4 kB10/09/07
example1b.jpg14.4 kB10/09/07
example1c.jpg7.0 kB10/09/07
example1d.jpg5.0 kB10/09/07
example2.fmw31.0 kB10/09/07
example2a.jpg61.9 kB10/09/07
example2b.jpg51.4 kB10/09/07
example2c.jpg17.1 kB10/09/07
User Comments Add a new comment