Easiest way to fix duplicate rule instance issue in same ruleset version
Hi All - Can you guys please share your experience or way to resolve this issue.
Actually after importing multiple times same package in higher environment we are seeing duplicate instances of same rule in same ruleset version. For example we have a Rule R1 in Ruleset RS1 in version 01-01-01 then after importing the zip 3 times in higher environment I can see 2 instances of same rule R1 in RS1:01-01-01.
Earlier when I faced this issue in 6.x and lower I used to do Revalidate and Save or some time unlock the ruleset version and delete the rule from that version in higher environment and then reimport the package and it used to work. but this time I see more than 4 rules have this issue so wanted to check with experts here in the forum that what's the best way to deal with this situation? Currently I am using 7.1.5.
Pegasystems Inc.
US
Hi Dhirendra,
If you are importing the same package multiple times, I would expect the rules to be skipped if they imported successfully the first time. I am very surprised that the same rule imported multiple times. What do the pzInsKey values show for the duplicate rules? Are they different? What do the timestamps match up with? If the pzInsKey values are the same, check the database table to see if pzInsKey has been specified as the primary key.
Carissa
Pegasystems Inc.
US
I want to second what Carissa said. If you are importing the exact same RAP over and over again, the pzInsKeys of all the rules should be the same (and skipped on subsequent imports). If the pzInsKeys are the same in the database, you want to make sure you have key constraints on your rules table. If the pzInsKeys are different, that tells us you've done something like develop rule A1 in dev, move it to QA, delete it in dev, create a brand new rule named A1 in dev (which will produce a new pzInsKey) and import that second rule to QA. (alternately, if you have multiple dev type sandboxes and you create a rule A1 in each of them and then migrate those rules all into a single QA box, you'll experience the same problem). That would require importing different RAPs. If you have two or more A1 rules with separate pzInsKeys, you need to decide which one you really want and delete the others. You'll probably have to go directly to the database to do this since the system is just not built to support this.
JPMC
US
Thank you Carissa Wenhardt and Mike Townsend for your response!
I am amazed to see that there is no one here encountered this issue before, while I have faced this issue multiple time in 5.x, 6.x and now in 7.1. This is an issue where DB shows only one row with one pzinskey in pr4_rule table in target environment after repeated imports. Even when we search it from developer portal and click on triangle shape at the beginning of rule on search result to see all the version of that rule - it shows only one rule instance in that version. but when you go to revalidate and save to list the affected rule then it list multiple instance of same rule in same ruleset version. When such rules are referred at run time then we can see a Log entry which says something like '...system is unable to open the instance using given key...'.
sometime this issue is resolved when we do revalidate and save for such rules, but sometime it doesn't work so I usually delete such instances and reimport package which imports only deleted rules.
Pegasystems Inc.
US
Dhirendra,
Have you been doing in place upgrades? You might want to confirm that you have the constraints on the table(s) where you store your rules. You really shouldn't be seeing this ever.
Thanks,
Mike
JPMC
US
Thank you Mike Townsend for your response and suggestion. I did verify from DB side everything looks fine from index and key perspective and pr4_rule table contains only one row for affected rule. Today I noticed that even when we save as such rules it creates multiple instances in same ruleset version which I never faced before, so I open a SR-A16055 which screenshots and log details.
JPMC
US
The only unusual thing in my case is that my team does development in a environment which has split schema setup and we are facing this issue in a environment which is single schema setup and code is dumped from 'development system with split schema'.
Accepted Solution
Pegasystems Inc.
US
Upon reviewing the corresponding SR, we see that it has been resolved. SA-18714 was created as a result of the investigation. Please reference that if you have the same question.