Application Design
- RulesetA:01-05
- RulesetB:02-03
- RulesetC:01-17-50
There are five instances of a section rule named EnterClaimDetails in the rules cache as shown below:
| Applies to class | Ruleset & version | Availability |
|---|---|---|
| Org-Div-Work | RulesetA : 01-04-02 | Available |
| Org-Div-Work-FraudClaim | RulesetB : 01-02-01 | Blocked |
| Org-Div-Work-FraudClaim | RulesetC : 01-17-99 | Withdrawn |
| Org-Div-Work | RulesetB : 02-02-01 | Available |
| Org-Div-Work-FraudClaim | RulesetC : 01-09-12 | Available |
When a user runs the application, which version of EnterClaimDetails is selected during rule resolution, when processing a fraud claim?
Pegasystems Inc.
US
The application stack for Ruleset B specifies major version 02- which excludes visibility of the 01- Blocked rule.
Note that RulesetC within the application stack specifies a patch-level version, 01-17-50.
The 01-17-99 rule in RulesetC that Withdraws the Org-Div-Work-FraudClaim EnterClaimDetails rule within RulesetC would not be visible.
The 01-19-12 version of Org-Div-Work-FraudClaim EnterClaimDetails would be visible.
Since that rule is Available, and its applies-to class is more specific than Org-Div-Work, it becomes the selected rule.
Siemens
PT
The application stack for Ruleset B specifies major version 02- which excludes visibility of the 01- Blocked rule.:-
By this do you mean Ruleset B was skimmed because that is not mentioned in the question. Otherwise why visibility of 01- will be excluded?
Pegasystems Inc.
US
Yes, Ruleset B was skimmed to 02- which then excludes 01-.
This is how Pega works. Suppose in the same database you had both Pega 7 and PRPC 6.2.
You would not want the PRPC 6.2 rulebase to be visible if you were running a Pega 7 application.
Yes, Ruleset B was skimmed to 02- which then excludes 01-.
This is how Pega works. Suppose in the same database you had both Pega 7 and PRPC 6.2.
You would not want the PRPC 6.2 rulebase to be visible if you were running a Pega 7 application.
You would also not want the Pega 7 rulebase to be visible if you were running a PRPC 6.2 application.
TalkTalk
GB
has the cache algorithm been applied in the question or is this prior to that and this is every instance of the rule at the beginning when simply all rules are picked with the correct purpose (the purpose being the name of the rule and it's type of record)
Pegasystems Inc.
US
The correct rule is always selected based on the rule resolution algorithm. Caching comes later. If the selected rule is not in the cache Pega will consider whether it should be added.
TalkTalk
GB
yes, that is fine, although in the 7.2 material, it shows a decision is made to check the rule cache, if it exists then to carry on, otherwise to populate the cache indicating it's not optional (i've read somewhere that the rule needs to be referenced 3/multiple times for it to enter the cache).
what I was specifically asking in the context of this question - it presents a "rule cache" showing five instances of a rule.
has the caching algorithm (which is a sub-process of the main rule resolution algorithm) been run yet? the answer to this is no it hasn't been run.
the question starts from the first step in the caching algorithm "choose rules with the correct purpose" - if you carry on from here, you arrive at the answer easily
the question leaves a lot to be assumed which makes it not a good question when people are being critical of the words and context it is presented in
Pegasystems Inc.
US
I should have said "caching is secondary" as opposed to saying "caching comes later". The existing rule being referenced has a key which can be quickly checked against the cache to see if the rule is still valid.
This raises the question "how can the rule key become invalid"?
This is no longer being taught in your SSA course, or even the LSA course, partly due to changes Pega has made since PRPC 6.2 with regard to what is called "System Pulse". Help simply says there is a database pulse and cluster-based pulse -- the latter the currently used approach. If interested you can research cluster technologies such as Apache Ignite and Hazelcast.
I should have said "caching is secondary" as opposed to saying "caching comes later". The existing rule being referenced has a key which can be quickly checked against the cache to see if the rule is still valid.
This raises the question "how can the rule key become invalid"?
This is no longer being taught in your SSA course, or even the LSA course, partly due to changes Pega has made since PRPC 6.2 with regard to what is called "System Pulse". Help simply says there is a database pulse and cluster-based pulse -- the latter the currently used approach. If interested you can research cluster technologies such as Apache Ignite and Hazelcast.
Suppose the older database system pulse. When you have multiple nodes and within one node someone checks in a new version of a rule, something needs to "tell" the other nodes in the cluster that the rule they are using may no longer be valid (is untrustworthy). This can be accomplished by a cache-related table in the database being updated at the same time the new version of a rule was checked in. A System Pulse agent that runs on each node periodically compares what exists within in its in-memory cache to the cache-related database table. If the table indicates a change has occurred, the in-memory cache needs to react.
When the application is forced to react it needs to re-run the rule resolution algorithm. An application's ruleset stack may be limited to specific patch level versions. If a rule has been checked into the database at newer version than what the application allows, that newer version will be excluded as part of the rule resolution process.
Hoping that answers your question.
TalkTalk
GB
thanks for the reply, I was looking for information regarding the behaviour of the cache just to get a better understanding. from the current 7.2 material, it doesn't talk about scenarios that can invalidate a cache, at what point things are refreshed or what can cause a reset.
I was curious to know what happens if you restart a pega server in regards to the cache or if there are other exception scenarios.
from my understanding, if you update a rule, that would cause that rule to be invalidated in the cache and the rule resolution algorithm occurs again?