Press "Enter" to skip to content

System setting and dynamic system setting rules in Pega

19

Introduction

In this post, we will see more in detail about configuring the system settings.

Let’s talk some basics about system settings.

Think about any software you install, You have an option to customize few settings.

For example, If you are  installing a 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 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 few configuration files specific to tomcat web server.

Server.xml –  contain 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.

1. prweb – where our pega instance is hosted.

2. prhelp – help system is hosted (Other action – help)

3. prsysmgmt – SMA stand-alone application is hosted

Note: I hosted a Jenkins server for my research purpose, you won’t find it in your installation package J

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

  1. Application system (server) specific
  2. 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

https://community.pega.com/sites/default/files/help_v74/procomhelpmain.htm#data-/data-admin-/data-admin-system-/data-admin-system-settings/data-admin-systemsettings.htm

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 multimode?

  • 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.
  • Multinodes system share the common data base.

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.

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.

System settings

This 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, where as in DSS changes can be done directly in production without a deployment.

  • DSS can hold only a single value, where as 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

  1. Development
  2. System Test
  3. User Acceptance Test
  4. 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 environments.
  • 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 J

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

  • 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
  • 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!!

One of my subscriber was asking this post for long, so this is for him. Happy Bharadwaj ? 😀

I hope you like the upgraded version of myknowpega!!

  1. Sai Sai

    Excellent Prem. Thank you.

    • Premkumar G Premkumar G

      Thank you, Sai. 🙂

  2. Suma Suma

    Thankyou prem. Very much useful
    I have a query. Suppose if we need to update the one property value in production but that property is not available in pyworkpage and as we have a option to add property in pyworkpage i have added but its not coming up in pyworkpage. Can you please suggest if we have any other approach

    • Premkumar G Premkumar G

      Hi Suma,
      I believe the help documentation for clipboard is quite misleading. To my knowledge, we cannot commit the changes in the database. Save just save the data in memory. You have to create some standalone utility (activity) to update property values in production

  3. Rajiv Rajiv

    Few things
    1) Multinode systems can have a delay of upto 60 seconds or more for sync of these values. Note that these settings are cached in and SystemPulse will invalidate them every 60 seconds based on the edits performed.
    2) The DSS can be overridden through JAVA_OPTS using the -D option to Java command line arguments.

  4. Vamsi Vamsi

    Hi Prem, The look and feel of site is very nice compared to last version. And this article is excellent as similar to old ones. 🙂

    Also a small request, Can you please make an article on OOTB functions atleast some which are more common and makes our life more easy.

  5. Syed Syed

    Explanation is Crisp and Clear. Thank you for keeping it so simple yet so informative.

  6. Rushi Rushi

    HI Prem,

    Super… and thanks for sharing the valuable information

  7. Sivajyothi Sivajyothi

    Hi Prem,
    Just wanted to know few things..
    Is this WebPage built on Pega?
    The new look of this site is really Awesome, and i wanted to know how you built the header part SplitScreen UI.
    Can you make a post on how to build such type of UI.

  8. Charan narra Charan narra

    Very nice and perfect explanation bro.please explain pega versions upgrade.

  9. Sairam Sairam

    Thank you Prem, Very Much Useful, If possible can you please make a posts on SMA, PAL, and DCO

  10. Prashanth Prashanth

    Hi Prem,

    What is load balancer and how it will work?

  11. Srikanth Veeramalla Srikanth Veeramalla

    Thanks Prem. Very Good Explanation

  12. Somenath Panda Somenath Panda

    Great post Prem. It is so easy to understand and clear the concepts. Will wait for your next post. Please update soon.

  13. Faijas Faijas

    Excellent writeup . Keep up the good job

  14. Chandramouli Chandramouli

    Hi Prem,

    I am working on an application, and DSS is defined in another application’s Ruleset. My Ruleset is not Prerequisite of DSS’s Ruleset. so can i use DSS in my current application.?

  15. Divya Divya

    Could you please explain PEGA pulse configuration

  16. Hi Rajiv ,
    What are multi node systems and what is meant by DSS.

  17. Aleksandr Belenov Aleksandr Belenov

    Thank you very much.

Leave a Reply

Your email address will not be published. Required fields are marked *

error: Content is protected !!