Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Specializing Rules for Multiple Properties

Updated on September 10, 2021

 This presentation is part of the Reusability and Specialization e-Learning Course.

Transcript

Requirement

This scenario looks at a situation where a customer is using PRPC as an insurance risk rating engine, a pure BRE system.  The customer wants to specialize rules by many different properties such as:

  • Locale, perhaps state or region
  • Insurance product, which is looked up in an external database based on a customer’s profile
  • Associated risk, which is calculated at run time
  • Age
  • Sex

Approach

In this scenario, the challenge is that there are many specialization characteristics and some rules are specialized by more than one feature.  Given the nature of the characteristics, the use of RuleSets or classes to represent the specialization alone would be challenging due to the dynamic nature of the values.  Properties such as age are likely to have an age range, which make it difficult for us to use classes or RuleSets.

Insurance may be a good candidate for classes; however, since it is determined dynamically, we would need to use a page change class method to dynamically change the class of the work object.

Circumstancing gives us more flexibility; however, only one property can be circumstanced per named rule.  This leads us to a design decision:  Do you circumstance all rules on the same property or choose a different property for each rule throughout your application?

There is no one answer to the question.  The answer depends greatly on the nature of your application and the nature of who will be maintaining the rules.  Using a single property (e.g. Locale) as your circumstancing property throughout the application provides a more consistent and well-defined rule management process.  On the other hand, using different properties on different rules may allow you to use circumstancing in more places throughout your application.  I recommend discussing the pros and cons of these two approaches with your business and development teams to see which one works best for them.

In our solution, we have decided to treat locale as a property to be circumstanced throughout the application.  This means that wherever we need to conditionalize a rule based on locale we will use circumstancing.  We should not see “If State = MA”, for example, in our rules themselves.  For all other specializations (e.g. Age or Risk Grade), the rules themselves will need to be conditionalized with the specialization logic. 

One common way to do this is by using a decision tree that then calls another decision rule.  For example, you could have a decision table that has the logic “If Risk Grade = A1, call Decision Table A1FicoAdjustment.”  product

Remember, function aliases can be used in decision tree’s to make the creation and management of such rules simpler.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us