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?
+34- 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
+10- 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
+34- 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.
1 person upvoted this
Reply
Rich Text Editor, editor1
Editor toolbars
Press ALT 0 for help
Helpful Members This Week
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.