Discussion
Infosys
Infosys
US
Infosys
Posted: Dec 18, 2015
Last activity: Apr 6, 2018
Last activity: 6 Apr 2018 19:26 EDT
Closed
post upgrade ruleset versions should be created as next Major or next Minor
Hi,
We are upgrading 10 applications from 6.2 to 7.1.8. Post upgrade how ruleset versions should be created for each application? is it next Major+minor+patch or next Minor+patch? some of the applications are really big and complex for which changes have been made frequently in ruleset versions. These applications are not skimmed.
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Posted: 9 years ago
Pegasystems Inc.
Pegasystems Inc.
IN
- Skimming could improve the performance. Nevertheless, even if it is negligible relatively when cross verified with pre-skim performance readings.
- The advantage of major skim in PRPC v6.3 SP1 is, it filters the Withdrawn, No & Blocked rules in the final skimmed rule set version maintaining the rule set clean.
- Definitely, the rule maintenance would be easy esp. from not running into pre-requisite errors.
- After skimming, it is not a mandatory to delete the old rule set versions.
- Rather, we could point the application to skimmed versions.
- Again, having both skimmed & non-skimmed versions might take longer time during the packaging or deployment activities. (if we include)
- Instead, we could take a backup and have it running on a reference instance.
Please note -
Show More
- Skimming could improve the performance. Nevertheless, even if it is negligible relatively when cross verified with pre-skim performance readings.
- The advantage of major skim in PRPC v6.3 SP1 is, it filters the Withdrawn, No & Blocked rules in the final skimmed rule set version maintaining the rule set clean.
- Definitely, the rule maintenance would be easy esp. from not running into pre-requisite errors.
- After skimming, it is not a mandatory to delete the old rule set versions.
- Rather, we could point the application to skimmed versions.
- Again, having both skimmed & non-skimmed versions might take longer time during the packaging or deployment activities. (if we include)
- Instead, we could take a backup and have it running on a reference instance.
Please note -
- Post skimming it is advised to run Re-validate & Save wizard or Validation wizard.
- It is best to skim all the dependent/pre-requisite rule sets to refrain from unknown errors that may cause because of the blocked rules.
- We should be watchful with the distributed rule set versions so as to accommodate the HFix/Patch versions in continuation with current development. (since, its a major skim - we may need not to worry to an extent of taking a step back)
- Only, that the feature "As Of Date/Effective Date" would be lost which can be managed individually on each ruleset version.
- HFix/Patch versions delivered per customer need to be managed carefully. Fairly a typical example:
- Customer A - requested for a Hfix and was done in 01-01-05
- Customer B - requested for a Hfix and was done in 01-01-08
- With either of the skims, major/minor - we would end up both the rule updates into a single version
- In the latest release - we deliver the final rulesets to 'Customer A', who will have 'Customer B' Hfix updates causing business rule violation errors.
Thank you!
Major skim would be helpful ... (its not mandate to skim as well)
Show Less