Every system/application have settings that user can change or create new ones if needed.
Example : Think of WhatsApp where we have settings related to ringtone, notifications etc., These are used to enhance and customize the application to our needs.
Similarly PEGA by default comes up with some System Settings which are used for the maintenance of the application. There are two types of System Settings provided by PEGA:
- System Settings, associates with a ruleset version and therefore supports version locking.
- Dynamic System Settings, associates with a ruleset but not version and therefore simple data records without support of version locking.
System Settings provide a way to define settings which will be applied in run-time based on the Production Level of the environment.
Point To Note: Each environment can be given a number starting from 1(experimental system, low security) to 5(production). The corresponding Production Level for each value will be as follows:
Production level values typically signify the following:
You can find existing settings by navigating through Records->SysAdmin->System Settings.
Below is a screenshot of some of the OOTB System Settings.
System Settings supports versioning and provides a way to lock and migrate the changes. If any change is required, they can be done in the next version.
As this process involves deployment to reflect the changes we have to decide carefully whether this type of setting is needed or not, as the work involved to maintain the rapid changes in the long run will be hectic.
One can consider this type of setting when:
- The values are specific based on the environment like the Endpoint URL’s. As these must be definitely different when considered in Development, Testing and Production environments.
- The values will not involve rapid changes therefore avoiding frequent deployments.
Creating System Setting
A new System Setting can be created by navigating through Records->SysAdmin->System Settings-> +Create
Provide Setting name, Ruleset name, as part of which the setting can be stored. Here I am creating System Setting for storing the URL which is used while retrieving Customer Details.
Point To Note : Note the URL is different for Level 5(Production) when compared to other levels just like in real-time applications, where the Development and Testing environments will be pointed to dummy URL’s.
Retrieving System Setting value
We can use OOTB functions to retrieve System Setting value. Goto Records-> Technical-> Function
Search for the function with name getRuleSystemSetting. The function accepts two parameters:
- System Setting Name
- Ruleset Name
In the below example I created a sample activity and proceed to run the activity (Actionsà RunàRun) to fetch the System Setting value and set onto TempPage.pyNote property.
Currently the Production Level of my environment (personal edition) is ‘2’ and therefore the URL configured for Level ‘2’ has been returned. You can check the current Production Level of an environment by navigating through Designer Studio->System->General->Systems,Nodes,Requestors
Dynamic System Settings
Dynamic System Settings, provide a way to define settings which are simply data instances and cannot have version control and therefore making it easy to change the settings without any deployment requirement.
You can find these settings by navigating through Records-> SysAdmin-> Dynamic System Settings.
Below is a screenshot of some of the OOTB DSS.
Point to Note : The above shown settings will also be present as part of prconfig.xml file in the server path of the application.
“Wait !!!, If these settings are part of a file, why do we need DSS again ?”
Here comes the advantage of DSS over prconfig.xml.
prconfig.xml file will be present separately for each node(server). And therefore whenever there is a change to any setting, we have to make the same in multiple files based on the number of nodes.
Whereas, DSS is nothing but a record which will be saved as part of database. And all the nodes in an environment have a single database. So whenever a change is made to DSS, the value will be stored as part of a single database and will be in sync across multiple nodes. And therefore avoiding updating in multiple files.
DSS are used whenever you need to configure a value in the application, but changes frequently according to business requirements.
One of the use case is
- SLA times till when the case has to be kept in Workbaskets, initially it may be configured as 7 days. Later the business wants to change it to 3 days for faster processing. By using DSS the operations team can change the value within no time and without requiring any code deployment.
Creating a DSS
A new DSS can be created by navigating through Records-> SysAdmin-> Dynamic System Settings-> +Create
Provide the Description, Ruleset name, Purpose (a meaningful DSS Name will be sufficient). In the below screenshot, I am creating an DSS which stores the Goal time that will be used to hold a case in WorkBasket.
The configuration is so easy, we just need to provide a single value. Here I am giving the value as ‘7’ as this will be used as maximum days to hold a case in the Workbasket using SLA.
Retrieving DSS Value
- We can use OOTB functions to retrieve an DSS value. Go to Records-> Technical-> Function
- Currently, the below are the functions that returns the DSS value by providing the required inputs like DSS name, ruleset name as part of which it is being stored etc., Both the functions have same name but have different number of parameters. This is called method overloading in traditional programming language.
Look below for the description and usage of both these functions.
1) getDataSystemSetting – (String, String, String)
Accepts three parameters -> DSS name, Ruleset name, Default value (will be used when the DSS cannot be found)
Point To Note: Here I don’t have DSS created with the name ComplaintWBSLAGoal in the CS ruleset and therefore whatever the value I am configuring as part of third parameter will be returned by default.
Accepts two parameters -> DSS name, Ruleset name
In the below example I created a sample activity and proceed to run the activity (Actions-> Run-> Run) to fetch the DSS value and set onto TempPage.pyNote property.
1) If the values are specific to each environment and are constant(or will not change frequently), the System Setting is a best option.
2) If the values are same in each environment and can subject to frequent change , the DSS is a best option.
That’s the end of our tutorial. Hope you liked and learned something new. Let me know how you used these settings and what you feel about the topic in the comments.
Happy Learning !!!
Author - Satish Segu
A passionate and self teaching programmer with lots of love for Android programming. Currently being working as PEGA Developer and posses kowledge in a variety of areas starting from Case Management, Agents, Security, BIX etc., Connect with me through below links.
Happy Learning !!!