What is rule availability in Pega?

What is rule availability in Pega?

Create Time: 2017/06/26
Type: Application Structure

Introduction

In this post we will see more in details about the rule availability.

• 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 for the party. I will not allow my friends too !!

Friend 4: I am ready to come for the party, but I got 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 positive response from only two people. I cancelled the party and started writing a new post for you guys. ‘Rule availability’

• I find there are many similarities between my friends 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 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 rule 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?

1. Available
2. Not Available
3. Withdrawn
4. Blocked
5. 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.

1. ParentAvailable
2. 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 availablity 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 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 its enough for rule available

b) Not Available

• Using this option, you can make a rule not available in 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 to ‘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 you actually use?

• In development environment, say you have a rule in 01-01-01.
• You saved the rule in higher version 01-01-02 and did some drastic changes. When you test the rule, it throws 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 this 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 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: Lets check the same in 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 development environment

c) Withdrawn

• Selection 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 an pega OOTB rule in your application ruleset. You started implementing your own requirement. In later release, Pega provides 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 higher environment.

All you can do is save as the rule in higher application ruleset and withdraw the rule. You can move the withdrawn rule to higher environment. So it invalidates 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.

Let’s test the withdrawn rules

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 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 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 later point of time. In this case you can block the respective rules. The rules just throw the error to end user.
• In development environment, If you didn’t complete the entire development, you can block the corresponding rule till then.

Let’ test a blocked rule.

Step 1: Save As the child activity and make the availability to ‘Blocked’.

Step 2: Check in the user portal. Trace it.

You can see the exception thrown. Since we are testing it using button call, it never stops flow processing(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 user portal.

You can see the error thrown. the process is blocked

e) Final

• On Selecting this option, you are making a rule as 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 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, rules final, because they don’t want us to update those in rules in our application rulesets.

Let’ test the final rule availability

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 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 exception when it runs. Rule resolution don’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 same ruleset.