PEGA (PRCP) Class Structure

PEGA PRPC Class Structure

PEGA Basic Class Structures and Hierarchy 

Hierarchy  and Reusability of class Design

In software trends Re-usability  is the ability to take a module or component from one system and apply it to another system. Reusable components abide by the DRY (Don't repeat yourself) principle and ensure applications are efficiently built saving time and effort in development and testing. 

Pega promotes application design which employs a framework layer as the foundation of an application with an implementation layer built on top. The framework layer majorly provides common functionality which can be reused across multiple applications and is extended by a concrete implementation layer which involves application specific features. In this methodology is adopted because it promotes re-usability and is a structured means of designing scalable, robust applications.

More detail about, the best practice for PRPC class structure design involves implementing a class design which consists of four layers:

1.             PRPC shared product: the Pega layer which contains all Pega OOTB rules and functionality

2.             Enterprise shared product layer: extensions to the Pega OOTB functionality which is used across applications

3.             Generalized application layer: a generic base application employed as a framework for the actual application

4.             Organisational and specialized application layer: the actual application

Reusability decreases as rules are saved to lower layers.

 The key building blocks making up an organisational structure in Pega consists of organisations, divisions and business units. These building blocks provide a basis of describing the access model of application users and need not map directly to the HR organisational chart.
An efficient method of designing an organisation structure in Pega involves dividing users into functional groups based on what the user does.
Access groups is Pega terminology for grouping users to various applications with various levels of access. An access group can be associated to an organisation, division, business unit or individual with each level of specialisation overriding the broader group.
For example, a Larry is a manager at ABank in the Finance division, working in the Accounts business unit. ABank has the access group ABank:WorkUser giving all ABank employees access to the bank's portal. Finance employees also have the access group TradeMore:WorkUser and the Accounts business unit has the access group DebCredit:WorkUser. Since Larry is a manager he is also part of the access group DebCredit:WorkManager.
Thus, Larry is part of the following access groups overall: ABank:WorkUser, TradeMore:WorkUser andDebCredit:WorkManager.
Note: the Accounts access group DebCredit:WorkUser was overridden by Larry's specific DebCredit access group DebCredit:WorkManager.


The Pega rule hierarchy begins at the top class @baseclass which is extended by several base classes:

·                     Rule- concrete subclasses hold rules

·                     Data- concrete subclasses hold data

·                     Assign- assignments i.e. steps of the workflow

·                     Code- references in-memory server code

·                     Embed- outlines structure of pages embedded in pages
When determining whether a data instance should derive from Data- or Embed- if the class will never be a top-level page or a saved object (as opposed to being a saving an object with embedded objects) then define the instance under Embed-

·                     History- stores the history of objects

·                     Index- secondary access keys to improve retrieval performance

·                     Link- records relationships/associations between objects

·                     Log- for logging system events

·                     PegaAccel- supports the Application Accelerator tool

·                     System- for system settings and status

·                     Work- work objects, covers and folders

 Classes and Class Groups/Work Pools

Classes in Pega are a way of grouping rules and providing structure.

Classes can be:

·                     abstract: groups reusable rules and is an instance of Rule-Obj-Class (name always ends in a hyphen e.g. MyClass-)

·                     concrete: can be instantiated and inherits rules from parent classes

Class groups are used to define work pools (a collection of work types or classes). They map to a physical database table and contain a unique identifier which links to the table's primary key.

All class groups must directly inherit from Work-

The Work- class provides several key features for work pools:

·                     rules for class groups and work objects e.g. pyStatus, pyDefault, New

·                     sample rules e.g. SLA

·                     rules used as stubs e.g. NewDefaults

Pega implements a dual inheritance model which consists of pattern and directed inheritance. 

·                     Pattern inheritance involves inheritance based on the pattern of the ruleset name e.g. MyClass-Child is the subclass of MyClass-. When applied, pattern inheritance takes precedence over directed inheritance.

·                     Directed inheritance is dependent on what the developer explicitly specifies as the class' parent class

Units of Work

All work classes inherit from the base class Work-. There are three main subclasses of Work-:

·                     Work-Object-

·                     Work-Cover-

·                     Work-Folder-

All work classes contain a unique ID pyID which is usually in the form - e.g. AA-10. The pyID prefix is defined in thepyDefault model of the work class with the property .pyWorkIDPrefix.

The current work object is stored on the clipboard under pyWorkPage.

Layers in the generated class structure

The layers depicted in the enterprise class structure image are:

Layer	Purpose
Enterprise Reuse	For 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 Reuse	For assets that need to be reused on a division-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.
Framework	Defines 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.
Implementation	Defines 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 Product	Consists 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

Class	RuleSet	Parent Class (Directed)
		6.1+	6.2+
MyCo-	MyCo	Work-	Work-Cover-
MyCo-FW-	MyCo	Work-	Work-Cover-
MyCo-Data-	MyCo	Data-	Data- (same as 6.1+)
MyCo-Int-	MyCoInt	Data-	Data- (same as 6.1+)
MyCo-Div1-	MyCoDiv1	Work-	Work-Cover-
MyCo-Div1-Data-	MyCoDiv1	Data-	Data- (same as 6.1+)
MyCo-Div1-Int-	MyCoDiv1Int	Data-	Data- (same as 6.1+)
MyCo-FW-FrameworkName1-	FrameworkName1	Work-	Work-Cover-
MyCo-FW-FrameworkName1-Work	FrameworkName1	Work-	Work-Cover-
MyCo-FW-FrameworkName1-Work-Type1	FrameworkName1	Work-Object-	Work-Cover-
MyCo-FW-FrameworkName1-Work-Type2	FrameworkName1	Work-Object-	Work-Cover-
MyCo-FW-FrameworkName1-Data-	FrameworkName1	Data-	Data- (same as 6.1+)
MyCo-FW-FrameworkName1-Int-	FrameworkName1Int	Data-	Data- (same as 6.1+)
MyCo-Div1-Implementation1-	MyCoImplementation1	Work-	Work-Cover-
MyCo-Div1-Implementation1-Work	MyCoImplementation1	MyCo-FW-FrameworkName1-Work	MyCo-FW-FrameworkName1-Work (same as 6.1+)
MyCo-Div1-Implementation1-Work-Type1	MyCoImplementation1	MyCo-FW-FrameworkName1-Work-Type1	MyCo-FW-FrameworkName1-Work-Type1 (same as 6.1+)
MyCo-Div1-Implementation1-Work-Type2	MyCoImplementation1	MyCo-FW-FrameworkName1-Work-Type2	MyCo-FW-FrameworkName1-Work-Type2 (same as 6.1+)
MyCo-Div1-Implementation1-Data-	MyCoImplementation1	Data-	Data- (same as 6.1+)
MyCo-Div1-Implementation1-Int-	MyCoImplementation1Int	Data-	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 ofWork- (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 FrameworkName1IntRuleSet includes the MyCo RuleSet as an additional prerequisite.

RuleSet	Prerequisite RuleSets
	6.1+, 6.2 GA, and 6.2 SP1	6.2 SP2
MyCo	MyCoInt	MyCoInt
MyCoInt	Pega-ProcessCommander	Pega-ProcessCommander
MyCoDiv1	MyCo MyCoDiv1Int	MyCo MyCoDiv1Int
MyCoDiv1Int	MyCoInt	MyCoInt
FrameworkName1	Pega-ProcessCommander FrameworkName1Int	Pega-ProcessCommander FrameworkName1Int
FrameworkName1Int	Pega-ProcessCommander	Pega-ProcessCommander MyCo
MyCoImplementation1	FrameworkName1 MyCoDiv1 MyCoImplementation1Int	FrameworkName1 MyCoDiv1 MyCoImplementation1Int
MyCoImplementation1Int	FrameworkName1Int 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:

Field	Input value	Description
Organization	GLBX.com	Official name of the organization/company using the application. (The organization name is typically based on the four-character stock ticker of the company.)
Division	HR	Division using this particular sliver/implementation
Framework	OnboardingFW	Name 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.
Implementation	Equipment	Name for this particular sliver/implementation, because it handles requests for equipment (computer, workspace area) for Globex's new hires
Case type (1)	Workspace Request	Case 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 Request	Case 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

Class	RuleSet	Parent Class (Directed)
GLBX-	GLBX	Work-Cover-
GLBX-FW-	GLBX	Work-Cover-
GLBX-Data-	GLBX	Data-
GLBX-Int-	GLBXInt	Data-
GLBX-HR-	GLBXHR	Work-Cover-
GLBX-HR-Data-	GLBXHR	Data-
GLBX-HR-Int-	GLBXHRInt	Data-
GLBX-FW-OnboardingFW-	OnboardingFW	Work-Cover-
GLBX-FW-OnboardingFW-Work	OnboardingFW	Work-Cover-
GLBX-FW-OnboardingFW-Work-ComputerRequest	OnboardingFW	Work-Cover-
GLBX-FW-OnboardingFW-Work-WorkspaceRequest	OnboardingFW	Work-Cover-
GLBX-FW-OnboardingFW-Data-	OnboardingFW	Data-
GLBX-FW-OnboardingFW-Int-	OnboardingFWInt	Data-
GLBX-HR-Equipment-	GLBXEquipment	Work-Cover-
GLBX-HR-Equipment-Work	GLBXEquipment	GLBX-FW-OnboardingFW-Work
GLBX-HR-Equipment-Work-ComputerRequest	GLBXEquipment	GLBX-FW-OnboardingFW-Work-ComputerRequest
GLBX-HR-Equipment-Work-WorkspaceRequest	GLBXEquipment	GLBX-FW-OnboardingFW-Work-WorkspaceRequest
GLBX-HR-Equipment-Data-	GLBXEquipment	Data-
GLBX-HR-Equipment-Int-	GLBXEquipmentInt	Data-

Generated RuleSets

RuleSet	Prerequisite RuleSets
GLBX	GLBXInt
GLBXInt	Pega-ProcessCommander
GLBXHR	GLBX GLBXHRInt
GLBXHRInt	GLBXInt
OnboardingFW	Pega-ProcessCommander OnboardingFWInt
OnboardingFWInt	Pega-ProcessCommander GLBX
GLBXEquipment	OnboardingFW GLBXHR GLBXEquipmentInt
GLBXEquipmentInt	OnboardingFWInt 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.