Specialization and component applications

When considering approaches to application specialization, think of applications as components rather than as frameworks. Components are part of a whole, like the wheels or the engine of a car. In contrast, a framework describes the essential, static structure, like the chassis of a vehicle.

When you use applications as components, you can take a modular approach to application configuration. You can define an application by composing it of multiple component applications. 

Do not confuse a component application with a component that is a collection of rulesets used to create a small feature that can be added to any Pega Platform™ application.

You can design Pega applications specifically for use as components. By definition, a component is recursive. A component can comprise other components in the same way that objects can comprise other objects. An application satisfies this definition since an application can be built-on on multiple applications.

The term component implies that an object has a stable interface and can be tested separately according to published specifications. A component application need not contain its own unit test rulesets, but it can temporarily develop during development. Before deployment, unit test rulesets are moved to a test-only application built on the component application.

Similarly, the test data entry stage of a case type within a component application can be configured as valid only for self-testing and used to provide the test data for the remaining stages. It can be avoided by a when rule defined as “when the case is not covered” if the case type is only used as a subcase in production. When a production application extends a case type within the component application that includes a test-only stage, the production application is free to remove that stage from its case type rule. 

Pega component applications follow the object-oriented programming (OOP) open/closed principle. This principle states that an object does not need to be changed to support its use by other objects. Also, objects need not change if additional features are added to the user object; this avoids maintenance-intensive ripple effects when new code is added to support new requirements.  

According to the Template Design Pattern used by Pega Platform, modeling a business process follows the open/closed principle. You define a foundation algorithm in a base class. The derived classes implement code at allowed extension points.

Using built-on applications breaks up common and stand-alone components into their applications. This modular design approach lets you point an application to another application rule. As a result, changes to any required rulesets and versions across applications are more easily managed. The use of multiple built-on applications also eliminates the need to use ruleset prerequisites. Instead, you can use Application Validation mode to avoid warnings related to the use of rulesets that are located across multiple applications.

Use built-on component applications to modularize functionality and promote reuse. Built-on applications encourage the use of Application Validation mode over ruleset prerequisites. Warnings related to the use of the same ruleset across applications are avoided.

For more information about how Pega Platform processes various hierarchical structures of multiple built-on applications at design time, see the following Pega Community article and Tech Talks. 

• Using multiple built-on applications
• Application stack hierarchy for multiple built-on applications
• Multiple built-on applications