Question
Atos Syntel
IN
Last activity: 16 Oct 2018 12:03 EDT
System Settings vs Dynamic System Settings
Facts from link https://docs.pega.com/understanding-system-settings-v51
- DSS can be updated/created programmatically, whereas you need to manually update System settings if you want to change it's value.
- System Settings is a rule which means multiple instances can exist by ruleset versioning, whereas only one instance of DSS can exist.
- System Settings can have environment specific value(by use of production level) whereas DSS can have only one value for all(unless you change it in each environment).
Questions
- Can a setting be configured in both System settings and DSS (not at the same time)?
- How does PRPC process/checks the Systems settings and DSS ?
like for example if PRPC needs to check a setting's value, will it know whether the settings belong to Systems settings or DSS or will it check both Systems settings and DSS to find the setting's value.
***Moderator Edit: Vidyaranjan | Updated Categories***
**Moderation Team has archived 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
Pegasystems Inc.
IN
Hi,
Both System Settings (Rule-Admin-System-Settings) & Dynamic System Settings (Data-Admin-System-Settings) are related. In certain cases, the data instances can override the values provided in the corresponding rule.
Refer the below discussion should be helpful.
https://collaborate.pega.com/question/dynamic-system-settings
Mostly you won't set values at both places but if you have in most cases DSS setting will take precedence. Don't know about any particular case where DSS won't be considered first.
Thank You
Pegasystems Inc.
IN
Hi,
In Version 5.1, the System Settings functionality allows application developers to easily change or add settings. This provides a place where system constants may be set and stored in the PegaRULES database, for all nodes to access. Beginning in Version 5.1, many - but not all - of the prconfig.xml settings are moved to the System Settings feature.
Hi,
In Version 5.1, the System Settings functionality allows application developers to easily change or add settings. This provides a place where system constants may be set and stored in the PegaRULES database, for all nodes to access. Beginning in Version 5.1, many - but not all - of the prconfig.xml settings are moved to the System Settings feature.
Although the System Settings functionality is similar to settings in the prconfig.xml file, this new feature does not completely replace that file. As System Settings are stored in Process Commander classes (which are in turn stored in the database), the system constants can only be accessed after the Process Commander application has been initialized, and has the information to be able to connect to the database. Therefore, this functionality cannot be used for allsystem settings; the initialization settings must still be stored in the prconfig.xml file
Thank You.
Atos Syntel
IN
Hi Shekar,
I can understand that the initialization settings should be set in prconfig.xml, rest of the settings can be in prconfig.xml or DSS or System settings.
My question is not about prconfig.xml, my question is about DSS and System Settings
Posting the questions again:
- Can a setting be configured in both System settings and DSS (not at the same time)?
- How does PRPC process/checks the Systems settings and DSS ?
like for example if PRPC needs to check a setting's value(assuming that it is not set in prconfig.xml), will it know whether the settings belong to Systems settings or DSS or will it check both Systems settings and DSS to find the setting's value.
Accepted Solution
Pegasystems Inc.
IN
Hi,
Both System Settings (Rule-Admin-System-Settings) & Dynamic System Settings (Data-Admin-System-Settings) are related. In certain cases, the data instances can override the values provided in the corresponding rule.
Refer the below discussion should be helpful.
https://collaborate.pega.com/question/dynamic-system-settings
Mostly you won't set values at both places but if you have in most cases DSS setting will take precedence. Don't know about any particular case where DSS won't be considered first.
Thank You
Atos Syntel
IN
So it is possible to have all/some settings in both System Settings and DSS and when it comes to which one to pick DSS will take precedence.
Please confirm.
Pegasystems Inc.
IN
Hi,
There are many threads you can refer to regarding the same.
To give brief idea refer the below explanation and links
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 any other higher environments(except prod rulesets). The answer is typically no. So this infers to when you know the variable is not expected to change over a period of time and if you need a change in it, you would expect 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.
Hi,
There are many threads you can refer to regarding the same.
To give brief idea refer the below explanation and links
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 any other higher environments(except prod rulesets). The answer is typically no. So this infers to when you know the variable is not expected to change over a period of time and if you need a change in it, you would expect 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 overridden 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. (https://collaborate.pega.com/question/dynamic-system-settings)
https://docs-previous.pega.com/understanding-system-settings-v51
https://community.pega.com/sites/default/files/help_v71/procomhelpmain.htm
Thank You