Product Rule Creation in Pega -Part 1

We all would be aware of developing an application in PEGA and the deployment cycle it undergoes before it goes LIVE where end-users can use our application. Just to summarize, the most typical deployment cycle would be

DEV -> QA -> UAT -> Pre PROD -> PROD

• DEV-> Environment where all development activities take place.
• QA-> Environment where quality assurance team tests the features developed by developers.
• UAT-> Environment where business users test the features that are tested by QA.
• Pre PROD-> Environment which acts as a mirror of the production environment. Usually, load testing [if applicable] will take place in Pre-PROD.
• PROD-> Environment where end-users use the application with actual live data.

What is Deployment?

• Deployment is the process of promoting/migrating our code from one environment to another.

• Deployment in PEGA involves the below steps,
  • Creating and configuring Product rule
  • Extracting product rule [creating ZIP archive]
  • Importing ZIP archive into the target environment.
• Deployment is a crucial task in any project which ensures the application goes LIVE.

What is a Product Rule?

• PEGA supports deployment across environments using the product rule.
• Product rule is an instance of class Rule-Admin-Product.
• Product rule belongs to SysAdmin category. Product rules are also called as RAP rules.

Before getting into a detailed discussion on how to create a product rule, let’s understand the below terminologies,

1) Application

Application is a collection of Rulesets, Version, and Instances. Refer to this article from OSP to understand what is an application in detail.

2) Ruleset

• RuleSet in an application is used to store the related group of rules.
• RuleSet provides security, version control, and the ability to deploy our application to different environments.

Ruleset type can be broadly classified into three categories

Standard Ruleset

• By default, new rulesets created in the application will be of type standard.
• Ruleset of type Standard can have any type of rule without restrictions.

Shared Ruleset

• A RuleSet of type Shared should contain rules which may be shared across multiple applications in the organization. 
• Ruleset of type Shared cannot be referred in application ruleset stack, rather it should be mentioned under the advanced section in the definition tab of the application rule.

• A shared RuleSet cannot contain a class rule.
• Example rules to place in a shared ruleset are corporate logo, organization-wide activities in Work-/Data-.

Component Ruleset

• A RuleSet of type Component should contain functionalities that can be reused across multiple applications in the organization. 
• Ruleset of types Component cannot be referred in the application ruleset stack, rather it should be mentioned under the advanced section in the definition tab of the application rule.
• A Component RuleSet can contain class rules.
• Component ruleset and component are two different concepts. A component ruleset is just a ruleset with reusable functionalities whereas component is a reusable application with more than one ruleset.

3) Ruleset Version

• RuleSet version is used to control the versioning in Ruleset.
• When we create a new RuleSet, the system creates version 01-01-01 and thereby starts incrementing as 01-01-02, 01-01-03 and so on. This can be modified by developers when needed.
• Each RuleSet version has 3 parts separated by a hyphen – Major, Minor & Patch.
• Below are the recommendations from PEGA on controlling versioning,
  • For major releases, the first two digits can be incremented. This is known as a major version increment.
  • For enhancements, the middle two digits can be incremented. This is known as a minor version increment.
  • For bug fixes, the last two digits can be incremented. This is known as a patch version increment.

4) Non-versioned Rules

• These are instances associated with a Ruleset but not RuleSet version.
• Non-Versioned Rules inherit from Rule- classes. Few examples are,
  • RuleSet Name [Rule-RuleSet-Name]
  • RuleSet Version [Rule-RuleSet-Version]
  • Class [Rule-Obj-Class]
  • Application [Rule-Application]
  • ARO [Rule-Access-Role-Obj]
  • Access Deny [Rule-Access-Deny-Obj]

5) Associated Data

• Similar to non-versioned rules, these are instances associated with a Ruleset but not RuleSet version.
• Associated data instances inherit from Data- classes. Few examples are,
  • Operator ID [Data-Admin-Operator-ID]
  • Access Group [Data-Admin-Operator-AccessGroup]
  • Workbaskets [Data-Admin-Workbasket]

How to create a Product Rule?

Product rule in PEGA can be created in two ways,

• Manual product rule creation.
• Product rule creation with the wizard.

Let’s explore the process of creating product rules manually in this post. Wizard usage and other aspects will be covered in the continuation posts.

Manual Product rule creation

We prefer to manually create a product when the details to be filled in the product are known ahead. Let’s now see the different configurations available in a product rule.

Rule Form of product accepts two key parameters,

• Label/Identifier -> Unique identifier of the product rule.
• Product Version -> Provision to control versioning of the product. It can possibly be the current date/ version to be deployed [01.01.02]/ any custom values.

PEGA recommends creating product rule in any one of the ruleset version that is to be deployed. This ensures the product rule is available in all the environments.

Each product rule has 4 tabs namely,

• Contents
• Dependencies
• Deployment/Installation
• History

1) Contents

The content tab covers most aspects of the product rule.

Applications to Include

• If we want to deploy our entire application with all its associations to higher environments, then we can make use of this section.
• We can also add more than one application to deploy.

Name

• This field denotes the name of the application to be deployed.
• Extra caution is required to make sure none of the PEGA provided application is included in the list as it will be existing in the target environment.

Version

• In PEGA, it’s possible to create multiple versions of the same application. This field is used to mention the version of the application to deploy.
• A typical example could be the PegaRules application which has versions namely 06.01.01, 07.01.01, 08.01.01.

Include associated data

• Enabling this option in product rule will select all the associated data instances of all rulesets included in the application.

Custom/Production rulesets

• Production ruleset in PEGA is mainly used to handle delegation requirements.
• Production ruleset will be mentioned under the advanced section in the definition tab of the application instance.
• Enabling this option in product rule will ensure that the production ruleset mentioned in the application rule is included in the ZIP archive.

Shared/Component rulesets

• Ruleset of type Shared/Component will be included in the ZIP archive if this option is enabled in the product rule.

Delta Mode

• Enable this option if we expect the ZIP archive to only contain rules from the patch version of the ruleset mentioned in the application rule.

• Delta mode is applicable only when the patch version is mentioned in the application ruleset stack.

Include rule history

• Every rule will have history maintained which keeps track of the person who made the change, date time of change along with the information on the change made.
• These entries are maintained in the class Rule-History.
• Enabling this option in product rule will include rule history of the rules included in the ZIP archive.
• PEGA recommends not to include the rule history during product creation since it will be used only in the DEV environment.

Include data types

• Enable this option to include the instances of the data types (classes & tables) that are associated with this application.

Rulesets to include

• This section can be used to deploy an entire application by mentioning its ruleset individually or to deploy rulesets for bug fixes/changes requests.
• PEGA recommends using the ruleset option for deployment since this has more control to decide on what should be/shouldn’t be deployed.

Name

• The name of the ruleset to be included.

Minimum Version

• A ruleset can have any number of versions and this field identifies the starting version from which rules should be considered.
• This field can include Major [01] or Minor [01-01] or Patch [01-01-01] version of a ruleset.

Maximum Version

• A ruleset can have any number of versions and this field identifies till what version the rules should be considered.
• This field can include Major [01] or Minor [01-01] or Patch [01-01-01] version of a ruleset.
• The minimum version should always be lesser than the maximum version.

Exclude non-versioned rules

1. Enabling this option will exclude all of the Rule- non-versioned instances of the mentioned ruleset in the archive.
2. In this case, the required instances should be included explicitly using itspzInsKey.

Include associated data

• Enabling this option will include all Data- instances of the mentioned ruleset.
• If this option is not selected, the required data instances should be included explicitly using its pzInsKey.

Application Context

• This field auto-populates the application name which contains the mentioned ruleset name and version.

Global exclusions

• Global exclusions are only applicable when Exclude non-versioned rules option is unchecked.
  
• Let’s consider a scenario where only class, ruleset name, and versions of a particular ruleset should be included in a product rule. This can be achieved using the below configuration,

• With the help of Global Exclusions, we can configure a product rule to include non-versioned rules of a particular type.

Class instances to include

• This section of the product rule is used to include instances of a particular class.

Name

• Class name that contains instances to be included as part of the product. It can be any class that extends from Data-, Rule- or Work-.

ListView filter

• We can apply a custom filter criteria to the identified instances of the class using a list view. For Eg, we can use the below configuration to conditionally include classes created in an implementation ruleset [INSPRT].

When filter

• The custom filter can also be applied using when rule instead of a list view.

Include descendants

• Enable this option to include instances in classes that descend from the class entered in the name field. For example, if the class entered is Data-Address, instances of its descendant classes Data-Address-Phone, Data-Address-Fax are also included in the product.
• ListView filter and When rule filter will be ignored if this option is enabled.

Exclude classes

• By default, all descendent classes are included when Include descendant is checked. We can use this field to enter the names of descendant classes that we do not want to include in the product.
• For Example, enter Data-Address-Email to exclude it as a descendant of Data-Address. We can also enter more than one class using a comma (,) to delimit the names.

Individual instances to include

• This section will be used to include a particular instance in the product rule using the instance’s pzInsKey.

• We can get the instance’s pzInsKey using below possible ways,
  • “Select a class and press Query” option enables us to select a class & query its instances.
  • Open the instance and use keyboard shortcut Shift+F8 to get the InsKey of the instance.
  • Open the View XML page of the instance and select the value of the property pzInsKey.

Jar files to include

• This section will be used to select the custom Jar files that we have imported.
• For Example, If we have imported Jar files to implement Bar Code/ QR code in our application, then those jars can be selected and can be promoted to higher environments using this section.

• In most of the scenarios, Jar files are used to access Java classes and function from PEGA.
• OOTB Jars should never be promoted to higher environments.

File Details

This section enables us to configure archive/file related information namely creation date, short description, etc.

Creation date

• Field to hold the date when the product rule is created.
• Configured value will be displayed in the target system when the ZIP file is imported.

Short description

• Field to hold a short description about the product rule.
• Configured value will be displayed in the target system when the ZIP file is imported.

Exclude schema changes for 5-4 compatibility?

• This option enables us to achieve backward compatibility.

Preview product file

• This shows the summary of the contents to be included as part of the product ZIP archive.
• PEGA recommends reviewing each product file that we create in the system to ensure none of the required rules/instances are missed.

Create product file

• Click to create a ZIP archive in the ServiceExport directory on the current application server node.
• The ZIP archive can also be downloaded to the local machine once the generation is successful.

2) Dependencies

• Our product might have few dependencies on other products/Hot Fixes which should be verified by the system before importing the product rule into the destination system.

Let’s consider a scenario where our product file will work only if the destination system has a 7.3.1 version of the PegaRULES Process Commander application installed and HFix-38813 installed prior to our deployment. This can be achieved using the below configuration in dependencies tab

3) Installation/Deployment

This section covers most of the post-deployment activities.

Post-Installation

• We can mention a HTML rule in Read Me field that provides a detailed description of the Product rule and any other important information that is to be highlighted after deploying the product, for example, configuration instructions.
• With the above configuration, PostImportConfiguration HTML file will be loaded at the end of the import process which instructs users with post-deployment tasks.

Revalidate and Save

• Post-deployment, if we feel some of the rules in an application should be re-compiled, then the application and version can be mentioned in this section.
• Rules in the mentioned application get re-compiled which ensures the deployed code works as expected.

Pointers to Remember

• PEGA provided applications should not be included in the Applications to include section.
• Including Rule history in the Applications to include section is not recommended by PEGA.
• Make sure only the required non-versioned rules and associated data are included in the product when deploying a ruleset. Global exclusion in conjunction with exclude non-versioned rules can be used to achieve this.
• Class Instances to include section can be used effectively in conjunction with ListView/ When filter to have more granular inclusion of class instances.
• Include Descendants should be checked in the class instances to include section only when provided class is abstract.
• It is recommended to use the Query Jars section to include required jar files instead of manually importing it in the destination system.
• Make sure all the rulesets other than Production/ Artifacts rulesets are locked before the deployment.
• Let’s ensure the product rule doesn’t have rules which already exist in the destination system. This will overload the product rule and the ZIP archive that gets created.
• PEGA recommended size of a ZIP archive is 15MB. If it exceeds, let’s make sure our product rule is broken into smaller units.

We are glad to publish the article requested by @Vimal on “Product rule creation in PEGA“. If you want us to publish any articles of your choice, please fill out this form & we will make sure it gets published.

Stay tuned for more posts on Deployment & Dev Ops !!!