Configuring Dynamic System Settings

From PegaWiki
This is the approved revision of this page, as well as being the most recent.
Jump to navigation Jump to search

Configuring Dynamic System Settings

Description Guidelines for configuring dynamic system settings
Version as of 8.6
Application Pega Platform
Capability/Industry Area System Administration



Introduction[edit]

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
  • prconfig system settings

Creating a DSS[edit]

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[edit]

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

setting: Name of the DSS

pyGetDynamicSystemSettings Tools: PublicAPI instance

aOwningRuleset: Ruleset in which the DSS is saved

aKey: Name of the DSS

DSS use cases[edit]

This section summarizes common business scenarios in which a DSS can be used.

Figure 2: Connector endpoint URL

Connector endpoint URLs[edit]

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 3: Using DSS during connector call

Application-specific constants[edit]

Scenario 1[edit]

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[edit]

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[edit]

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 prconfig values without additional deployment process.
Figure 7: Setting prconfig values through DSS

Comparing application settings and dynamic system settings[edit]

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:

https://community.pega.com/sites/default/files/help_v85/procomhelpmain.htm#rule-/rule-admin-/rule-admin-system-/rule-admin-system-settings/new.htm              

References[edit]

For more information on dynamic system settings, refer to the following articles: