Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Understanding the Class structure and RuleSets generated by the Application Accelerator

Updated on June 10, 2020

Summary

The Application Accelerator generates an initial layered enterprise class structure and multiple RuleSets, based upon the input values you provide (and default values). This article presents:

  • The layers, classes, and RuleSets created by the Application Accelerator for PRPC 6.1+ and 6.2+.
  • Descriptions of the purpose of each layer
  • An example scenario that illustrates the relationship between the values you enter into the Application Accelerator and the resulting generated enterprise class structure and RuleSets. The example scenario is similar to the business scenario described in the Building your first application tutorial.
The generated structure and RuleSets described in this article are for the following PRPC releases: PRPC 6.1+ (GA, SP1, and SP2) and PRPC 6.2+ (GA, SP1, and SP2).

Suggested Approach

Quick links

Generated enterprise class structure

Two large diagrams depict the layers and classes in the enterprise class structure generated by the Application Accelerator. Click to open a diagram in a new window:

   PRPC 6.1+:
   class structure diagram
   PRPC 6.2+:
   class structure diagram

This class structure enables multiple PRPC applications within the same system to co-exist, and supports effective reuse among the applications. For each PRPC release, the generated structure reflects best practices available in that release.

 

Layers in the generated class structure

The layers depicted in the enterprise class structure image are:

LayerPurpose
Enterprise ReuseFor assets that need to be reused on an enterprise-wide basis. Such assets are rules for enterprise-wide business logic (such as standard properties, decision tables, Service Level rules) and enterprise-wide data assets (such as classes and rules for data stored in the system, and classes and rules for access to data in external systems, via connectors).

For example, the MyCo enterprise wants to reuse the property that holds an employee's serial number on an enterprise-wide basis, so that the various applications used by that employee across the enterprise can consistently rely on the same serial number property for the same employee.

Divisional ReuseFor assets that need to be reused on adivision-wide basis. Such assets are rules for division-wide business logic (such as standard properties, decision tables, Service Level rules) and division-wide data assets (such as classes and rules for data stored in the system, and classes and rules for access to data in external systems, via connectors).

For example, a division wants to reuse a service level rule that defines the expected response time to a customer complaint in all of its applications, so that it can consistently enforce a focus on meeting its customer relationship commitments.

FrameworkDefines a common work-processing foundation that is extended by the specific implementations.

For example, the MyCo enterprise makes auto loans, and has an auto loan framework that is comprised of all of the assets needed for MyCo's standard auto loan process. Each division of MyCo extends that basic auto loan application to meet their specific divisional needs: the commercial business line division's auto loan application needs to handle loan requests distinct from that of MyCo's personal line division.

ImplementationDefines an implementation of a framework that is customized for a specific division.

For example, the commercial business line's auto loan application reuses assets from the commercial business line division layer and from the auto loan framework layer, while the personal line's auto loan application reuses assets from the personal line division layer and the auto loan framework layer.

PRPC Base ProductConsists of the PRPC system's built-in classes and rules necessary for processing cases and other work in PRPC applications, as well as for areas of PRPC itself.

Using the same names that are depicted in the diagrams, the tables below illustrate the classes and RuleSets generated by the Application Accelerator for an organization called "MyCo", and demonstrate where the division, framework, implementation, and case/work type names are used in the class and RuleSet names.

Generated classes

ClassRuleSetParent Class (Directed)
6.1+6.2+
MyCo-MyCoWork-Work-Cover-
MyCo-FW-MyCoWork-Work-Cover-
MyCo-Data-MyCoData-Data- (same as 6.1+)
MyCo-Int-MyCoIntData-Data- (same as 6.1+)
    
MyCo-Div1-MyCoDiv1Work-Work-Cover-
MyCo-Div1-Data-MyCoDiv1Data-Data- (same as 6.1+)
MyCo-Div1-Int-MyCoDiv1IntData-Data- (same as 6.1+)
    
MyCo-FW-FrameworkName1-FrameworkName1Work-Work-Cover-
MyCo-FW-FrameworkName1-WorkFrameworkName1Work-Work-Cover-
MyCo-FW-FrameworkName1-Work-Type1FrameworkName1Work-Object-Work-Cover-
MyCo-FW-FrameworkName1-Work-Type2FrameworkName1Work-Object-Work-Cover-
MyCo-FW-FrameworkName1-Data-FrameworkName1Data-Data- (same as 6.1+)
MyCo-FW-FrameworkName1-Int-FrameworkName1IntData-Data- (same as 6.1+)
    
MyCo-Div1-Implementation1-MyCoImplementation1Work-Work-Cover-
MyCo-Div1-Implementation1-WorkMyCoImplementation1MyCo-FW-FrameworkName1-WorkMyCo-FW-FrameworkName1-Work (same as 6.1+)
MyCo-Div1-Implementation1-Work-Type1MyCoImplementation1MyCo-FW-FrameworkName1-Work-Type1MyCo-FW-FrameworkName1-Work-Type1 (same as 6.1+)
MyCo-Div1-Implementation1-Work-Type2MyCoImplementation1MyCo-FW-FrameworkName1-Work-Type2MyCo-FW-FrameworkName1-Work-Type2 (same as 6.1+)
MyCo-Div1-Implementation1-Data-MyCoImplementation1Data-Data- (same as 6.1+)
MyCo-Div1-Implementation1-Int-MyCoImplementation1IntData-Data- (same as 6.1+)
NOTES:
  • Extending from Work-Cover- (not just Work-) is required for applications that leverage case management features. In PRPC 6.1+, the Application Accelerator provides an option to select Work-Cover- for a work type. For example, if that selection was made for the Type1 work type listed in the above table, the direct parent of the generated MyCo-FW-FrameworkName1-Work-Type1 class would be Work-Cover- instead of Work-Object-. In PRPC 6.2+, extending from Work-Cover- is the default (as indicated in the table) to make it easier for all newly generated applications to leverage case management.
  • Each layer's Data- and Int- classes typically represent containers that stand by themselves and store data and interface classes used at that layer. It is rare to want the system to use class inheritance to reuse a data asset (for example, to reuse data classes from MyCo-Data- for data classes in MyCo-Div1-Implementation1-Data-). However, if your application requires extending from the organizational layers' Data- or Int- classes, modify the class rule for the framework or implementation class to set the needed directed parent class.
  • When you create a new organization by running the Application Accelerator, the top-level class has a directed parent class of Work- (for PRPC 6.1+ systems) or Work-Cover- (for PRPC 6.2+ systems). However, when you create a new organization directly using the Organization Setup wizard instead, that wizard generates a top-level class (such as MyCo) with a directed parent class of @baseclass. If you create a new organization using the Organization Setup wizard and want to reuse that organization when running the Application Accelerator, update the top-level class's inheritance (by manually updating the Parent class field in the class's rule form) to use the appropriate directed parent Work class, as shown in the preceding table.

Generated RuleSets

The only difference between the generated RuleSets for PRPC 6.1 and 6.2 is that in 6.2 SP2, the FrameworkName1Int RuleSet includes the MyCo RuleSet as an additional prerequisite.
RuleSetPrerequisite RuleSets
6.1+, 6.2 GA, and 6.2 SP16.2 SP2
MyCoMyCoIntMyCoInt
MyCoIntPega-ProcessCommanderPega-ProcessCommander
MyCoDiv1MyCo
MyCoDiv1Int
MyCo
MyCoDiv1Int
MyCoDiv1IntMyCoIntMyCoInt
FrameworkName1Pega-ProcessCommander
FrameworkName1Int
Pega-ProcessCommander
FrameworkName1Int
FrameworkName1IntPega-ProcessCommanderPega-ProcessCommander
MyCo
MyCoImplementation1FrameworkName1
MyCoDiv1
MyCoImplementation1Int
FrameworkName1
MyCoDiv1
MyCoImplementation1Int
MyCoImplementation1IntFrameworkName1Int
MyCoDiv1Int
FrameworkName1Int
MyCoDiv1Int
NOTES:
  • In PRPC 6.2 SP2, the enterprise reuse RuleSet (MyCo) is included as a prerequisite RuleSet for the generated frameworkInt RuleSet. This provides support for the best practice of storing common rules at the enterprise level, because it gives the ability to reference those common rules from rules in the framework-level RuleSets.
  • When you create a new organization directly using the Organization Setup wizard rather than the Application Accelerator, the wizard generates the organization RuleSet (such as MyCo) with a prerequisite of Pega-ProcessCommander. If you create a new organization using the Organization Setup wizard and then reuse that organization when running the Application Accelerator, update the organization RuleSet to include the generated orgInt RuleSet as a prerequisite after it is created by the Application Accelerator.

Globex company scenario

This scenario describes Application Explorer inputs and results in PRPC 6.2 SP2.

In this example scenario, the Globex company has just deployed PRPC 6.2 SP2 for the first time within the company. Globex's IT department installed PRPC.

So that Globex's business analysts can log in and create the first application profile for the initial sliver of their first PRPC-based project, the IT department has created a temporary organization name TEMP.com using the Organization Setup wizard, and then created operator IDs for the business analysts. (The official organization is created when the project team is ready to generate the first application.)

The overarching goal envisioned by the company is to automate and manage all of the Globex's processes involved in onboarding a newly hired employee. The first "sliver" that the team will implement is the sliver that handles requests and approvals for purchasing computer equipment and setting up workspace items for a new hire (Equipment). The HR division is the first division that will use this sliver, and there are two case types: Workspace Request and Computer Request.

The business analysts have logged into the system and used the Application Profiler to capture the case types, processes, specifications, and requirements for this first sliver. These inputs are captured in the Onboarding Version 1 - AP-1 application profile. The team is ready to use the Application Accelerator to generate the application structure based on this application profile.

Inputs to the Application Accelerator

Based on the goals of this sliver, the team uses the following values in the Application Accelerator:

FieldInput valueDescription
OrganizationGLBX.comOfficial name of the organization/company using the application. (The organization name is typically based on the four-character stock ticker of the company.)
DivisionHRDivision using this particular sliver/implementation
FrameworkOnboardingFWName for the base framework on which future slivers/implementations will be built, like those to handle work requests for Globex's new hires (such as Benefits, Payroll, etc.). The FW portion of the name indicates it is a framework.
ImplementationEquipmentName for this particular sliver/implementation, because it handles requests for equipment (computer, workspace area) for Globex's new hires
Case type (1)Workspace RequestCase type for requests of workspace items, such as cubicle location, desk, file cabinets, white boards, etc. (Specified in the application profile.)
Case type (2)Computer RequestCase type for requests of computer equipment, such as laptop, monitor, printer, keyboard, etc. (Specified in the application profile.)

A system architect starts the Application Accelerator, and in the Application Overview window, chooses the application profile the team created. To generate the application structure that supports both the framework and the equipment setup sliver, the system architect specifies a framework named OnboardingFW and an implementation named Equipment in the Application Overview window.

On the Base and RuleSets step of the Application Accelerator, the system architect replaces the displayed default organization and division values with the official ones: GLBX.com and HR, and keeps the default class structure of Standard. The displayed values refresh to reflect the input values:

Clicking Preview displays the enterprise class structure that will be generated by the Application Accelerator given those input values:

Globex example: Generated enterprise classes and RuleSets

When the application is generated by the Application Accelerator in PRPC 6.2 SP2:

  • Classes are created in the system, with names based on the input values.
  • RuleSets are created. The class rules are stored in those RuleSets.
  • The classes have directed parent classes according to the pattern shown in the following table (based on the Globex scenario).
Generated classes
ClassRuleSetParent Class (Directed)
GLBX-GLBXWork-Cover-
GLBX-FW-GLBXWork-Cover-
GLBX-Data-GLBXData-
GLBX-Int-GLBXIntData-
   
GLBX-HR-GLBXHRWork-Cover-
GLBX-HR-Data-GLBXHRData-
GLBX-HR-Int-GLBXHRIntData-
   
GLBX-FW-OnboardingFW-OnboardingFWWork-Cover-
GLBX-FW-OnboardingFW-WorkOnboardingFWWork-Cover-
GLBX-FW-OnboardingFW-Work-ComputerRequestOnboardingFWWork-Cover-
GLBX-FW-OnboardingFW-Work-WorkspaceRequestOnboardingFWWork-Cover-
GLBX-FW-OnboardingFW-Data-OnboardingFWData-
GLBX-FW-OnboardingFW-Int-OnboardingFWIntData-
   
GLBX-HR-Equipment-GLBXEquipmentWork-Cover-
GLBX-HR-Equipment-WorkGLBXEquipmentGLBX-FW-OnboardingFW-Work
GLBX-HR-Equipment-Work-ComputerRequestGLBXEquipmentGLBX-FW-OnboardingFW-Work-ComputerRequest
GLBX-HR-Equipment-Work-WorkspaceRequestGLBXEquipmentGLBX-FW-OnboardingFW-Work-WorkspaceRequest
GLBX-HR-Equipment-Data-GLBXEquipmentData-
GLBX-HR-Equipment-Int-GLBXEquipmentIntData-

Generated RuleSets

RuleSetPrerequisite RuleSets
GLBXGLBXInt
GLBXIntPega-ProcessCommander
GLBXHRGLBX
GLBXHRInt
GLBXHRIntGLBXInt
OnboardingFWPega-ProcessCommander
OnboardingFWInt
OnboardingFWIntPega-ProcessCommander
GLBX
GLBXEquipmentOnboardingFW
GLBXHR
GLBXEquipmentInt
GLBXEquipmentIntOnboardingFWInt
GLBXHRInt

Questions commonly asked about the generated class structure

Why do non-work classes, like Org-, inherit from Work- (in 6.1+) or Work-Cover- (in 6.2+)

Because of rule resolution, inheriting from Work- or Work-Cover- on those levels allows for increased sharing of case-management-related or work-related assets across multiple applications. For example, if a company creates two top-level classes for some reason (such as when two organizations do not currently work with each other and they want to develop applications independently), the applications can still share work-related assets.

Why does the Org RuleSet have the OrgInt RuleSet as a prerequisite (required) RuleSet?

So that business logic rules in the Org RuleSet have the ability to reference integration-related rules and classes stored in the OrgInt RuleSet.

Why doesn't the Application Accelerator generate MyCo-FW-FrameworkName1-Data- to directly inherit from MyCo-Data-? Why doesn't the generated MyCo-FW-FrameworkName1-Int- directly inherit from MyCo-Int-? Or for the rest of the Data- and Int- classes?

It is rare to want the system to use class inheritance to reuse a data asset (for example, to reuse data classes from MyCo-Data- for data classes in MyCo-Div1-Implementation1-Data-). However, if your application requires extending from the organizational layers' Data- or Int- classes, modify the class rule for the framework or implementation class to set the needed directed parent class.

Conclusion

This article has provided an overview of the enterprise class structure and RuleSets that are generated by the Application Accelerator, and an example illustrating the relationship between sample input values and what is generated.

 Starting with PRPC 7.1, abstract class names generated by the Application Accelerator do not contain a trailing hyphen. For example, MyCo- class would be named MyCo.
  • Previous topic Introducing PRPC 6.2 - Implementation and Methodology
  • Next topic DCO 6.2 and 6.3 - Creating Application Profiles and Discovery Maps

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us