Core Concepts – Rule Availability in Pega
In this blog article, we will understand about the rule availability concept.
Update: The concept of Rule availability remains the same across different Pega versions. The screenshots in this blog article were reused from Pega 7 version. Use this blog article to learn the concepts and you can try it out in the latest versions as well.
Let me start this post with a story. I invited my close friends for a party in a WhatsApp group. I asked them to send a confirmation reply.
Friend 1: I am always ready to attend the party (Bestie 🙂)
Friend 2: I am not available for the party.
Friend 3: I won’t come to the party. I will not allow my friends too!!
Friend 4: I am ready to come for the party, but I have a family function blocking that day
Friend 5: I am coming. This is my decision and no one can change it.
So sad. I got a positive response from only two people. I cancelled the party and started writing a new article for you guys. ‘Rule availability’
I find there are many similarities between my friend’s availability and rule availability.
I asked 5 rules to run 🙂
Rule 1: I will run for you (Available)
Rule 2: I will not run for you. (Not available)
Rule 3: I will not run for you, I will not allow rules in my lower version to run. (Withdrawn)
Rule 4: I can run for you, but I am blocked (Blocked)
Rule 5: I will run for you. You cannot update me (can be updated in the same open version)
What is rule availability?
– Rule availability helps in managing rules. They can determine if the rule is eligible to run or not. They can also determine the availability of rules in lower versions.
– In the rule form, you can configure the rule availability.
Why do you use rule availability?
Scenario: there may be some scenario, where don’t want a particular rule to run in the application. You can use the availability feature in the rule form to make the rule not available for rule resolution.
We know, Pega use different rules to support a business process.
For example – when you create a new work item, there are many rules involved to complete the task like flows, activities, when etc. Some rules in the framework can be overridden in the Implementation layer.
Rule resolution helps in picking the right rule.
What are the types of rule availability in Pega?
- Available
- Not Available
- Withdrawn
- Blocked
- Final
We will explore all the possible by rule availability scenarios with examples.
What are the pre-requisites to test rule availability?
You can test using any rule. In this tutorial, I am going to guide you through activity rules.
Create 2 new activities.
- ParentAvailable
- ChildAvailable
Parent activity – Use ‘Call’ keyword and call child activity from parent activity.
Child activity – For testing purpose, use a property-set to set pyLabel – “Child rule is available”
Create a new section, and include some fields. Have a button control. In the button, On click event add an action set to call the parent activity.
How do you configure rule availability?
You can use Live UI and check the property involved in holding the availability value in rule form. – ‘pyRuleAvailable’.
You can see the property ‘pyRuleAvailable’ in the rule class contains the availability value.
How do you use different availability options?
a) Available
As the name suggests, the rule is always available to run.
Here I have configured both the activities, parent & child activities ‘Available’.
This is very simple to test. The rule will run anyways 😀
Step 1: Open the section in the user portal.
Step 2: Start the tracer & click on the check availability button.
you can see the child activity ran. It is available.
I think it’s enough for the rule available
b) Not Available
Using this option, you can make a rule not available in a particular version.
For example – Say you have a rule in 2 versions: 01-01-01 & 01-01-02. Default rule resolution always picks the highest version. In our case 01-01-02.
Now, here if you want your rule in 01-01-01 to run, then you can make the rule availability in 01-01-02 ‘No’
Note: You always use this in development environment. There is no use in moving a rule to higher environment with rule availablity set to ‘No’. You can just delete it right 😀
So when do you actually use it?
– In the development environment, say you have a rule in 01-01-01.
– You saved the rule in higher version 01-01-02 and made some drastic changes. When you test the rule, it throws an error.
– You need to check, how it worked previously.
So instead of deleting the rule in 01-01-02, you can make the rule availability to ‘No’.
The rule resolution invalidates the rule with availability set to ‘Not Available’, so it runs the rule in 01-01-01.
We will test and check how Rule availability ‘No’ works.
Step 1: Save As the child activity in 01-01-02 and set pyLabel to ‘Availability No checking’.
Step 2: Click on the button. As of now keep it available and use the tracer to check the value.
You can see ChildAvailable in MyKnowPega 01-01-02 gets picked and pyLabel is ‘Availability No checking’
Step 3: Now update the availability in 01-01-02 to ‘Not Available’.
Step 4: let’s check the same in the user portal again. trace it.
See, now you can see the rule in 01-01-01 is picked.
You can use this for testing in a development environment.
c) Withdrawn
Selection of this option makes the rule in the current version and previous versions in the same ruleset, withdrawn from the rule resolution. It means rule resolution, invalidates the withdrawn rule and its other lower versions in the same ruleset.
For example – You have your rule in MyKnowPega 01-01-01 version and updated the rule in MyKnowPega 01-01-02 version. When you withdraw the rule in 01-01-02 version, then the rule resolution never pick the rule in both 01-01-02 & underlying versions – 01-01-01.
What are the other scenarios, you withdraw a rule?
You override a pega OOTB rule in your application ruleset. You started implementing your own requirement. In a later release, Pega provided the same feature in their OOTB activity, So you no longer required the overridden activity in your application ruleset.
What will you do here?
You cannot delete the rule, since the rule is packed and moved to a higher environment.
All you can do is save as the rule in the higher application ruleset and withdraw the rule. You can move the withdrawn rule to a higher environment. So it invalidates the rule in lower versions too.
– You have a rule say – ‘discount flow’ in ‘OIKGGB-MyKnowPega-Work’ .
– You Overridden the flow in ‘OIKGGB-MyKnowPega-Work-AmazonSales’ class for Amazon sales case.
– After some particular release, You included all the Amazon sales discount process in the ‘OIKGGB-MyKnowPega-Work’ class generic flow. So now, no use in having a specialized version in Amazon sales class.
What will you do here?
You can withdraw the rule you specified in the ‘OIKGGB-MyKnowPega-Work-AmazonSales’ class. So rule resolution picks the rule from ‘OIKGGB-MyKnowPega-Work’ class.
We will test and check how Rule availability ‘Withdrawn’ works.
Step 1: Create a new copy of the ChildAvailable rule in Application Integration ruleset.
Note: But this MyKnowPegaInt ruleset always comes under MyKnowPega (Implementation ruleset) in ruleset hierarchy. Rule resolution always picks the rule in higher ruleset in the hierarchy. In our case – MyKnowPega
Step 2: let’s test using the tracer.
You can see the rule in MyKnowPega 01-01-02 is picked.
Step 3: Now let’s withdraw the rule from MyKnowPega 01-01-02 version.
Step 4: Let’ check in the user portal using tracer.
You can see the rule is picked from MyKnowPegaInt ruleset.
What are the differences between ‘Not Available’ and ‘Withdrawn’ rule?
– ‘Not Available’ invalidates the rule only in the current version, where as the ‘Withdrawn’ invalidates the rule in the current version and lower versions in the same ruleset.
– Mostly we use ‘Not Available’ only in development environment and don’t promote those to higher environments, where as the ‘Withdrawn’ rules can be moved to higher environment.
d) Blocked
Selecting this option will not invalidate the blocked rule for rule resolution. Still, the blocked rule is the right candidate and if the rule gets picked by rule resolution, then the process returns not found.
When do you block a rule?
– Say for example, Amazon needs to stop their online electronics sales for a particular country. It can be resumed in a later point in time. In this case, you can block the respective rules. The rules just throw the error to the end user.
– In the development environment, If you didn’t complete the entire development, you can block the corresponding rule till then.
We will test and check how Rule availability ‘Blocked’ works.
Step 1: Save As the child activity and make the availability ‘Blocked’.
Step 2: Check in the user portal. Trace it.
You can see the exception thrown. Since we are testing it using a button call, it never stops flow processing(a kind of local action). So let’s test by using the activity in flow action post-processing activity.
Step 3: Open the flowaction – add the ‘ParentAvailable’ activity in Post-processing activity.
step 4: Now submit the flowaction in the user portal.
You can see the error thrown. the process is blocked.
e) Final
– On Selecting this option, you are making a rule as a final rule. You cannot override a final rule in another ruleset.
– When you try save as the rule, you will get an error.
Note: You can save as the Final rule in the same ruleset in higher versions.
When do you make a rule final?
– In my point of view, Pega introduced the ‘Final’ availability to restrict developers from updating the core designer studio engine rules.
– If you are sure that the rule cannot be reused in any other rulesets. It means you will never Save As the same rule to use in other rulesets ( We use it rarely 🙂 )
For example: You can check underlying sections in any rule form header. Pega makes the sections, and rules final, because they don’t want us to update those in rules in our application rulesets.
We will test and check how Rule availability ‘Final’ works.
Step 1: Open any final rule OOTB rule.
Section – RuleFormHeader
Step 2: Try Save As the rule in your application ruleset.
It means you cannot copy a Final rule in different rulesets.
We can try copying a final rule in the same ruleset higher version
Step 1: Open the child activity and set the availability to ‘Final’.
Step 2: Now try Save As in the next ruleset version 01-01-02.
You are able to make a copy only in the same ruleset higher versions 😊
What are the things to remember?
– Rule availability: Available – Rule is always ready to run
– Rule availability: Not available – Rule is not available to run. Rule resolution invalidates the rule.
– Rule availability: Withdrawn – The withdrawn rule as well as the lower versions in the same ruleset are not available to run
– Rule availability: Blocked – the blocked rule throws an exception when it runs. Rule resolution doesn’t invalidate the rule
– Rule availability: Final – You cannot specialize the Final rule in other rulesets. You can Save As only in higher versions in the same ruleset.
