Automatic Schema Handling

Let's look at how we can handle the schema problems that might arise if a custom transformer is reused.

Automatic Handling of User Parameters

To take the handling of user parameters first, when a transformer with a published parameter is incorporated into a custom transformer, the published parameter is automatically moved from the main workspace to the custom transformer.

This means that the user is no longer prompted for these when the workspace is run! But... those parameters instead become available on the Custom Transformer itself:

That way the parameters can be set differently for each instance of the custom transformer. If user input is required then these new parameters can be published themselves - and shared if you want them all to have the same value.

Automatic Handling of User Attributes

Now let's look at how attributes are handled. When a custom transformer is created, one of the parameters in the Create Custom Transformer dialog is labelled Attribute References:

"Handle with Published Parameters" is the automatic way of handling attribute references in the custom transformer. It makes sure that every attribute referenced within the custom transformer is supported outside of the transformer definition.

It does that by creating a published parameter for each attribute:

...and then using that instead of the attribute reference:

Now, when this transformer is used in a place where the schema doesn't match, the transformer will still be flagged red as "incomplete". However... the user is able to use that published parameter to select an attribute that is available.

So (in the above) if AddressID is not available, the user can select ADDRESSID or AddressUUID instead.

This illustrates how FME has automatically solved the attribute reference problem using published parameters. To make the custom transformer more generic, the workspace author can change the prompts on these parameters; for example change the prompt from "AddressID" to "Select an ID Attribute to Process".