System settings
System settings rules define run-time settings that can differ based on a system's production level, and which are further resolved at run time through rule resolution. System settings are identified by name and owning ruleset. The owning ruleset functions as a namespace and does not have to equal the ruleset that contains the rule.
The benefit of defining a setting by production level means, for example, that if you create an application in a development area, and plan to move it to a test area and then into production, you can provide values for this System setting for each level, and then move the setting rule into each area without having to reset the rule value.
A predefined System setting can be overridden by saving it into a different ruleset, with the same name and owning ruleset name. At run time, rule resolution determines which version of the setting takes effect.
Custom settings can be created in one of your application's rulesets, and can be thought of as constant for that application, further defined by production level.
Circumstance and time-qualified resolution features are not available for System settings rules.
Evaluation of System settings
Your application can query instances of the System settings class using the Java
get
method in the PublicAPI
PRSystemSettings
interface. For
more information, see
Java methods for Dynamic System Settings and System settings.
The rule and data instances listed below have similar names, but they are not related. Use System settings rules to hold important constant values in your application that are the same in every deployed copy of your application. Use Dynamic System Settings when the values differ from site to site, such as with URLs, user names, or port numbers, and when they might be set programmatically.
- System settings rules ( Rule-Admin-System-Settings rule type)
- Dynamic Systems Settings data instances ( Data-Admin-System-Settings )
- Setting rules ( Rule-Access-Setting rule type)