When upgrading to v7 frm v6.0.6 do my existing AM and CCM areas merge into a single area
I've been reading the Upgrade Notes for moving from v6.0.6 to v7 and I'm slightly confused.
The notes seem to suggest that if you have an existing AM and CCM areas then when you upgrade the AM area is merged into a new CCM area with the Model Manager extension not into what was your previous CCM area.
Which seems to suggest I'd end up with two Workflow Management (AM) project areas?
this doesn't seem to make sense.
For clarity my intent is to upgrade all my Jazz applications that are currently all at v6.0.6 iFix011 and I have them in a distributed topology whcih I intend to keep and upgrade all the applications to v7.
|
4 answers
My knowledge is:
After upgrade to 7.0 of a CCM instance and separate AM Instance, you will have still two instances. A CCM and an AM.
In CCM you can then enable the model manager and if you like, you can load the AM models into Rhapsody and store them into a CCM Project Area. , You may remove, after moving all content to the CCM, the AM instance. But links will not be migrated with this process.
I'm currently not aware of a Project Area move of the AM PA's into the CCM PA's.
I read there is a SCM Component Move available between two CCM instances since 6061. Maybe this could help to merge AM and CCM after update.
regards
Guido
|
More clarifications:
In 7.0, Rhapsody Model Manager is provided as an extension for an Engineering Workflow Management (EWM) server, rather than as a separate AM application as it in 6.0.6. See more details in https://jazz.net/pub/new-noteworthy/rmm/7.0/7.0/index.html#0.
The upgrade to 7.0 is straightforward. All information is preserved.
1) CCM 6.0.6 application => CCM 7.0 application
2) AM 6.0.6 application => CCM + RMM ext 7.0 application
There is no complete procedure to merge these two CCM nodes into a single node. But you can contact RMM Offering Manager Graham Bleakley (graham.bleakley@uk.ibm.com) to consider possible options.
Thanks.
Sasha.
Comments
Ben Sharples
commented May 18 '20, 4:24 a.m.
this is the whole problem it's not straightforward from reading the upgrade notes have to do a at least one server rename of either existing CCM or AM area. Whenever I've talked to IBM the one thing they always talk about avoiding is server renames as they are fraught with danger.
And from a user interface perspective having two applications that look essentially identical and are named the same is a recipe for confusion.
Geoffrey Clemm
commented May 18 '20, 9:06 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
You do not need to rename any servers. Where in the documentation were you given the impression that you needed to? There is one part of the upgrade process where you have to make sure that you are using the same name in V7 as you used in V6 (and not just select the "use default name" box). This is to make sure that you are not renaming any servers. As to having two applications that look identical and are named the same ... the point is that in 7.0, there is one application (CCM) that provides the functionality that used to require two applications (CCM and AM). The AM functionality is now just a project area option. Because the CCM and AM functionality have a large number of integration points that are simplified if all the project areas are in the same application, this can greatly simplify your end user experience.
Ben Sharples
commented May 28 '20, 4:39 a.m.
It is not the case that I will by default end up with only one application as currently I have been told (and the documentation on Knowledge centre also says it) that there is no capability to merge the existing CCM and AM databases so I end up with 2 CCM applications with one of them enabled for Architecture Management.
The first being the upgraded version of my existing CCM and the second being an upgraded version of my existing AM, which means I have two applications that for a gernal user to all intents and purpose look identical and the workitems and Models previously are still on separate applications.
The only options so far from IBM Support are:
1. Don't upgrade my AM server and then post upgrade import my previous models and rebuild any linking to other applications as if it were a fresh model. (LOSING ALL THE HISTORY)
2. Investigate using DSCM to try and clone the model components across but this was for Source Code and not be tried on Models before. (Retains history but loses any snapshots)
Neither option is particularly optimal.
Benjamin Röhl
commented May 28 '20, 9:38 a.m.
Will there be a migration path to combine both CCM and CCM+AM applications in the future?
Otherwise it seems to fail the whole purpose of having AM as an extension, as lot of people will migrate instead of having a fresh install.
Geoffrey Clemm
commented May 28 '20, 9:34 p.m.
| edited May 28 '20, 9:35 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
It is important not to confuse an "application type" with an "application instance". The application types are "CCM", "QM", "RM", etc. The "application instances" can be identified by their server URL, e.g. "https://myhost1:9443/ccm", "https://myhost2:9443/ccm"
By default, the first segment after the host is the application type, but that is not required.
So in 7.0, there is one fewer application type ... in particular the "AM" application type no longer exists. When you upgrade a 6.x AM application instance, it is automatically converted from an AM application type to a CCM application type. But the number of application instances do not change when you upgrade from 6.x to 7.x.
Benjamin Röhl
commented Jun 02 '20, 3:50 a.m.
Thanks Geoffrey, I appreciate your answer.
But from a administrative point of view, the deployment on a single server machine results into introducing another port, e.g. "https://myhost1:9443/ccm", "https://myhost1:10443/ccm". Introducing another application instance, means another port and JVM parameters to take care of (in regards of firewall and other security related stuff).
Geoffrey Clemm
commented Jun 02 '20, 7:36 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Benjamin,
I wasn't sure how this last comment related to this thread. You are not introducing another application instance ... you are just upgrading existing application instances (and whatever URLs you were using before the upgrade are the same after the upgrade). The only thing that happens in 7.0 is that your instances that were RMM instances before the upgrade become EWM instances after the upgrade.
Note that the context root of the RMM instance (including the port) stays the same after the upgrade (right?).
Geoffrey Clemm
commented Jun 04 '20, 9:18 p.m.
| edited Jun 04 '20, 9:44 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Yes, except for an anomaly that I was not aware of, until I researched this question. In particular, that anomaly is that if you had installed RTC 6.x and RMM 6.x in the same package group, then because of limitations in the Install Manager, you unfortunately have to create a new package group that has just RMM 6.x, and then have to "server rename" your RMM 6.x instance into a new server instance that is associated with the new package group. The server renamed instance will now have a new URL (if it is on the same server as the original RMM 6.x instance, the server renamed RMM 6.x instance will just have a different port number). Only then can you perform the upgrade to 7.x.
showing 5 of 9
show 4 more comments
|
Hi,
let me try to make my recent answer more clear.
the upgrade process from Jazz 6.0.6.1 to 7.0, requires you to split your deployment in regards to migrate the AM application.
Let me quote IBM's Interactive Upgrade Guide here:
In order to perform the migration, a new instance (or an additional one if the current topology includes both CCM and RMM applications) of Change and Configuration Management application with Architecture Management Extension for CCM must be installed. The merge of IBM Engineering Systems Design Rhapsody - Model Manager with another existing instance of Change and Configuration Management in the current deployment topology is not supported.
So, if everything was installed into one server instance (resp. one web application server, like WebSphere) you have to move out the AM application first, to do finally the upgrade for AM.
From there on, the AM application resides in a separate server instance.
Comments 1
Geoffrey Clemm
commented Jun 04 '20, 9:57 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Thanks for providing the quote from the Upgrade Guide, since this let me track down the source of the confusion. In particular, what this is saying is that when you performing the upgrade, when you are done, you will have a "new instance" of EWM, and no longer have an instance of RMM ... namely ... your 6.x RMM instance now "becomes" an EWM instance. So where does this "move" issue come from? As I was researching your question, and clicking through the Interactive Upgrade Guide, I discovered the anomaly described in my comment in the other thread. But note that even if you had your 6.x RMM and 6.x RTC installed in the same package group, which means you need to move one of them into a new package group before you can upgrade (meaning you have to server rename one of those servers), you don't have to move it into a different server instance ... you can server rename the 6.x RMM to the new package on the same server instance ... but you will have to give it a new port number. |
For new customers starting with v7+ it is great that they have capabilities of 2 applications now in 1 CCM application.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.