RAM 7.5.0.2 to RAM 7.5.1.1 upgrade
Hi, We are planning for a upgrade from RAM 7.5.0.2 to 7.5.1.1 We have a lot of live communities that are used by a lot of consumers. Are there any potential risks or issues that we can encounter and for which we need to take some mitigation steps? E.g. One general doubt running through my mind is the most important feature of RAM 7.5.1.1 which RAM 7.5.0.2 does not have is the "Master Lifecycle". When our system is upgraded, all the existing communinties,ill not have a master lifecycle. What effect will this have on our existing community lifecycle and its assets? I understand it is a very generic question. It would be good if you could throw some light and provide your expert advice. Thanks in advance, Regards, Sripriya |
2 answers
Rich Kulp (3.6k●3●8)
| answered Oct 05 '12, 4:02 p.m.
FORUM MODERATOR / JAZZ DEVELOPER edited Oct 05 '12, 4:03 p.m.
It won't let me do a comment on your "a few more questions" question. My reply is too large, so here it as an answer instead:
NOTE: Before hitting the migrating button from 7502 to 7511 make sure that you first install 7511 testfix7d or later on top of the base 7511. There was a migration bug in 7511 base with lifecycles and permissions. The testfix7d makes sure that the migration from 7502 to 7511 is complete and does the correct migration. The migration steps are as follows: 1) Go through each community lifecycle, find the workflow for that lifecycle. If there is no master lifecycle yet for that workflow create an empty default master lifecycle based on that workflow. This master lifecycle has no restrictions, policies, reviewers, etc. 2) After creating the master lifecycle or finding that one is already there then the community lifecycle is migrated. This means if the community lifecycle had any configuration applied, such as policies, reviewers, etc. then the community lifecycle after migration will continue to have these configrations. At the community level these will be maintained. After this then any changes to the master lifecycle will be inherited by the community lifecycle the next time it is accessed. 3) After all community lifecycles in all communities have been migrated a background job will be kicked off to migrate all of the asset lifecycles. Migrating an asset lifecycle is done by merging the existing asset lifecycle (which is a complete snapshot) with the community lifecycle it came from and then saving it. The save will strip out all of the configuration that came from the community lifecycle and save only the additions. Next time an asset lifecycle is retrieved it will merge the current community lifecycle back in so that it would pick up the latest changes to the community lifecycle at that time. ---- Note: The basic concept of inheritance of lifecycles is this. Master Lifecycle: A complete lifecycle fully configured. Community Lifecycle: Just the delta (additional configurations) over and above the master lifecycle. Asset Lifecycle: Just the delta (additional configurations) over and above the community lifecycle. Then whenever a community lifecycle is loaded into memory (accessed) it will at that time merge in the current master lifecycle configuration. This may result in some community configuration being changed because it conflicts with the master configuration. If the community lifecycle is then changed it will save out only the differences from the master lifecycle and not the entire configuration. Saving the master or community lifecycle doesn't propagate changes at the time of save. They are picked up on the time the children lifecycles are accessed for whatever reason. The only immediate propagation is changing reviewers, lifecycle managers, or their permissions. All other changes are not propagated until the next time the lifecycle is accessed. Whenever an asset lifecycle is loaded into memory it will at that time do a merge with the current community lifecycle (after the community lifecycle was merged with the master). And when saved only the differences from the community will be saved. Comments Thanks a lot Richard for the heads up of the test fix and the detailed explanation. :) Hi Richard and team, The above explanation really helped clear quite a lot of my doubts. One another question I have, say I have a community with 20 assets. All the 20 assets are in the "Review" state of the lifecycle. I have a policy called Modify Asset Owner Policy configured in the "Review" state of the lifecycle. Now I realize that I need to add an extra reviewer. To accomplish this, I change the "Modify Asset Owner Policy" in the community lifecycle to add this new reviewer. This policy has been configured to fire only during "Asset Save" and "Entrance to state". Question: Although the community lifecycle has been changed, the asset lifecyle of each of the 20 assets will reflect the change only when the policy runs again correct? So do I have to manually update each individual asset so that the policy runs again during the saving of the asset? Or is there a way changes to the community lifecycle gets migrated to the asset automatically by some mechanism? Hope my question makes sense. Please let me know! Thanks a lot!
|
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.