Scribd
Upload
26 views

Class Structures and Heirarchy

The document discusses class structures and hierarchies in Pega. It covers principles of reusability and layered design frameworks. It also describes organizational structures, access groups, class inheritance models, and units of work in Pega.

Uploaded by

raghu_534
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
26 views

Class Structures and Heirarchy

The document discusses class structures and hierarchies in Pega. It covers principles of reusability and layered design frameworks. It also describes organizational structures, access groups, class inheritance models, and units of work in Pega.

Uploaded by

raghu_534
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

Class Structures and Hierarchy

Reusability and Hierarchy Design

Reusability in software is the ability to take a module or component from one system and apply it to
another system. Reusuable components abide by the DRY (Don't repeat yourself) principle and ensure
applications are efficiently built saving time and effort in development and testing. Reusability can be
classified into the types: application (reusable components within an application that can be implemented
across business units) and enterprise (reusable components that can span multiple applications).

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 provides common functionality which can
be reused across multiple applications and is extended by a concrete implementation layer which involves
application specific features. This methodology is adopted because it promotes reusability and is a
structured means of designing scalable, robust applications.

In detail, 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. Generalised application layer: a generic base application employed as a framework for the actual
application
4. Organisational and specialised application layer: the actual application
Reusability decreases as rules are saved to lower layers.

The general rule of thumb is to have enough layers to clearly group levels of reuse without introducing
unnecessary levels of complexity.

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:WorkUsergiving 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  and DebCredit: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 the pyDefault model of the work class with the property .pyWorkIDPrefix.

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

You might also like