Copying RAM Communities between Server
I understand how to export and import meta model data and migrated assets
between RAM servers using libraries and the eclipse batch asset utility
but do not have a handle on how to migrate communities and their associated asset scoping, users, roles and constraints from one server to another (short of redefining them from scratch). Could someone provide some insight (no Rational pun intended) on the best practices for migrating community definitions from one server to another? Currently running on RAM 7.5.0.2 and looking to move up to 7.5.1.
Thanks
Dana
between RAM servers using libraries and the eclipse batch asset utility
but do not have a handle on how to migrate communities and their associated asset scoping, users, roles and constraints from one server to another (short of redefining them from scratch). Could someone provide some insight (no Rational pun intended) on the best practices for migrating community definitions from one server to another? Currently running on RAM 7.5.0.2 and looking to move up to 7.5.1.
Thanks
Dana
2 answers
Dana,
When I'd to do this kind of migration, the only way was copying the database from one to another server. This is far far away of being a good practice, but for me it's the only way to get a mirror of my current server.
My hardest configuration on repository is lifecycles, I'd two of them for each department. It's really hard to maintain it.
Maybe this ugly-and-dirty way can works for you.
When I'd to do this kind of migration, the only way was copying the database from one to another server. This is far far away of being a good practice, but for me it's the only way to get a mirror of my current server.
My hardest configuration on repository is lifecycles, I'd two of them for each department. It's really hard to maintain it.
Maybe this ugly-and-dirty way can works for you.
The original intent of RAM libraries was to provide the ability to export general, reusable configurations to be uses across any server instance.
Users are not exported, since a RAM user is a profile for a user that is managed in some registry. Users and their specific roles are usually specific to a RAM instance and hence were not exported.
As libraries are being use more of a "transferal" medium between various RAM instances in the same organizations (say preProd, and Prod), the need to move community configuration becomes more critical.
Communities and their (scoped) types are exported today, but Roles Configurations and lifecycles ( https://jazz.net/jazz02/web/projects/Rational%20Asset%20Manager#action=com.ibm.team.workitem.viewWorkItem&id=34506) are not ... 34506 is first on the todo list in this area.
Users are not exported, since a RAM user is a profile for a user that is managed in some registry. Users and their specific roles are usually specific to a RAM instance and hence were not exported.
As libraries are being use more of a "transferal" medium between various RAM instances in the same organizations (say preProd, and Prod), the need to move community configuration becomes more critical.
Communities and their (scoped) types are exported today, but Roles Configurations and lifecycles ( https://jazz.net/jazz02/web/projects/Rational%20Asset%20Manager#action=com.ibm.team.workitem.viewWorkItem&id=34506) are not ... 34506 is first on the todo list in this area.