In this article, we will see more in detail about configuring the system settings.
Important note: Pega deprecated the System settings rule from Pega 8.3 version and introduced a new rule called Application Settings that replaces System settings. It is recommended to visit Application settings blog article
Let’s talk about some basics of system settings.
Think about any software you install, You have the option to customize a few settings.
For example: If you are installing software in either Mac OS or Windows platform, then you may have to customize the default software settings. Most of the settings are in file system and the softwares provide administration console / simple UI feature to update the file systems at the back end.
Let’s talk about Pega 🙂
In Pega, we have a few important configuration files. I will walk you through the personal edition software directory.
This is my PRPCPersonalEdition location.
Note: Personal editions are web applications and so you see the tomcat webserver.
You can enter into the tomcat -> conf
You can see a few configuration files specific to tomcat web server.
Server.xml – contains certain host name and port number configuration for the server
Web.xml – contains servlet configurations and stuffs for the web server Eg, PRServlet, WebLDAP1 etc.
You can open and see the settings by yourself
Now come one step back and move through the following directory tomcat -> webapps
You see there are 3 default webapplications are hosted in the tomcat server.
Note: From Pega 8 version, SMA web app is replaced by Pega admin studio
Note: I hosted a Jenkins server for my research purpose, you won’t find it in your installation package.
Let’s go further inside on the following path tomcat ->webapps ->prweb -> WEB-INF -> classes
You see the prconfig.xml file. This is where most of the system configurations are done.
Just open the prconfig.xml file
You can see certain DB related configuration and stuffs!
Note: prconfig.xml will be specific to node (server)
Let me put a full stop on these configuration files and jump into DSS and system settings.
DSS – dynamic system settings
DSS can be categorised into two types
- Application system (server) specific
- Application business specific.
a) Application system (server) specific
You can either set or change the system configuration settings using DSS.
The prconfig.xml settings can be overridden by the DSS values.
Pega provides lots of system specific default DSS values that can override the values from prconfig.xml
Please follow the below PDN link to look at the default DSS settings from Pega 7.4
Go to Records -> Sysadmin -> Dynamic system settings.
You will see the list of default Dynamic system settings provided by Pega.
I am going to show you some crazy configuration.
John Snow welcoming Pega express 😀
I made this by just updating the default DSS – Video/WelcometoExpress.
Just update the highlighted box and you can see John Snow in action 🙂
What are the advantages of having these settings as dynamic?
It can be changed any time, very easily. Dynamic system settings are data instances and so it will not come under any locked ruleset.
So, updating a DSS does not require a release deployment and can be updated easily in production
A single DSS can be applied to multi nodes system.
What is multi-mode?
Usually when our Pega application is used by many end users, then organization can decide to run the applications in multi-node ( multi servers) so that the load is shared equally (using load balancer) and application performance is maintained.
Multi-nodes system share the common database.
We know rules , data instances, work instances all get stored in database tables.
So it’s like all multi-node systems point to the common database and any changes in rules/data in database will be reflected in all systems.
Hence proved , A single DSS can be applied to multi node systems 🙂
This is the big advantage over the prconfig settings, because, prconfig files are specific to each nodes (servers) and thus the changes have to be done in all the prconfig files in multi node system.
Now let’s go to second type
b) Application business specific DSS
DSS can also be used to add or update the application business specific configurations
Requirement: Let’s say a bank, HDSC is using pega customer service application. The bank follows a business policy like, when a customer is in arrear for 60 days( it means he /she didn’t pay the loan due amount for 2 months), then the customer should be treated by the HDSC bank employees.
I would say, 60 days is an application business specific configuration and it should be treated dynamic, so that it can be changed easily in the future.
Technically, I would achieve this business scenario by placing a case in the workbasket and wait there for 60 days. SLA can be set on the workbasket based on the DSS value!
When you come across similar business scenarios, always try to make it configurable using DSS 🙂
How to create a new DSS?
Step 1: Records -> Sysadmin -> Dynamic system settings -> New
Owning ruleset – Specify an application rule. Used in packaging
Setting purpose – This will the data instance name. Give a meaningful name.
Click create and Open.
Step 2: Provide the value
Huh, This is one of the most simplest rule type in Pega! 🙂
I gave the value as 60.
Now, how a DSS can be referred in other rules?
Pega is there to help. Pega provides an OOTB function to retrieve the value from the DSS rule.
Open the function rule – GetDataSystemSetting
Record -> Technical -> Function –filter on GetDataSystemSetting
You can also search and open the rule.
You can see it accepts two input parameters and returns the output as string.
Remember when you create, the two input characters are the key of the DSS rule.
Let’s test this function rule
Step 1: for testing purpose, create a new activity rule
Step 2: Add a new step with step page – test page and method as property-set
Step 3: Use the expression builder on the property set method and search the function using browse
Step 4: Click on the function and pull it in the editing area using (+) and include the two parameters.
Step 5: Click on test to test the function. You should see the value 60
Done 🙂
Step 6: For testing, set it to some property, say pyLabel and use show-page method
Step 7: Run the activity, you can see pyLabel value is set from the DSS rule as 60
Also, you can see the DSS instances are saved in the pr_data_admin table.
Important note: Pega deprecated the System settings rule from Pega 8.3 version and introduced a new rule called Application Settings that replaces System settings. It is recommended to visit Application settings blog article
System settings
This is the second type of rule where you can configure the system settings.
Let me start with the differences between DSS and System settings.
What are the differences between DSS and System settings?
DSS are data instances and System settings rule are rule instances
Rule instances cannot be modified without an unlocked version and thus changes in the System Settings rules are always by preparing a deployment to production, whereas in DSS changes can be done directly in production without a deployment.
DSS can hold only a single value, whereas a System settings can hold 5 different values based on production level ( environments)
The ideal use case is an external service URL.
Say like, your pega application connects with an external system using connect-REST. In your project,
you have 4 different environments
- Development
- System Test
- User Acceptance Test
- Production
In lower testing environments, you cannot connect to external system’s production data. It is required that they have different environments with different service endpoints to connect.
System Settings rule come as an ideal candidate for this requirement.
Open any System settings rule
Step 1: Records -> SysAdmin -> System Settings rule
Open any instance.
You see the system setting values for different production level.
What is Production level in Pega?
Production level are normally associated with the environment. It ranges from 1-5
1 – sandbox / research environment
2- Development environment
3- System / Load test environment
4- User acceptance test environment
5- Production environment
You can see the current production level from the System rule.
Designer studio -> System -> General -> System, Nodes, Requestors
You can open the system rule and update the production level.
In the clipboard, you can see the current production level in
System pages – pxProcess – pxAdminSystem – pyProductionLevel
How to create a new system settings rule?
Step 1: Records -> Sysadmin -> system settings -> new
Step 2: provide the value based on the environments
For testing I varied the arrear wait days per environment.
That’s it 🙂 again it is a very simple rule to configure
Now, how a System settings rule can be referred in other rules?
Exactly same as DSS instance, Pega provides a separate function rule to handle
Search and open the rule – getRuleSystemSetting
Same type of input and output parameters.
Let’s straight away test this using the same test activity we used for DSS.
Step 1: Open the same activity created before for DSS tutorial and expand the step1
Step 2: Follow the same steps to update the expression using expression builder. Search for getRuleSystemSetting
Step 3: Provide the same input parameters
FirstApp,ArrearWaitInDays
Step 4: You can click test, to find the output parameter.
We know the current production level is 2 and so the output is 1 day 🙂
Step 5: Apply this function to set the value to pyLabel and run the activity to check the value.
Nice 🙂
Note: when the same activity is run on the production environment with production level 5, then the return output will be 60.
Note: Mostly System settings are used to specify different URL per environment.
I hope you are clear with DSS and System settings 🙂
Remember both has positive as well as negative
1. DSS can updated any time in production without deployment, on the other hand System settings are rule instances and can be updated only with deployment. Exception case, where we can save the system settings in production ruleset (unlocked) and can update the URL!! so DSS 1 , System Settings 0
2. If we need to have different values in different environments, then we have to carefully update the DSS manually in all environments, where as in System settings you can specify value per environment only once. so DSS 1, System Settings 1
So first analyse which fits you best and use the system setting rules/data instances accordingly!!
