Question
Dynamic System settings
Hi All,
I am new to this topic,can any one describe in which scenario dynamic system settings and system settings need to create. And its classified into rules-admin-system-settings and data-admin-system-settings,how they are useful.
Expecting with real time scenario.
Thanks in Advance...!!!
***Updated by moderator: Lochan to close post***
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Accepted Solution
Areteans Technology
IN
Hello N@gendra,
To start with it is a good question. System settings is a rule and dynamic system setting is data instance.Both have the same key combinations Owning Ruleset and Name of the setting.
Do we have rulesets open in production or anyother higher environments(except prod rulesets). The answer is typically no. So this infers to when you know the varibale is not expected to change over a period of time and if you need a change in it, you would expecct a code change to go in, use rule system setting. EX: URL to open other internal system. (you know the value is different in every environment and would not change very often).
If you expect the value might change frequently and you would rather avoid a deployment and have your support team change the value in production, use dynamic system setting. ex: 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 settings used by pega.
As dynamic system settings is a DB read always(no caching etc), it is db intensive. So, you might even extend Declare_CachedDataSystemSettings which is provided OOTB in your application to reduce DB calls.
Hello N@gendra,
To start with it is a good question. System settings is a rule and dynamic system setting is data instance.Both have the same key combinations Owning Ruleset and Name of the setting.
Do we have rulesets open in production or anyother higher environments(except prod rulesets). The answer is typically no. So this infers to when you know the varibale is not expected to change over a period of time and if you need a change in it, you would expecct a code change to go in, use rule system setting. EX: URL to open other internal system. (you know the value is different in every environment and would not change very often).
If you expect the value might change frequently and you would rather avoid a deployment and have your support team change the value in production, use dynamic system setting. ex: 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 settings used by pega.
As dynamic system settings is a DB read always(no caching etc), it is db intensive. So, you might even extend Declare_CachedDataSystemSettings which is provided OOTB in your application to reduce DB calls.
Also in your system, if you often sync production environment into lower environments for good testing data or compliance reasons etc, remember the dynamic system settings of production will be overriden in lower environments too.So after every sync, you have to change the DSS values appropriately if needed in the lower environments.
both have pros/corns but typically if you are not expecting a change in the variable use rule system settings.If you feel you might change it often, use dynamic system settings.
Thanks,
Ashok
Pegasystems Inc.
US
A good discussion and example of this topic is in the system operations section of the PDN. Consider the article below as a starting point that contains an example.
https://docs-previous.pega.com/system-administration/creating-and-modifying-dynamic-system-settings
Lu
The Pega Academy Support Team
COGNIZANT TECHNOLOGY SOLUTIONS
IN
Hi Leo,
First of all thanks for your reply..
By the way i read that blog previous,but i didnt find what i want.For your summarize i want to know why we need to create system settings and how its useful in real time projects.
Infosys Ltd
IN
Hi,
Most of the system configuration settings contained in the prconfig.xml file can be overridden and modified using dynamic system settings.
Using Dynamic System Settings prevents the hassle of editing the proconfig.xml, which depending on the application server used might require redeploying the entire PRPC application for the changes to take effect
An additional advantage is in a multi-node system where the Dynamic System Settings are shared by all
nodes sharing the database making administration of the cluster easier.
Accepted Solution
Areteans Technology
IN
Hello N@gendra,
To start with it is a good question. System settings is a rule and dynamic system setting is data instance.Both have the same key combinations Owning Ruleset and Name of the setting.
Do we have rulesets open in production or anyother higher environments(except prod rulesets). The answer is typically no. So this infers to when you know the varibale is not expected to change over a period of time and if you need a change in it, you would expecct a code change to go in, use rule system setting. EX: URL to open other internal system. (you know the value is different in every environment and would not change very often).
If you expect the value might change frequently and you would rather avoid a deployment and have your support team change the value in production, use dynamic system setting. ex: 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 settings used by pega.
As dynamic system settings is a DB read always(no caching etc), it is db intensive. So, you might even extend Declare_CachedDataSystemSettings which is provided OOTB in your application to reduce DB calls.
Hello N@gendra,
To start with it is a good question. System settings is a rule and dynamic system setting is data instance.Both have the same key combinations Owning Ruleset and Name of the setting.
Do we have rulesets open in production or anyother higher environments(except prod rulesets). The answer is typically no. So this infers to when you know the varibale is not expected to change over a period of time and if you need a change in it, you would expecct a code change to go in, use rule system setting. EX: URL to open other internal system. (you know the value is different in every environment and would not change very often).
If you expect the value might change frequently and you would rather avoid a deployment and have your support team change the value in production, use dynamic system setting. ex: 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 settings used by pega.
As dynamic system settings is a DB read always(no caching etc), it is db intensive. So, you might even extend Declare_CachedDataSystemSettings which is provided OOTB in your application to reduce DB calls.
Also in your system, if you often sync production environment into lower environments for good testing data or compliance reasons etc, remember the dynamic system settings of production will be overriden in lower environments too.So after every sync, you have to change the DSS values appropriately if needed in the lower environments.
both have pros/corns but typically if you are not expecting a change in the variable use rule system settings.If you feel you might change it often, use dynamic system settings.
Thanks,
Ashok
Pegasystems Inc.
IN
Great work together on this thread here in Pega Platform. I wanted to take a moment to let you all know that we now have the Product Support Community live on the PDN. I request that you refer all product-related questions to this new Community. It will be the best place moving forward to receive assistance!
Hope to see you there!
Lochan | Community Moderator | Pegasystems Inc.