Application structure
By now, there is no debate about which application structure approach to use: modular architecture or framework/implementation architecture. The only debate today is how modular the application's modular structure should be. Applications can be hosted on the same database or distributed across multiple databases.
On the Application wizard tab of a Rule-Application rule form, you can promote an application as a reusable application on which to build other applications can.
A component, by definition, is designed to be reused by multiple applications. You can promote components in Dev Studio by clicking Configure > Application > Components. It is also possible to add a component to a component.
The Rule-Application rule form includes rulesets; every rule for an application can go into the same ruleset. However, that method is contrary to the best practice of keeping code organized, and the PegaRULES application maintains the organization of code. There are 55 rulesets as of Pega Platform™ version 8.8.
Organized rulesets contain purpose-related classes, which is the same principle you use when defining a component. PegaRULES has rulesets for UI, process management, the rule engine, and more.
In applications that use PegaRULES, you can organize rulesets by their primary concern. An application is an object, and a case type is a different object, each with different concerns.
An application owns the Work and Data classes in the ruleset that shares its name. You can create case types in their own ruleset by using Dev Studio. Then, the system adds the rules created in App Studio to the ruleset of the case type.
Avoid creating dependencies between the work pool class and case types of an application because their concerns are not the same. 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. You might decide later that a different application should own the case type.
Views defined at the data type level allow different case types to reuse those views. Each case type can then define its own view that incorporates a view of a data type. Cases types have less coupling to their current application when they use data type views that are defined in a layer that is under the current application.
The New Application wizard
The New Application wizard allows one application-type choice, framework or implementation application, to be made at a time,. Implementation is the default choice.
Avoid choosing the Framework option for the sake of future-proofing. Extra effort is required to build and maintain a framework application. That additional time cannot be justified without clear evidence of why a monolithic framework layer is necessary.
The Implementation option is the default option. It is the best option unless the business requests a framework application.
The New Application wizard generates the following new items:
- Work, Data, Int, Link, and UIPages classes.
- Class group and Data-Admin-DB-Table for the work pool class.
- APP and APPint rulesets.
When you run the New Application wizard, if the ORG that you specify does not exist, the system generates a Data-Admin-Organization record and ORG and ORGInt rulesets.
A generated application always contains ORG and ORGInt rulesets; those rulesets use the Ruleset validation (RV) mode instead of the Application validation (AV) mode.
The New Application wizard establishes the initial Enterprise Class Structure (ECS) for the application but also creates a new work pool whether or not it is required.
Because the New Application wizard always generates ORG and ORGInt rulesets for each application, these rulesets can add complexity and redundancy. Enterprise centers of excellence (COEs) typically want to maintain control over which ORG ruleset versions other applications can use. If what is placed in the ORG ruleset is limited to data types only, the concern is not so great. Additionally, App Studio users should be allowed to create applications independently.
An Enterprise COE can still create different versions of an Enterprise application, locking it down whenever a new version is published. Applications created in App Studio can easily be converted to a built-on Enterprise application, at the same time removing the ORG and ORGInt rulesets.
Work pool-less applications
Certain types of applications having a work pool class would run counter to their purpose. Two such types of applications are:
- Applications that are part of the Enterprise ORG/Div/Unit hierarchy.
- Center-out applications that support multiple external organizations.
Enterprise applications
As a best practice, when you create a new application for a new ORG, create a DevOnly application. Save that DevOnly application to the generated ORG ruleset naming it ORG, change the associated ruleset of the application to ORG, then remove the DevOnly and DevOnlyInt rulesets from that ORG application.
Create a class group for the ORG class. You can create a class group record for the ORG class because the ORG class extends Work-Cover-. You can also create an ORG-UIPages class that extends Data-Portal. Name that class as the UI class of the ORG application. Then, make other configurations to save the ORG Rule-Application rule, such as changing the skin rule or assigning a new alias. Finally, on the Application Wizard tab, promote the ORG application as one that can be built on.
A separate Enterprise application where every ruleset is set to Application Validation Mode makes it the same as every other application with regard to version management. An Enterprise application can have its own DevOps pipeline; however, that pipeline cannot continue to the production environment.
Versionable Enterprise applications, built on different PegaRULES application versions, support flexibility. Manageability is less complex compared to ORG rulesets being present in every application. The same logic applies to higher-layer applications built on Enterprise applications.
Center-out, multiple-external-organization applications
An application suite can behave the same way for multiple external organizations while allowing each external organization application to change its appearance, plus support connectivity to JSON-mappable REST services that each external organization provides.
JSON-mappable means that the data model for every external organization REST service must be one-for-one mappable to the core data model of the application in the "center." Another term for one-for-one mappable is "bijective."
When the center-out approach is used, a Rule-Application rule unique to each external organization would exist. That Rule-Application rule allows the system to reference a different skin rule and a pair of external-organization-unique APP rulesets. One of the two rulesets referenced by the external organization Rule-Application rule, its APP ruleset, is used to override the Work, Data, Link, and UIPages rules beneath that application. The second of two rulesets referenced by the external organization Rule-Application rule, its APPInt ruleset, is used to integrate with JSON-mappable REST services hosted by the external organization.
Each external organization would host web pages that embed content produced by the center-out Pega application. Each external organization would define its own Web Embed interface styled and branded as the external organization wants. The URL associated to an external organization-unique Web Embed interface would invoke an external organization-unique authentication service. The access group associated to that authentication service would point to the external organization's unique Rule-Application rule.
Check your knowledge with the following interaction:
This Topic is available in the following Module:
Want to help us improve this content?