Pega recently launched version 8.6, which introduces some incredible enhancements focused on delivering improved user experiences, simplified sophisticated app development, and more. In 8.6, we implemented a new unified configuration framework called configuration sets to allow for truly upgradeable and dynamic applications. Across Pega applications, we see many different implementations that provide simple app configurations to end users. This can be a challenge because it makes upgrades more difficult and reduces the predictability of each app. These configurations often require rule overrides, which introduce backwards compatibility and upgrade issues. Configuration sets resolve these issues.
How to find and define configuration sets
Configuration sets can be found in App Studio under Settings > Configurations. Once on the configurations page, you will see all configurations within your system grouped by set. There are two new important terms with regards to configurations:
- Configuration set: A high-level grouping of settings that reflect a feature within your application.
- Configuration setting: An individual setting that controls some piece of application behavior within an application.
Begin by defining the configuration sets, or features that require configuration, within your application. To do this, click the “Manage configuration sets” button on the top right. A modal, where you can create new sets, will launch. You can return to this modal at any time to add new configuration sets.
Next, define the individual settings within your application. Since each configuration set reflects a configurable feature within your application, start by adding configuration settings to a single set. Use the “Add configuration” button in the top right to create a new configuration. It is important to note that if you have not created any configuration sets yet, this button will be disabled, since every setting must belong to a set.
Once you launch the “Create configuration” modal, start by defining a name and description. It is important to give sensible names and descriptions, as this will help both application users and developers understand the intent of the configuration. Next, provide the set it belongs to and scope. Configuration has three possible scopes:
- Application
- Case type – All
- Case type – Specific
Configurations respect rule resolution, and the scope will determine where you can reference these configurations throughout your application. You can provide a type for configurations (Text, Boolean, Picklist, etc.) Finally, every configuration must have a default value. This value is used when end users have not provided a configuration. This value can only be changed by application developers and should define the default or “shipping” behavior of a feature. Default values can be a static value or can be calculated by a decision table. The decision table will be defined in the class specified in the configuration scope. There are plans to expand the types of calculations in the future, but decision tables are the only calculated type in 8.6.
Submit the configuration when complete and iterate on creating settings to finish defining out the configurable features within your application. It is important to note that you do not need to add all your configurations up front. You may return to add, delete or update configurations at any point during your application development, but it is helpful to think in advance about which features you'd like to have.
Referencing configuration sets throughout your application
Once created, configuration settings may be updated to change metadata such as default value, name or description. You may also delete configurations. If the setting you are trying to delete was defined in a locked rule set, the setting will be deprecated rather than deleted to ensure backwards compatibility. You will be shown where in the application the deleted setting is currently being used to understand the impact of the changes you are making.
Configuration sets also track any changes being done to configurations by rule set version. At any point, you may use the “What’s new” link to show the audit of the configurations. These changes track updates, deletions and new settings to provide visibility into what has changed. Note that these changes are consolidated by rule set version so if a default value is changed several times in a single version, only the final delta is shown.
Configurations can be referenced throughout an application through two main mechanisms, Condition builder and Expression builder. Expression builder configuration referencing is only supported for data transforms, activities, and declare expressions. Condition builder configuration referencing is supported for the entire platform. In both experiences, you will see a top-level category for Configurations. Clicking on this will bring you to a list of configuration sets, which can be drilled into to get the individual settings. Click on any setting to reference it.
Enabling safe end user configurations
One of the main benefits of configuration sets is the ability for end users, tenants, and applications to override configurations without the need for rule overrides. To expose this capability to an end user, add the new pxAdministration landing page to any of your channels. This is an out-of-the-box, dynamically-generated page which shows all configurations grouped by set or by scope. From here, users can view default values, create new overrides and view existing overrides.
When an end user creates an override, a data record specific to that tenant is created with the new value for the setting. It is important to note that this does not affect default value, but rather creates a tenant-specific data instance. It is also important to note that an end user cannot change the existing references to that configuration, or the type of the configuration. This allows the application developers to change, update, delete, and push new changes to their users without worrying about upgrade impact. The tenant-specific data will always take precedent and end users can revert to the default when needed.
You can also apply security to the pxAdministration landing page to control which personas can see which configuration sets. Use the new persona security authoring under Users > User management in App Studio. Here you will see a list of your personas defined in the application. Click on a persona to drill into the new security experience. Here you will be able to identify simple CRUD privileges on cases, data and configurations. Removing write access for a configuration set for a given persona will still show the configuration set in their experience, but in read only mode. Removing read access will remove the set from the pxAdministration page for that persona all together. It is important to note that none of these privileges affect a persona's ability to execute a configuration at runtime, but do control the ability to view or update.
Recommended Resources:
- Take a look at this article on the Pega Wiki to learn more about configuration sets.
- Curious about what else is new in 8.6? Find out here!
Don't Forget
-
JOIN THE CONVERSATION on Collaboration Center
-
FOLLOW @PegaDeveloper on Twitter
-
SUBSCRIBE to the Pega Developer Podcast on Spotify or via RSS