Question
Credit Suisse Group AG
CH
Last activity: 28 Jan 2020 5:43 EST
Merging rules to release version from branch changed the pzInsKey 7.1.9
Hi All,
In Pega version 7.1.9 we see a strange behavior related to Branch and Merge concept where the original pzInsKey of a rules changes if there is merge of new changes done from a branch ruleset.
1. Rule A exists in the release version 1
2. Save as the rule to a branch.
3. Modify rule(optional)
4. Merge the rule back to the release version 1
5. The original pzInskey of the rule is modified to a new one!!
This is definitely not the behavior in the newer version of Pega. (We tested in 7.2.2 and in this version the original pzInsKey is preserved in the release version even after multiple merges)
This definitely seems to be a bug and not a "feature" as multiple deployment to Test environments will always run in to Duplicate Instance Check while deployment.
Does someone know if this was a bug in 7.1.9 and is fixed through a hotfix?
***Moderator Edit-Vidyaranjan: Updated SR details***
BPM Company
NL
huh?
I reckon that's an expected behaviour, since you're changing a rule, and pzInsKey must be updated as a result.
At least it contains a timestamp of the last check in.
When you tested it on v7.2.2, are you sure that you merged it to the same RS version? maybe it was new one, and the original rule's pzInsKey didn't change, because the rule itself didn't change
Credit Suisse Group AG
CH
It was the same ruleset and same version.
If this is expected then it is weird because deploying the same version in a higher environment will always result in duplicate check.
I think it is fundamental that original pzInsKey should not change and this works as expected in higher versions of Pega.
BPM Company
NL
Sorry, I was wrong.
Just double checked it: after merging, the original pzInsKey stays the same (Pega v7.3.1).
So please trace it as it was suggested below
Pegasystems Inc.
FR
Hello,
I might be wrong but I don't think we have an existing hotfix for such issue on Pega 7.1.9. Have you tried to trace and check which activity exactly is changing the pzinskey? Can you share it here?
Credit Suisse Group AG
CH
Hi Marc,
Please see the difference in attached image between 719 and 722.
It seems that the fault is in Data Transform - pyMergeDefaults
BPM Company
NL
I see that this data transform is in Available state. Could you Save it As into one of your rulesets and add missed lines? and check after that if it will work
Credit Suisse Group AG
CH
We tried it already. But it does not work.
The DT seems to expect parameters which are not there in 719. It is not this single rule which is the culprit here.
BPM Company
NL
There is one clue you could try to use: in the 7.2.2's pyMergeDefaults a comment has been provided: "BUG-238945 : Set the original inskey and create properties for the rule to be saved".
If you search for the "BUG-238945", you'd see that there is only one more rule involved - an activity pyMergeInstance. It's also Available, so you could try to align changes in that rule with your pega version.
Credit Suisse Group AG
CH
Really appreciate the help and the time!
But we also tried that :(
It turns out that fixes for BUG-238945 is distributed in many other rules too which is not easily detectable even using the Rule Content search. e.g. pzDeleteRuleInDestination where there is a fix in the JAVA step of the 3rd line.
There is no way to confidently say what the total set of rules which actually resolves this issue, since even content search is not working.
In 7.2.2 for the ruleset Pega-RuleRefactoring there are version 07-10-21 to 07-10-28 which is extra on top of 7.1.9 containing 122 rules. Comments with same BUG Id were found in 07-10-25 and 07-10-27 (could be others, hard to detect).
I have raise an SR now. There is no confident way of knowing how many rules and code pieces we need to customize to fix this defect in 7.1.9
Pegasystems Inc.
US
Hi @KumarS7883,
Please share your SR ID so that we may track the progress from you and attach this conversation to it.
Thanks!