Whats the best way to deal with unused or not used classes and rules under it?
Hi All .... What's the best way to deal with unused or not used classes and rules under it when code has been moved to higher environment?
Accepted Solution
Pegasystems Inc.
IN
Hi,
well for lower environment you can run it. However for higher environment, the rulesets will be locked, This wizard can't delete a rule that belongs to a locked RuleSet version. Locked rules will be left in place during the deletion. So it might not work !
This article talks exactly what you are looking for . Please take a look : http://pdn.pega.com/node/1269
Pegasystems Inc.
IN
Hi
If the class and all the rules under it is unused and you are sure that it is not going to be used in future as well ,then using the Delete a Class wizard is a good option that you can explore. It delets a class and all of its pattern- inheritance dependent classes and associated objects such as properties, activities, instances (including work items, attachments and assignments).
Please refer the PDN Help here to know more about it : https://community.pega.com/sites/default/files/help_v719/procomhelpmain.htm
JPMC
US
Thank you Santanu Bhattacherjee for your response!! So are you recommending to run this wizard in all the environments?
Accepted Solution
Pegasystems Inc.
IN
Hi,
well for lower environment you can run it. However for higher environment, the rulesets will be locked, This wizard can't delete a rule that belongs to a locked RuleSet version. Locked rules will be left in place during the deletion. So it might not work !
This article talks exactly what you are looking for . Please take a look : http://pdn.pega.com/node/1269
JPMC
US
Thank you Santanu Bhattacherjee for your response! I think it would be a nice to have feature in pega if we could have a utility similar to column population job so that we can run and clean-up all un-necessary classes and rules in any environment.
This issue is very frequent when we have some service consuming xmls and corresponding schema changes after some time.
Pegasystems Inc.
IN
Hello,
Your request describes an enhancement to product functionality and will need to be processed as an Enhancement Request. I have raised an enhancement request on your behalf.It will be reviewed and evaluated by our product management team further .
JPMC
US
Thank you Santanu Bhattacherjee for taking it forward, it will really be a useful feature.
TCS
AU
Hi Santanu,
Sorry for jumping in. What's the best way to delete the rules in higher environments that's not associated with ruleset. We use automated deployment process with application name as the key for exporting rules. When we promoted last time, it picked the branch application as well and deployed in other environments. Though it's not causing any issue, we wish the Branch application to exist only in Development environments.
Manually deleting may be an option. Since we use automated deployment, Devops compliance team not keen on doing manual changes in higher environments. Are there any alternate solution to this? Thanks,
Pegasystems Inc.
US
I immediately thought about the availability options Santanu suggested. If you have locked your rulesets prior to migration this is a natural accounting style change pattern.
Eventually in your application release cycle you may skim your rulesets to higher versions and delete your lower version ruleset with the ruleset delete tool.
Sometimes things are not so well planned or done quickly to deal with issues.
In these cases you can investigate the RuleBase Compare wizard, to find differences between environments you may not be aware of
https://community.pega.com/sites/default/files/help_v719/procomhelpmain.htm
JPMC
US
Thanks Peter Gousios for your response !
As per my experience I feel availability option probably is good when we have very few rules to deals with. It does not look a good option when we have complete set of redundant/unused classes and redundant rules inside it.
Example - when we have services or xml which pega application consumes and if service definition or underlying XSD changes then wizard creates totally new classes and other rules based on how big changes are.
I am not sure how skimming can be helpful to resolve this issue.
Pegasystems
US
Today if I start with rules A,B,C in lower environment let's say I've tested them and migrated them to the higher environment.
Now later in lower environment I delete rule B, and make rule D so I have A,C,D. I test that and move it to higher environment. But now higher environment doesn't look like lower environment since B still exists in higher environment.
Should we consider enhancing the "move it to higher environment" tool so that we move both additions AND deletions ? If we did that, then when we do the second move described above, the system would delete B from the higher environment.
/Eric
Hi Eric,
wouldn't it be the usual approach to lock the RuleSet version when going to a higher environment and set rule B to "Withdrawn" in the new RuleSet version if it is not needed anymore?
I mean, this is the main reason for the "Withdrawn" Rule Availability Status, isn't it? There is no need to consider deletions then in R-A-Ps, though it might be a nice feature on some occasions.
Updated: 15 Oct 2015 11:13 EDT
Seniorlink
US
Withdrawing the rule creates yet another instance. The real question is why you'd be deleting rules that are in a ruleset you've migrated as it makes debugging hard because you have different ruleset contents with the same stacks. If you want to get rid of the rule record you do withdraw it, then you skim to get a clean product ruleset which won't hit the rule at all, then you remove all the rulesets below the skim version from the database if you're not sure you caught every possible reference to the rule with your testing. The last part about removing the rulesets below the skim version is almost certainly unnecessary. If you used blocked instead of withdrawn you'd be much more assured but then you cannot directly revert to something in the basis application for your application and so it's less safe (in my opinion).
Still, why would anyone delete a ruleset from a locked version that's been migrated to a higher environment?
Pegasystems
US
Dhirendra, my idea would require that the zip generation for raps be enhanced to include information both about rule additions and deletions. Today it only includes additions. Then at the other end, the import would need to also be enhanced to do the deletions as well as the additions.
This would address the common situation where as part of development, we not only ADD some rules but DELETE some as well. Today's rap/zip mechanism only handles the ADDs.
/Eric
Pegasystems
US
Using "block" or "withdraw" instead of completely deleting a rule may be appropriate depending on the situation. I'm not sure one way deserves to be labeled the "usual approach". Each approach may have its advantages and disadvantages. For instance, blocking or withdrawing something rather than deleting it provides for some historical footprints which could be valuable, plus may be r-a-p/zippable for migrating to higher environments, but on the flip side having all those unused rules staying around might cause some confusion or take up too much space in certain situations. /Eric