Application structure

Any application can be built on other applications. Any application can leverage components. An application can be specialized in multiple ways, such as using class inheritance, ruleset overriding, or, to a limited extent, circumstancing. Pattern inheritance can be used for class specialization within an application. Direct inheritance can be used for class specialization from between a higher-layer application and a lower-layer application.

Everything described above is subsumed by the term “modular architecture.” By now, there is no longer any debate on what application structure approach should be used. The only debate today is how modular the application’s modular structure should be defined. The structure definition begins with the application itself before searching downward to identify dependencies. Dependencies define what underlying applications or components must preexist before an application can be deployed to another system.

In the Application wizard tab, any application can “advertise” itself as a reusable application on which other applications can be built. A component, by definition, is designed to be used by multiple applications. The New Application wizard tool is just that — a tool that has a long history dating back to when a framework application was the only built-on option available. Pega initially supplied the option to generate both a framework and implementation application simultaneously.

When creating an application, the New Application wizard begins by asking what type of application you want to create.

If you select an application other than a core Pega-provided application, for example you select the ORG/Enterprise application, Pega assumes you may want to import case types from that application into the application being generated. If you do not want to import any of the selected application’s case types, if any, you can clear the Include all case types check box, or you can individually clear case types that you do not want to import.

If you choose a Pega-owned application such as Cosmos or Classic, the New Application wizard behaves differently. Unless generating a quick demo application, always click Advanced configuration to specify the ORG and the APP portion of the new application’s [Work/Data/Int] class name prefix.

By default, an implementation application is generated. The generated application contains four rulesets, two for the ORG and two for the APP. These generated rulesets have developed classes that establish the initial Enterprise Class Structure, or ECS for short.

In the Advanced configuration, is an option to choose either Framework or Implementation. If Framework is selected, the New Application wizard generates rulesets that end in FW and contain classes with an ORG-FW-APP prefix.

The use of this Framework option has fallen out of favor when Pega initiated support for multiple built-on (MBO) applications as of version 7.2.2. Only when it is known at the start of a project that a business has expressed a desire to leverage a framework application is this option be selected.

The Framework option must not be chosen purely for the sake of future-proofing. Extra effort is required to build and maintain a framework application. The additional time and effort required to develop a framework application cannot be justified without clear evidence for its need.

If you choose to build on an application other than a core Pega-provided application, you eventually come to the same name-the-application screen that contains the Advanced configuration link. Any case type selected for import is directly inherited by a generated case type of the same name. The work pool class within the to-be-generated application also directly inherits the work pool class within the selected built-on application. You can change this afterward to have the generated work pool class extend Work-Cover- instead,

An application is an object; case types are objects. Each has different concerns. An application owns the Work/Data classes within its ruleset. Case types should be associated with a ruleset that is different from the application’s ruleset. A case type that has the potential to be converted to a (yet-to-be-defined) component application should be created in a case type-specific ruleset. Avoid creating dependencies between case types and rules defined within an application's work pool class. Do not create a rule within an application’s work pool class simply because two different case types utilize a rule with the same name and type, a field group property for example. Views can be defined against the field group's Data class. Both case types can reuse that View.

The New Application wizard always includes two ORG rulesets within the applications that it generates. The ORG rulesets are configured to use Ruleset Validation mode as opposed to Application Validation mode.

It is a straightforward process to place the two ORG ruleset into a separate Enterprise application. The Enterprise application's Application rule's associated ruleset should be the ORG ruleset. A ClassGroup record can be created the ORG class since the ORG class extends Work-Cover-. An ORG-UIPages class that extends Data-Portal can be created, then used as the Enterprise application's Application rule's UI class.

The reason for creating a separate Enterprise application is so that it can be treated the same as every other application in terms of deployment. For example, the Enterprise application might have its own DevOps pipeline, albeit one that does not continue all the way to the production environment.

Different versions of the Enterprise application can be defined based on the version of PegaRULES application the Enterprise application is built on. Likewise, a application that is a built-on Enterprise application can declare that it is dependent on a certain version of that Enterprise application.