What are some best practices for naming and organizing published workspaces, automations, server apps, and schedules?

Question

Relatively recently we've acquired FME Server and are in the process of converting workbenches we had run previously via task scheduler. We have quite a few already and I am interested in suggestions (or articles) that anyone has on how to best document or organize the workspaces. There might need to end up being some trial and error regardless, but I would like to avoid some pitfalls on the front-end if possible.

The most relevant search result I found was this, but doesn't seem to apply directly to what I'm looking for: https://community.safe.com/s/bridea/a0r4Q00000HbsC7QAJ/best-practices-document-for-fme-server

Thank you!

icon

Best answer by redgeographics 9 February 2023, 09:27

View original

redgeographics · Accepted Answer

One thing to keep in mind is repositories: once created you can't rename them and once a workspace is published in a repository you can't move it to another one. So it is best to think about that part of the FME Server organisation before you actually start publishing workspaces.

We generally recommend setting up your repositories either by department or by project, but really it's up to you. Whatever works best for your organisation. Whatever you do, consistency is key.

Workspace documentation is another big topic of course. You can opt to do that inside the workspace itself, using annotations and bookmarks. Another option is to create external documentation. Most important here is not to document WHAT you do, but WHY.

Using simple codes at the start of your workspace and automation names is an easy way to keep track of things. So is the option to add tags to your automations to facilitate quick filtering.

Hope this gets you underway a bit, but feel free to ask more.

atyra · Answer

One thing to keep in mind is repositories: once created you can't rename them and once a workspace is published in a repository you can't move it to another one. So it is best to think about that part of the FME Server organisation before you actually start publishing workspaces.

We generally recommend setting up your repositories either by department or by project, but really it's up to you. Whatever works best for your organisation. Whatever you do, consistency is key.

Workspace documentation is another big topic of course. You can opt to do that inside the workspace itself, using annotations and bookmarks. Another option is to create external documentation. Most important here is not to document WHAT you do, but WHY.

Using simple codes at the start of your workspace and automation names is an easy way to keep track of things. So is the option to add tags to your automations to facilitate quick filtering.

Hope this gets you underway a bit, but feel free to ask more.

@Hans van der Maarel Thank you for the response. We have experimented a bit with repository names and noticed that you can't move workspaces between them without republishing. So being intentional on how we set it up does appear critical like you say.

Regarding documentation, I had been wondering if an external document to track description/purpose/frequency might be helpful for us to track what we have published and why it is there would be necessary. So I appreciate that recommendation as well.

One outstanding question I have: If I have schedules for workspaces (e.g. nightly), is it better generally to use automations with a scheduled trigger or to use schedule manager? I realize there might be pros and cons to each, but is there one approach that is generally superior in most scenarios?

Thank you again for your help!

What are some best practices for naming and organizing published workspaces, automations, server apps, and schedules?

3 replies

Reply

Community Stats

Reply

Community Stats

Sign up

An FME Account is required to contribute

Login to the community

An FME Account is required to contribute

Scanning file for viruses.

This file cannot be downloaded