Published Parameter Examples

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.

Sharing 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.

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