Question
Intact Financial Corporation
CA
Last activity: 24 Oct 2018 10:05 EDT
Step Page not working with circumstance
Hi,
We are upgrading from Pega 6.3 SP1 to 7.3.1, we found an issue when calling a decision rule (Decision Table and When rule), the step page is not considered when using a circumstance.
I.E We are looping in a list of object name "Coverage", we preparing some coverage where we need to apply a decision table. So, we have MyCoverageABC, MyCoverageDEF, (...)
on each of these coverage, we can have a different circDateTime, depending on some condition.
So, when we apply the DecisionTable, we are using the circumstanceDateProp = ".circDateTime".
But, now in Pega 7.3, the step page is no more use and use the primary page, which is not even a coverage, since it is the parent class. So, we have bad result, because .circDateTime exist on the parent, but not the same date than the coverage.
Someone has this problem ?
We have over 16000 circumstance rules, so it will be very long to manage step page issue 1 by 1.
We got this issue with the When Rule in Pega 6.3, we have been forced to use a Java Function "@callwhen(StepPage, "whenRuleName)", I hope it's not the solution to fix the problem for the decisionTable.
Adaps
IN
Below link might help you
Intact Financial Corporation
CA
No, it's not related to this.
Instead of doing "myStepPage.circDateTime", Pega is doing "primary.circDateTime". The stepPage is defined in the Page&Classes with an existing Pega classe. It's not a compilation issue, it is a runtime issue. Pega execute the bad version of my rule because myStepPage.circDateTime != primary.circDateTime
Thank you
Intact Financial Corporation
CA
You can see an activity I have created to test this issue, all screenshot are in the DecisionTable StepPageIssue.docx.
Knowledge Expert
FR
This is known issue for circumstance when step class is different from primary class:
Intact Financial Corporation
CA
It was working for me in Pega 6.3 SP1, so I received a HFix from Pega to solve this issue and this fix has not been applied for all the other clients. I will have to search which one it is : (HFIX-6646, HFIX-6861, HFIX-7038, HFIX-6407, HFIX-6388, HFIX-6300 and HFIX-6399)
When I use a StepPage, I change the context of my execution, it is unacceptable to use the Primary as context for my circumstance... This is a conceptual bug.
We solved a bug with the When Rule by calling the function "@callWhen", but I have realised that is the same conceptual bug. if I used a normal precondition ".variable1 == .variable2", this uses the step page. If I use a When Rule, the variables use in the rule will be on the step page... but if I set a circumstance to the When rule, it's using the Primary... WOW!!!
Pega has to revise that decision, this is not working as expected, it is a conceptual bug.
Am I the only client who finds unacceptable that Pega is pushing the responsability to the client, to fix their bug?
Intact Financial Corporation
CA
For those who have more difficulties to understand the object-oriented world, here is a little analogy that simplifies my problem:
I working with Orange, but sometime I can find red or green apple with the orange. When I get an apple, I must move them in a different place, depending of the color. So, when I get the apple, I ask Pega "What is the color of my apple", Pega answer "Orange", because my primary object is an orange !
Adaps
IN
Please find the below link might help you
Coforge Technologies (Erstwhile Incessant Technologies)
GB
The decision results are not what you expect, since during Rule resolution the system checks for the circumstance template in @baseclass, while the template is present in the PegaSample class. However, the circumstance template is defined on properties present in PegaSample, and not in @baseclass. PRPC is loading all the required rules into pr_sys_cache_entry properly, but while looking for RULE-CIRCUMSTANCE-TEMPLATE in pr_sys_cache_entry, it is looking at @baseclass as pxleafclassname.
Recommended Approach
Decision circumstancing works with the primary page and not with the step page.
The decision results are not what you expect, since during Rule resolution the system checks for the circumstance template in @baseclass, while the template is present in the PegaSample class. However, the circumstance template is defined on properties present in PegaSample, and not in @baseclass. PRPC is loading all the required rules into pr_sys_cache_entry properly, but while looking for RULE-CIRCUMSTANCE-TEMPLATE in pr_sys_cache_entry, it is looking at @baseclass as pxleafclassname.
Recommended Approach
Decision circumstancing works with the primary page and not with the step page.
Change the activity so that it calls the primary page, not the step page.
All circumstancing works with the primary page, not just Decision rules.
Intact Financial Corporation
CA
Like I said, Im working in Pega since 2004, since version 4.2... For us, the StepPage has always been used. Now, we have over 16000 DecisionTable to create an intermediaire activity to have a primary page... It was working in 6.3 SP1 for me, even if this bug has been reported from Pega 6.1, I have probably received a fixed for Pega 6.3 SP1 5 years ago, but no trace of this fix in the Pega system.
We don't use template, we are using circumstance date property. So, the solution of Pega to upgrade from 6.3 SP1 to 7.3.1 is to create 16000 empty activity to have the right primary...
In my example, Orange is not a parent class of apple, the parent class could be "fruit" for both, but I have received the property of a totally different class.
Nobody has been able to convince me that this is not a bug.
Intact Financial Corporation
CA
It would be very interesting to find someone that knows someone that could answer the question about the page that was and and should be used for the rule set resolution when a circumstance Date Property is used on Decision Tables. We have a step defined to use a class for a Decision Table and it is not that class that is used to determine which version should be used for execution of that Decision Table. Isn't it strange ? At the least, surprising to us. Please spread the word, who can answer this ? There must be someone at Pega System that was involved in that desicion.