What is the best practice to compare “configuration” between different versions of Agile PLM ?
How would you confirm – without doing time intensive manual verification – that Oracle provided upgrade tools did in fact correctly upgrade Agile 9.x.x to the latest 9.3.6 version ?
I want to verify that the upgraded configuration matches with the “source” legacy version’s configuration… It would be nice if ACP like tool is available to compare the legacy vs the latest. However, ACP will not work between different versions.
My current thinking is to compare the generated admin reports from two different instances (legacy and the latest) via some custom code and display differences.
Does anyone have suggestions on how to compare configuration between different versions of Agile PLM ?
Thanks
Get a full Agile Classes Report for each environment, and then build a program to compare those files. This will only compare the class/subclass/attribute configurations (and workflows/lifecycles, if you so desire), but everything else is fairly simple compared to them. If you import those reports into Access (for example), it is fairly easy to look at everything and note missing and new stuff. Since the Agile Classes Report is fairly agnostic so far as versions of Agile are compared, it shouldn’t be much of an issue (if at all).
Note I am talking about comparing 92xx or 93xx to 93xx, and not Agile85 to 9350 (although I do think that it could be done, it would be just a bit harder).
You can do the same comparisons with various other reports, in addition to the Agile Classes Report (Events Configuration, Roles and Privilege, Users Configuration, Workflow Configuration, etc.). Note that ACP has always had the capability of comparing configurations, just by name (does this subclass have these attributes in both configurations) and a Deep Compare (that looks at all properties for objects in the configuration). This compare functionality can only compare what was exported from the source environment to what is in the target environment (and may be imported at some point in time).
You are FAR better off not using ACP to migrate configuration, unless you can test it thoroughly and understand what works and what doesn’t. It is also easier to do it in small chunks (lists/workflows/lifecycles, classes/subclasses/attributes, users/user groups, etc.) instead just importing it all together. ACP has gotten better, but it can never just merge 2 configurations without any issues. Even worse is if the 2 configuration do NOT have a common point in history (really, Really, REALLY hard to make that work), or that common point is a large number of changes ago. Plan on doing a LOT of testing when using ACP.
Also, you can upgrade a database very easily using AUT and not have to worry about using ACP at all (AUT is nearly bullet-proof, if you get all the Averify errors cleaned up).
Paritosh Deshmukh
Please refer to Doc ID 2159773.1 in support site.