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.
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.
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.
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.