We have several FME based solutions - At the moment they are mixture of workspaces, CustomTransformers and formats.
I guess my question is are people thinking about a package as a single tool (like a API connector) or can it also makes sense to include a number of transformers and formats in a similar way to an FME Server Project?
Solved
FME Packages: best practive?
+47- Celebrity
Best answer by andreaatsafe
Hi
FME Packages are intended to include components of related functionality—whether it’s transformers, formats, or web services —making it easier to distribute shared content.
Some of the best practices we consider when creating packages are:
- Flexibility in Contents: Packages can contain one or more transformers, formats, or web services.
- Related Functionality: Packages typically group components that share a common purpose. For example, our rule of thumb is to ask whether they share a common library/API or possibly use a common web connection (e.g., Azure Storage package). Including unrelated transformers in the same Package is not recommended because changes to a transformer may impose Package restrictions that would unnecessarily apply to all transformers within that Package
- Dependencies and Trade-offs: While grouping related transformers/formats/web services together is great for sharing code, it means you’ll need to upgrade all components in the package if one needs an update. However, this approach ensures logical and maintainable grouping.
Hope this helps provide a bit more guidance for using Packages,
Andrea
This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
+15- Safer
- Best Answer
Hi
FME Packages are intended to include components of related functionality—whether it’s transformers, formats, or web services —making it easier to distribute shared content.
Some of the best practices we consider when creating packages are:
- Flexibility in Contents: Packages can contain one or more transformers, formats, or web services.
- Related Functionality: Packages typically group components that share a common purpose. For example, our rule of thumb is to ask whether they share a common library/API or possibly use a common web connection (e.g., Azure Storage package). Including unrelated transformers in the same Package is not recommended because changes to a transformer may impose Package restrictions that would unnecessarily apply to all transformers within that Package
- Dependencies and Trade-offs: While grouping related transformers/formats/web services together is great for sharing code, it means you’ll need to upgrade all components in the package if one needs an update. However, this approach ensures logical and maintainable grouping.
Hope this helps provide a bit more guidance for using Packages,
Andrea
+47- Celebrity
Perfect, thanks
Good to know it can have multiple transformers etc inside. I’m working on a new FME based product and trying to think about the best method for distribution to customers. I’m torn between just a group of workspaces with embedded code or workspaces plus package with linked transformers.
I’m thinking about how the package is just a simple way to install all related components. In addition when publishing to FME Flow the package seems to also get published which is an added benefit compared to just CustomTransformers/Formats which require an additional step.