Question
J P Morgan Chase
IN
Last activity: 28 Oct 2016 9:01 EDT
Class Structure design considerations
We are in the design phase of a new application and are working on class structure design.
When we created a New Application using Pega wizard, the resultant ruleset stack in operator profile looked like this. (From top to bottom)
" IMPLEMENTATION level rulesets, DIVISION level rulesets, UNIT level rulesets, ORG level rulesets, FRAMEWORK level rulesets, PEGA rulesets "
There are two things that needed clarification here.
1) Why are FRAMEWORK rulesets at the bottom of the stack just above PEGA rulesets. Instead, shouldn' they be just a level below IMPLEMENTATION rulesets ?
2) Shouldn't UNIT and DIVISION level rulesets swap their positions so that the usual sequence of UNIT - DIVISION - ORG is held ?
We expected the ruleset stack would be like this.
" IMPLEMENTATION levle rulesets, FRAMEWORK level rulesets, UNIT level rulesets, DIVISION level rulesets, ORG level rulesets, PEGA rulesets "
We are in the design phase of a new application and are working on class structure design.
When we created a New Application using Pega wizard, the resultant ruleset stack in operator profile looked like this. (From top to bottom)
" IMPLEMENTATION level rulesets, DIVISION level rulesets, UNIT level rulesets, ORG level rulesets, FRAMEWORK level rulesets, PEGA rulesets "
There are two things that needed clarification here.
1) Why are FRAMEWORK rulesets at the bottom of the stack just above PEGA rulesets. Instead, shouldn' they be just a level below IMPLEMENTATION rulesets ?
2) Shouldn't UNIT and DIVISION level rulesets swap their positions so that the usual sequence of UNIT - DIVISION - ORG is held ?
We expected the ruleset stack would be like this.
" IMPLEMENTATION levle rulesets, FRAMEWORK level rulesets, UNIT level rulesets, DIVISION level rulesets, ORG level rulesets, PEGA rulesets "
Please help us understand the rationale behind the above two points as to why PEGA designed it that way so that we could have a better class structure designed.
***Message was updated by Moderator: Marissa Rogers - added category; added SR to post***
Accepted Solution
J P Morgan Chase
IN
Hi
We have got a response from Pega GCS where they mentioned the stack generated by App Wizard is to be fixed in the next release and it would look this.(from top to bottom)
" IMPLEMENTATION level rulesets, FRAMEWORK level rulesets, UNIT level rulesets, DIVISION level rulesets, ORG level rulesets, PEGA rulesets "
Thanks
Harsha
Pegasystems Inc.
AU
Hi Harsha.
We generally refer to the rulesets with higher precedence as being “on top” of those with lower precedence. The list is assembled during login. The process starts by finding the versioned application rule referenced on the access group of the operator. Note that in rare configurations the access group can actually come from the requestor definition, organization or division record. For most applications, the ruleset list is primarily comprised of rulesets referenced on the application form. The “built-on” applications are recursively processed until the PegaRULES application is found. The applications are then processed bottom up adding each application’s ruleset list on top of the previously added rulesets. As an example, if application A has two rulesets and is built on top of application B which has two rulesets and which is built on top of PegaRULES ruleset. We will end up with a ruleset stack with the rulesets of application A on top of those of application B on top of the Pega rulesets. Finally, if the operator is allowed to check-out rules a personal ruleset is added at the very top of the list. The personal ruleset has the name of the operator ID.
J P Morgan Chase
IN
Hi Basavaraj
Thanks for the reply. I am in sync with everything u say. But, I m looking for specifics on why the Application wizard in Pega (which automatically creates an App and builds the stack for us) has put the stack in the way I mentioned in the question. If you could speak on the specific questions I posted above, that would be great.
Updated: 1 Jun 2016 6:21 EDT
J P Morgan Chase
IN
Hello
I am still looking for some assistance on the questions posted. Hope someone could help.
Thanks
Harsha
Pega Systems
IN
I assume you are having Pega 7 instance.
When we create a New Application using Pega wizard, Application stack will have four main rulesets.
AppRS, AppInt, OrgRS, OrgInt
Two are related to current Application and other two have Orgnization specific things.
1) Why are FRAMEWORK rulesets at the bottom of the stack just above PEGA rulesets. Instead, shouldn' they be just a level below IMPLEMENTATION rulesets ?
>> Any Application has its own RuleSet stack (which can be modified as needed).
>> An Application (Implementation Layer) is built on top of some other application (Framework Layer).
>> At base, there will always be PegaRULES application
>> It is always like Implementation application built on top of Framework application ... on top of PegaRULES Application.
>> So, hierarchy will be like implementation rulesets, framework rulesets and pega OOTB rulesets.
2) Shouldn't UNIT and DIVISION level rulesets swap their positions so that the usual sequence of UNIT - DIVISION - ORG is held ?
>> An Application stack can be made the way you suggested (or based on how you want to design)
i.e. "IMPLEMENTATION levle rulesets, FRAMEWORK level rulesets, UNIT level rulesets, DIVISION level rulesets, ORG level rulesets, PEGA rulesets"
>> To achieve this, the better option (considering reusability) would be build individual application (at different levels) having specific rulesets
I assume you are having Pega 7 instance.
When we create a New Application using Pega wizard, Application stack will have four main rulesets.
AppRS, AppInt, OrgRS, OrgInt
Two are related to current Application and other two have Orgnization specific things.
1) Why are FRAMEWORK rulesets at the bottom of the stack just above PEGA rulesets. Instead, shouldn' they be just a level below IMPLEMENTATION rulesets ?
>> Any Application has its own RuleSet stack (which can be modified as needed).
>> An Application (Implementation Layer) is built on top of some other application (Framework Layer).
>> At base, there will always be PegaRULES application
>> It is always like Implementation application built on top of Framework application ... on top of PegaRULES Application.
>> So, hierarchy will be like implementation rulesets, framework rulesets and pega OOTB rulesets.
2) Shouldn't UNIT and DIVISION level rulesets swap their positions so that the usual sequence of UNIT - DIVISION - ORG is held ?
>> An Application stack can be made the way you suggested (or based on how you want to design)
i.e. "IMPLEMENTATION levle rulesets, FRAMEWORK level rulesets, UNIT level rulesets, DIVISION level rulesets, ORG level rulesets, PEGA rulesets"
>> To achieve this, the better option (considering reusability) would be build individual application (at different levels) having specific rulesets
e.g. Implementation Application < Framework Application < Unit Level Application < Division level Applicaion < Org Level Application < PegaRULES Application
>> "Org Level Application" might not be needed
J P Morgan Chase
IN
Hi Sarang
Thank you for the response and I do have Pega 7.2 instance.
Your response points that, considering reusability, the better option would be
"Implementation Application < Framework Application < Unit Level Application < Division level Applicaion < Org Level Application < PegaRULES Application"
which is exactly what we thought is the best way too.
If we concur on above, the question would be on Why Pega wizard didn't generate the stack like above. Instead, it generated
" IMPLEMENTATION level rulesets, DIVISION level rulesets, UNIT level rulesets, ORG level rulesets, FRAMEWORK level rulesets, PEGA rulesets "
Thanks
Harsha
Updated: 7 Jun 2016 4:57 EDT
Pega Systems
IN
I don't think the staement about Pega wizard generated stack is right.
Can you please share any reference/document/screenshot supporting that statement about Pega wizard generated stack?
NB: Application RuleSet stack can be built in such a way that Rules in particular RuleSet should take precedence.
J P Morgan Chase
IN
Hi Sarang
Thanks for the patience. Below are the screen prints. I have selected JPMorgan > CCB > CTO as Org > Div > Unit in the respective manner. As the profile shows, the way it generated was (from the top)
" IMPLEMENTATION level rulesets, DIVISION level rulesets, UNIT level rulesets, ORG level rulesets, FRAMEWORK level rulesets, PEGA rulesets"
Regards
Harsha
Pega Systems
IN
With the help of given screenshots, I could replicate the scenario.
This seems to be a bug while creating a new Application for which SR can be raised.
For the time being, you can manually alter the Application RuleSet stack to give precedence to Unit Level RuleSets over Division Level RuleSets.
Hi Harsha,
Please go ahead and Reopen the SR. Also, mention that it was identified as a product bug through this post.
Regards,
Lochan | Online Community Moderator | Pegasystems Inc.
Accepted Solution
J P Morgan Chase
IN
Hi
We have got a response from Pega GCS where they mentioned the stack generated by App Wizard is to be fixed in the next release and it would look this.(from top to bottom)
" IMPLEMENTATION level rulesets, FRAMEWORK level rulesets, UNIT level rulesets, DIVISION level rulesets, ORG level rulesets, PEGA rulesets "
Thanks
Harsha
Pegasystems Inc.
IN
Hi Harsha,
Thank you for the update! I will marked this thread as Answered.
Regards,
Lochan | Community Moderator | Pegasystems Inc.
Pegasystems Inc.
JP
Why do you need a Unit level or Division level layer and/or rule sets at all? What kind of business logic are you going to put in those rule sets?
A layer or a rule set must be there for a reason. In many cases you don't even need a framework layer, implementation layer alone is enough.
Don't over engineering with rule sets and layer cakes, unless there is a real need. Layer cakes and rule sets are powful features yet difficult to master, so don't expect a wizard can generate ideal class structures / rule set stack which fits your need. The wizard never knows what is the problem you need to solve.
J P Morgan Chase
IN
Hi Chunzhi
Thanks for the response. We never had a unit level/division level in our application. It is clear that the stack would be specific to the kind of application we are trying to build or the problem we are trying to solve.
The only point we wanted to know was (as mentioned in the question) the rationale on why Pega built the stack in that way. As the wizard is built by Pega, we expect the stack built by the wizard to be an example which we can follow in normal scenarios.
Thanks
Harsha