Built-on applications and components

Decomposition refers to the process of breaking down a problem into smaller, more maintainable parts. In programming, these parts are called components.

To create a solution that includes case types, you need an application. When an application is used as a built-on application, the built-on application can be considered a component. A collection of rulesets that do not include case types can also be considered a component. Examples include reusable flows or correspondence, integration assets, or a function library. An application can leverage either type of component and then become a component itself or be deployed as a production application.

The following example shows the built-on applications and components that support a Claims application. 

The Multiple built-on Applications (MBO) flattening algorithm always takes the lowest position or precedence of any repeated application and then uses the highest version referenced in the flattened application stack.

For a video demonstration and detailed discussion of multiple built-on applications, see the Pega Community Tech Talk video Multiple built-on applications.

Numerous applications and components are available for reuse on the Pega Marketplace. To contribute to the Pega Marketplace, submit applications and components to make them available to Pega Community. For example, you can use the PegaDevOpsFoundation application as a sibling built-on application when using the Deployment Manager application to orchestrate CI/CD.

For applications that you want to display in the New Application wizard as potential built-on applications, on the Application wizard tab of the application rule, select the Show this application in the New Application wizard check box.

Use the Components landing page (Dev Studio > Configure > Application > Components) to create and manage components. A component defines a set of ruleset versions and can have other components or applications as prerequisites.

When creating a case type that does not extend a foundation application case type, it is advantageous to add that case type to a new, case type-specific ruleset. Doing so facilitates the development of component applications. When this approach is followed, and an application is built on PegaRULES, every case type exists in its own ruleset. The application rule, work pool class, and application data classes exist in the ruleset created by the New Application Wizard.

A case type that appears to be a good candidate for a component application should avoid dependencies on the work pool class and application-level data classes. Instead, the case type component candidate should utilize the data class that the application-level data classes extend. Similarly, work pool rules that the case type component candidate uses can be moved to the layer beneath the current application.

At the point that all dependencies on the current application are removed, the Refactoring wizard (Dev Studio > Configure > System > Refactor > Classes) can be used to rename the original class by replacing the existing application reference in the original case type’s class name -APP- with the name of a new component application -NEWAPP-. This newly created and refactored case type class and all its associated rules can then be placed within its own component application with the name NEWAPP. The original application is then modified to reference the new NEWAPP component application as a built-on application. Finally, the original case type class from the original application is re-created by importing it as a direct descendant of the newly created and refactored class in the NEWAPP component application. When re-created by importing, the original case type class is automatically saved to the original application's application ruleset.

When citizen developers design and implement applications using App Studio, they typically include multiple discrete components of functionality. As those citizen developers become more familiar with the business needs of the organization, opportunities to reuse those components in other applications may arise.

To create reusable built-on applications and components from citizen developer built applications, first, identify the reusable components. Then, refactor the appropriate rules from the existing application into your new reusable built-on applications and components as described above. It is important to define relevant records for components, not just applications, to simplify and encourage their use.