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.
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!
@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!
I personally only use Automations, I don't think there's any big advantage to either option, I just prefer to have it all in one place. I do tag all of my automations if they start on a schedule, and also tag them with the schedule frequency (daily, weekly, monthly)
