Is there a way to move workspaces from one repository to the other, other than re-publishing them through FME Workbench? I have a customer who has uploaded all workspaces to a single repository and is now looking to set that up in a better way (FME Server 2019)
Solved
Moving workspace from one repository to another
+63This 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.
+73- Celebrity
I reckon you could build something to automate it with the Repositories REST API....
OR (use this at your own risk - unsure of any flow on effects)
Access the underlying FME database and change the 'repositoryinfo_id' field in the 'fme_item' table for the required workbench to the matching ID of the repository (found in 'fme_repositoryinfo')
JobHistoryStatisticsGathering usually is under 'Dashboards' repository, by changing the ID to '1' it moves to the sample repository.
You'll then need to movethe workbench folder from the old repository folder to the new one. In this example on my local machine:
move this folder - D:\\ProgramData\\Safe Software\\FME Server\\repositories\\Dashboards\\JobHistoryStatisticsGathering
to here - D:\\ProgramData\\Safe Software\\FME Server\\repositories\\Samples\\JobHistoryStatisticsGathering
+63I fear not. How many workspaces are we talking about here?
I don't know the exact number, but it's only a handful. Probably best to tackle this when they want to move to FME Server 2020 and do a fresh start. There's some other stuff they've done that I'd like them to change.
+63I reckon you could build something to automate it with the Repositories REST API....
OR (use this at your own risk - unsure of any flow on effects)
Access the underlying FME database and change the 'repositoryinfo_id' field in the 'fme_item' table for the required workbench to the matching ID of the repository (found in 'fme_repositoryinfo')
JobHistoryStatisticsGathering usually is under 'Dashboards' repository, by changing the ID to '1' it moves to the sample repository.
You'll then need to movethe workbench folder from the old repository folder to the new one. In this example on my local machine:
move this folder - D:\\ProgramData\\Safe Software\\FME Server\\repositories\\Dashboards\\JobHistoryStatisticsGathering
to here - D:\\ProgramData\\Safe Software\\FME Server\\repositories\\Samples\\JobHistoryStatisticsGathering
I looked at the REST API and came to the conclusion it can't be used to upload workspaces 😕
And in this case I'd be very weary to edit the database directly. Given that this is for a relatively small number of workspaces I think the risk of something unforseen going wrong is too high and the potential time savings don't warrant it. As I mentioned in my reply to @virtualcitymatt above it looks like a fresh start when they do an upgrade is the best way to go.
It's good to know the option of editing the database exists, but I'd only use it as a last resort.
+48- Celebrity
I don't know the exact number, but it's only a handful. Probably best to tackle this when they want to move to FME Server 2020 and do a fresh start. There's some other stuff they've done that I'd like them to change.
Yeah nice - if its only handful then it will be a good opportunity to test everything and check that all is in order, republishing will be minor compared to testing.
+19- Supporter
I looked at the REST API and came to the conclusion it can't be used to upload workspaces 😕
And in this case I'd be very weary to edit the database directly. Given that this is for a relatively small number of workspaces I think the risk of something unforseen going wrong is too high and the potential time savings don't warrant it. As I mentioned in my reply to @virtualcitymatt above it looks like a fresh start when they do an upgrade is the best way to go.
It's good to know the option of editing the database exists, but I'd only use it as a last resort.
Hi Hans,
I actually did something like this in the past with the REST API, I am quite sure this can be done with the API.