Discussion
CVS
US
Last activity: 4 Nov 2016 22:24 EDT
Rule Resolution Process
Hi,
In the lesson Rule Resolution Process it says
1.Check the rule cache. If the rule is present in the cache, go to Step 8.
and the steps 8 and 9 are
8.Find the best instance (and check to make sure there is not a duplicate rule).
9.Check that the Availability is not set to BLOCKED.
Why do we have to check for the Blocked if the rule is already present in the Cache. Can a rule be changed from Available to Blocked by someone else while it was sitting in the cache.It would not even be picked up if its BLOCKED in the first place. even if the availability changes, does not the system pulse invalidate that entry from the cache.
Thnaks,
Pradeep
Pegasystems Inc.
US
With Blocked, the system wants to know that you're trying to access the rule, so that it can put up an error message telling you that the rule can't be run.
It helps to compare Blocked and Withdrawn, which perform similar functions, but result in different effects.
- Withdrawn is used before setting the cache, to determine which rules should be ignored, because they've been superseded. So a rule that's set to withdrawn just never goes into the cache, because the system should never attempt to run it.
- Blocked is used after the cache is set, because the system wants to attempt to run the rule, and know that it's not supposed to do so.
Let's say you have three rules of the same type, distributed as follows:
ABC-Work: ruleset 01-01-01
ABC-Work-Case: rulesets 01-01-15, 01-01-20
With Blocked, the system wants to know that you're trying to access the rule, so that it can put up an error message telling you that the rule can't be run.
It helps to compare Blocked and Withdrawn, which perform similar functions, but result in different effects.
- Withdrawn is used before setting the cache, to determine which rules should be ignored, because they've been superseded. So a rule that's set to withdrawn just never goes into the cache, because the system should never attempt to run it.
- Blocked is used after the cache is set, because the system wants to attempt to run the rule, and know that it's not supposed to do so.
Let's say you have three rules of the same type, distributed as follows:
ABC-Work: ruleset 01-01-01
ABC-Work-Case: rulesets 01-01-15, 01-01-20
- If the rule is Blocked in the 01-01-15 ruleset and the version in 01-01-20 is set to yes: the 01-01-20 version supersedes the blocked version, so the 01-01-20 version is added to the cache and the rule runs.
- If the rule is Blocked in the 01-01-15 ruleset and Withdrawn in the 01-01-20 ruleset: then the blocked version would be excluded from the cache, because the version in 01-01-20 supersedes it. And since that version (in 01-01-20) is Withdrawn, the system falls back to running the one in the higher class, in the 01-01-01 ruleset.
- If the rule is Blocked in the 01-01-20 ruleset: the system shouldn't fall back to the higher class. Rather, it shouldn't execute the rule at all, and instead should return an error. So it's important to know that the blocked rule is in the cache, so the system can say "I was supposed to run this rule, but instead I'm going to give you an error message saying I'm not allowed to run it."
Using scenario #3, if the blocked rule was excluded from the cache, then the system would have no rule to run. As a general rule, you want to know that there was no rule of that name in the cache, because that would normally indicate that the rule is in a class or a ruleset that isn't part of the application so the user can't access it.
I hope that cleared up the issue for you. Rule resolution is a tricky subject, one that can be difficult to describe, let alone understand. If you have any additional questions, please respond with them and we'll do our best to answer them.