Authored by Anonymous
A dynamic system setting (DSS) is an instance of the Data-Admin-System-Settings class, which can be used to define settings of the system and application. Dynamic system settings provide flexibility to manage and drive the system’s runtime behavior without the need to update any locked rules.
One advantage of using a DSS is that the values of a setting can be set based on the environment (Dev, QA, Stage. or Production). A second DSS advantage is that the value of a setting can be easily updated without rule changes when there is a business or technical need.
Common scenarios where a DSS can be used include:
- Connector endpoint URLs
- Application specific constants that can be used in the application’s Microjourneys and business logic
prconfigsystem settings
Creating a DSS
To learn how to create a DSS, refer to the following article:
https://community.pega.com/knowledgebase/articles/security/86/creating-dynamic-system-setting
Fetching the value of a DSS
Pega Platform provides Rule-Utility-Functions (RUFs) that can be used to retrieve the value of a DSS. The following RUFs can be called from application rules (such as data transforms or when-rules) to fetch the DSS value as a ‘String’:
Figure 1: RUF to fetch DSS value
| RUF Name | Parameters |
getDataSystemSetting |
owningRuleSet: Ruleset in which the DSS is saved
|
pyGetDynamicSystemSettings |
Tools: PublicAPI instance
|
DSS use cases
This section summarizes common business scenarios in which a DSS can be used.
Connector endpoint URLs
Consider a scenario where an application must use a REST call to fetch rate sheet information from an external system as part of an underwriting process. In this scenario, you would create a DSS (as shown in Figure 2) to hold the endpoint URL of the service, which eliminates the risk of hardcoding the same in the invocation routines (such as the Connect-REST method of an activity). Using the Pega-provided RUF, the application reads the DSS value and invokes the service connector. This DSS value can be updated in each of the environments (Dev, QA, and Prod etc.) easily without a need of deployment cycle.
Figure 2: Connector endpoint URL
Figure 3: Using DSS during connector call
Application-specific constants
Scenario 1
In a telecom application, a customer wants to archive expired offers after 30 days. The application should be flexible to allow changes to the archive period value at any point of time. To address this requirement, you would create a DSS as shown in Figure 4, and then use the DSS in your application to identify offers older than the specified archive period.
Figure 4: Setting offer expiry value as DSS
Figure 5: Using DSS value in an activity
Figure 6: Loan limit DSS
Scenario 2
In a banking application, a customer wants to develop a loan application review process. In this process, the loan application must get additional approvals when the loan amount exceeds a threshold amount, such as $5000. This loan threshold value can change based on the business demand and government financial regulations. To address this requirement, you would create a DSS that can hold the loan threshold value and use the DSS in the case approval process.
Driving prconfig settings with DSS
You can use a DSS to maintain prconfig settings. Setting a prconfig value by using a DSS makes it easier to maintain the value in a multinode environment. For example, you could use a DSS to update the system name (Data-Admin-System).
When you define settings using dynamic system settings, setting values are stored in the PegaDATA schema of the database and are applied to all nodes.
Advantages of using DSS to maintain prconfig values include:
- Pega applications are commonly deployed in a multi-node environment. System setting values can be defined using DSS to centralize maintenance. If system setting values are not defined using DSS, then any change in the configuration must be replicated manually on each node.
- Pega applications have the flexibility to update
prconfigvalues without additional deployment process.
Figure 7: Setting prconfig values through DSS
Comparing application settings and dynamic system settings
Application settings are rule instances, so any changes to application settings require a deployment.
Application system settings are useful in the following situations:
- The application setting value is based on the production level. The production level can range from 1 to 5.
- The application setting value doesn’t change frequently or a code change is not required when the value changes
Refer to the following article for information on application settings:
References
For more information on dynamic system settings, refer to the following articles: