When developing an application in the Pega Platform™, you can use built-on applications to enhance ruleset and framework reuse across applications and to reduce dependencies between applications.
Built-on applications are structured as a hierarchical application tree and are added by using the Open Application form in Dev Studio. For more information, see Application stack hierarchy for multiple built-on applications.
Benefits of using multiple built-on applications
Application development and maintenance are significantly enhanced when you use multiple built-on applications.
Configuring an application by using a single built-on application creates complex application structures that become challenging to maintain over time. For example, a combination of one or multiple frameworks with enterprise rulesets can potentially contain multiple unrelated rulesets, and also might result in your having to clone application definitions that you do not directly manage. This situation creates a large number of required updates when changes are made, including having to resynchronize various rulesets and versions across applications.
Using multiple built-on applications breaks up common and stand-alone components into their own applications, and provides the ability to point an application to another application rule, helping to automatically update any required rulesets and versions across applications when changes are made. The use of multiple built-on applications also eliminates the need to use ruleset prerequisites, helping developers to avoid warnings related to the use of rulesets that use Application Validation mode and are located across multiple applications.
Best practices for using multiple built-on applications
Refer to the following tips when developing an application that uses multiple built-on applications:
- Limit development to rulesets in the top-most application, and switch applications to develop in the lower layers of the hierarchical application tree.
- Avoid having the same ruleset in multiple applications. Instead, refactor the ruleset to its own application or a common application.
- Avoid using different versions of an application in the hierarchical application tree.
- Avoid branch IDs that span several applications.
- Avoid making any application structure changes without utilizing the Validation Tool to validate rules.