Dynamic System Setting & (Rule) System Setting in Pega

Before We Begin

We all are aware of Mobile Phone Settings where we can turn on/off notifications based on our preference. We don’t approach the manufacturer of mobile to get the setting updated.

In the same way, when an application is built using PEGA, the system does support few settings updates which doesn’t require developer/product owner support to get things done.

From the OSP dictionary, we would define system setting as a configuration that can be used to change the behavior of the system.

What is System Setting?

As the name suggests, it helps us update the settings of the system anytime. In PEGA terminology, the system is nothing but an environment [DEV, QA, UAT, PROD]. Hence system settings in PEGA can be used to control the settings specific to each environment.

Ways to configure Setting in PEGA

We can configure system-specific settings in 2 ways,

1. Dynamic System Setting
   • Application-specific
   • System/Infrastructure specific
2. System Setting/Rule System Setting

1. Dynamic System Setting

Dynamic System Settings are instances of class Data-Admin-System-Settings.

As the name indicates, It can be updated in the system anytime without undergoing any release management/code deployment process. Hence DSS is provided by PEGA as a data instance that will be associated with a ruleset but not with a version.

Dynamic System Setting configuration can be broadly classified into two types based on its usage,

1. Application-specific DSS.
2. System/Infrastructure specific DSS.

Application-specific DSS

• Application specific DSS comes in handy for supporting frequently changing business need which is always a consideration when we develop any application.

Let us now see how it can be used to support frequently changing business needs in PEGA.

Business Scenario

Let’s consider a leave management application where a Manager should approve the leave request at least 2 days before the leave requested date.

In the above scenario, 2 days time window for leave request approval is a changing factor and hence can be implemented using DSS.

Implementation

• This can be achieved by adding Manager as Work Party to the case and having DSS created for approval time window as 2 days.
  
• DSS can be found under the SysAdmin category in Records explorer.

• Approval window DSS value can be referred using the OOTB function getDataSystemSetting in Utilities library.

Input Parameters,

• owningRuleSet -> The ruleset name in which the DSS instance is created. In our scenario it is OSP.
• setting -> Name of the DSS instances created. In our scenario, it is  LeaveRequest/ApprovalWindow.

Output Parameters,

The value mentioned in the identified DSS [owingRuleSet + setting] will be the output param of this function. In our scenario, it is 2.

• OOTB Flow PartyApproval can be used to implement approval logic. Approval flow refers to the DSS value at run time to decide the approval window.

Let’s say in future if 2 days approval window is to be changed to 3 days,updating the DSS value to 3 would suffice.

System/Infrastructure specific DSS

Before discussing system/infrastructure specific DSS, let’s understand the below terminologies.

• Node -> Each server, hosting the PRPC rules engine software is known as a node.
• Multi-node environment -> An environment can have multiples nodes and each node has its own server-specific configuration files [prconfig.xml etc,]. All the nodes (Server) points to a common database server.

What is a Production Level?

Production level is a custom attribute that PEGA assigns to each system. The production level defines the level of access/security/restriction that a system has.

Each PRPC system has a production level, a value between 1 (lowest) and 5 (highest).

•     5 = production (Production environment)
•     4 = preproduction (Mirror environment of Production)
•     3 = test (Instances used by QA, UAT)
•     2 = development (Instances used by developers)
•     1 = experimental (Instance used for Pre-Sales)

Production level can be updated anytime using the System data instance in PEGA.

Now coming back to our discussion, there are few system variables that have values set from the configuration files placed in the server. Hence these configurations are specific to a node.

Few examples are,

• Performance alert thresholds.
• The maximum number of active connections in the database.
• The maximum active requestors.

When we mention these as system variables, does PEGA provide a mechanism to update these values based on the need 😳?. Yes, PEGA does support updating those variables in two ways,

• Updating prconfig.xml file -> Changes made in prconfig.xml is node-specific. It gets reflected only to the users who are logged in to that specific node.
  
• Creating/Updating DSS for environmental variables -> When the value is set/updated using DSS, changes get saved in the database and all the nodes in the cluster refer to the updated values.

Business Scenario

Ever wondered how PEGA would have restricted the option to trace service rule in the production environment?

Let’s now try to update the setting using DSS so that the system allows us to trace service rule even in production.

Implementation

• Open the below DSS and check the restriction that it has on the production level.

• Update the DSS value to 5 and restart the application server once.
• Try tracing any service in production after the restart and you should be able to trace it as similar to the lower environments.

Tracing service and restarting Production is not recommended. so careful consideration is required when you try to implement this.

Refer to this article from OSP to understand how to deploy DSS instances from one environment to another.

System Setting/Rule System Setting

System Settings are instances of class Rule-Admin-System-Settings.

System setting/Rule System Setting is a rule type in PEGA that can be used to set values to a variable specific to the environment based on the production level. The system setting in PEGA will be associated to a ruleset and version. Hence system setting change goes through release management/code deployment process.

System settings can be used to set the configuration specific to the environment/production level.

Now let’s quickly see how the above-discussed production level is used in conjunction with System setting with a real-time scenario.

Business Scenario

Let’s try to explore how PEGA handles retry in case of lock issues during SLA agent processing.

Implementation

PEGA uses the OOTB system setting SLALockRetryInterval to define the interval after which retry can happen in case of any lock issues.

This configuration is provided as a system setting because the value can differ between environments based on the business need.

Let’s try to have a retry time interval as 5 minutes in DEV so that developers need not wait for a long time for the SLA event to be executed.

How to invoke the System Setting rule?

System Setting can be referred using the OOTB function getRuleSystemSetting in Utilities library.

Input Parameters,

• owningRuleSet -> The ruleset name in which the System Setting instance is created. In our scenario it is OSP.
• setting -> Name of the System Setting instance created. In our scenario, it is SLALockRetryInterval.

Output Parameters,

The value mentioned in the identified System Setting [owingRuleSet + setting + Production Level] will be the output param of this function. In our scenario, it is 300000.

Coming back to our implementation,

OOTB SLA Agen activity EstablishContext refers to the System setting rule specialized in the application ruleset and sets the retry value as 5mins in the development environment.

Pointers To Remember

Both Dynamic system Setting & system Setting can be used to set a value to a variable. But there are a few considerations which insist us when to use Dynamic System Setting & System Setting.

• If the value changes frequently and we wish to avoid deployment & have the support team change the value in production, we can use a dynamic system setting.
  • Few Examples are,
    • flag for turning on off a feature depending upon the business flexibility.
    • flag to control the number of items to be picked up in a particular batch job.
    • many typical prconfig.xml settings used by PEGA.

• If the value is not expected to change over a period of time and we expect to have a code change to promote the changes, we can use System Settings.
  • Few Examples are,
    • Endpoint URLs (We know the value is different in every environment and would not change very often).

This concludes our discussion on Dynamic System Setting and System Setting 😊

We are glad to publish the article requested by @ Shashankey pinnireddy on “Dynamic System Setting & System Setting”. If you want us to publish any articles of your choice, please fill out this form & we will make sure it gets published.