Links may not function; however, this content may be relevant to outdated versions of the product.
How to compose the key of a PRCONFIG dynamic system setting
Summary
Beginning with version 6.2, you can store prconfig system settings as Dynamic System Settings, an optional alternative to the prconfig.xml file.
When you define a new prconfig system setting as a Dynamic System Setting, it is important to ensure that the key string for the setting (the field labeled Setting Purpose) has the correct structure and values.
This article explains the parts of the key string, and how you can determine the key string for a new prconfig system setting.
For information about Dynamic System Settings and the prconfig.xml file for Pega 7.3 and greater, see Configuring system settings.
Suggested Approach
Parts of the key string
The Owning Ruleset for Dynamic System Settings that hold a prconfig value is always Pega-Engine.
The Setting Purpose key string of a prconfig system setting stored in a Dynamic System Setting consists of three parts, in the following format:
File type/Setting Name/Classification
- File type: The file type consists of the the portion of the key string before the first slash. For prconfig system settings this must be prconfig.
- Setting name: The setting name consists of the portion of the key string between the first and the final slashes. The setting name identifies the specific system setting, and typically includes one or more slashes to help categorize prconfig settings by function.
- Classification: The classification consists of the portion of the key string following the final slash, and identifies the nodes to which this setting applies.
For example, the following key string defines the threshold for the PEGA0005 alert:
prconfig/alerts/database/operationTimeThreshold/default
File type
In this instance, the file type is prconfig, as for all prconfig settings.
Setting name
The setting name is alerts/database/operationTimeThreshold, identifying that the setting refers to the operation time threshold for database alerts.
Classification
The classification in this example is default, meaning that this setting will apply to all nodes which do not have an overriding setting.
Setting Name
The setting name portion of the key string identifies the specific function of the setting. Setting names generally have a category and one or more sub-categories separated by slashes, followed by a descriptive string identifying the setting purpose.
In the Pega0005 alert setting example, the setting name is alerts/database/operationTimeThreshold. This tells you that this prconfig system setting is in the alerts category, deals with with alerts pertaining to the database, specifically defining value of the operationTimeThreshold.
The Configuration Settings Reference Guide is the primary source for setting names, and contains descriptions for each available setting. Additionally, you can pull the setting name for a prconfig system setting from an entry in the
prconfig.xml
file. The prconfig.xml
entry for the database operation threshold setting would appear as follows:
<env name="alerts/database/operationTimeThreshold" value="1000" />
The setting name for this entry is the contents of the name parameter.
Classification
The classification portion of the key string identifies the nodes to which a prconfig system setting will apply. Classifications are most useful and meaningful when your system has a multi-node cluster of two or more servers.
You determine the classification of a node in the initialization/nodeclassification entry in the prconfig.xml
file for that node. Note that this setting must exist in the prconfig.xml
file, and cannot be implemented as a Dynamic System Setting. (In a multi-node cluster each node contains its own prconfig.xml file, allowing nodes to contain different node classifications.)
When the classification of prconfig setting is anything but default, that setting will only apply to nodes with that exact classification. A prconfig setting with a classification of default will apply to every node in the system which does not have the same setting with a matching specific classification.
For example, you are on a node which is classified with the following prconfig.xml
entry:
<env name="initialization/nodeclassification" value="DedicatedAgentNode" />
The node also loads the following Dynamic System Settings from the database:
prconfig/alerts/database/operationTimeThreshold/default
prconfig/alerts/database/operationTimeThreshold/DedicatedAgentNode
In this case, the value of the second, more specific setting will be used.