Class Structures & Hierarchy

Design

LEVEL – PRACTITIONER
 About the Author

Created By: Rajarshi Dutta

Credential Pega CSSA and experienced PRPC developer

Information:

Version and Date: V1. Sept 16th,2014

ognizant Certified Official Curriculum

2
 Icons Used

Hands on
Questions Tools Exercise

Coding Test Your Case Study

Standards Understanding

Best Practices
Demonstration & Industry
Workshop
Standards

3
 Introduction

• Class structure design is an integral part of every Pega application. Designing a

scalable, extensible enterprise class structures from the beginning of your project
will help avoid costly re-factoring. The enterprise class structure enables PRPC
applications to co-exist with each other and with customer or Pega built
frameworks.
• The enterprise class structure is also the foundation for enterprise reuse. Asset
reuse is integral to the long-term success of BPM within the organization and
ultimately, the reusability requirements drive the selection of your class hierarchy
design.
• Careful planning and analysis are important before creating the new classes, to
understand their interrelationships and plan their positions in the standard class
hierarchy. Maximizing reuse of standard classes, standard properties, and other
standard rules is a proven tactic for fast development at minimum effort.

4
 Objectives

• Importance of a Robust Class Structure in Application development.

• Role of Class Structure in Reusability and Security
• How Inheritance works in PRPC?
• What’s difference between Abstract and Concrete Classes?
• What’s the purpose of Class Groups?
• How the Work- Class helps in work processing?

5
 Do You Know

• Object oriented programing

• Java/HTML/JS

6
 4 - Layer Class Structure

7
 Layers in the generated class structure

• 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).

8
 Layers in the generated class structure
(Contd.)

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 Layer: 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. The Framework Layer stores base
rules/processes/components for a given application. A customer built framework
(CBF) serves as the basis for N number of deployments throughout the enterprise.
Framework Layer stores base rules/processes/components for a given application. A
customer builtframework (CBF) serves as the basis for N number of deployments
throughout the enterprise.

9
 Layers in the generated class structure
(Contd.)

A CBF must be able to stand on its own; therefore, this layer contains all rules
necessary to implement its functionality. While there will be a class group and its
mapping to a database table for testing purposes, the actual mapping of the application
to production database table occurs on the Implementation layer. Organization specific
logic, processes and rules must be placed on the Implementation layer as well; only
default edits, values, and application structures have their home in the CBF layer. The
CBF and its implementation classes can be considered the equivalent of an “ASP”
model, where the CBF is the base application. Pegasystems-built frameworks also
reside in the Framework layer. A customer application that is built on a Pegasystems
solution framework may directly implement the solution framework classes, or they
may be a CBF themselves. In the former case, there are one or more specialization
layers on the Implementation level, and the Pega solution framework on the
Framework level. In the latter case, there are one or more specialization layers on the
Implementation level and the CBF and the Pega solution framework on the Framework
level. The CBF has the Pega framework as its directed parent.

10
 PRPC Solution Frameworks :with (F1) and
without (F2) a CBF

11
 Layers in the generated class structure
(Contd.)

• Implementation Layer: 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 :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.

12
 Layers in the generated class structure
(Contd.)

• NOTE: Starting with PRPC 7.1, abstract class names generated by the Application
Express do not contain a trailing hyphen. For example, MyCo- class would be
named MyCo. Extending from Work-Cover- (not just Work-) is required for
applications that leverage case management features. In PRPC V7, extending from
Work-Cover- is the default (when the class is created using application express) to
make it easier for all newly generated applications to leverage case management.

13
 A Practical Example

14
 Creating PRPC Class Structure

15
 Abstract and Concrete class

• An abstract class is a class rule created to support the definition of rules, including
other classes. Such rules can be inherited by subclasses of the abstract class. Rules
with a class as a key part (such as properties, activities, flows, models, and so on)
can apply to an abstract class. A dash or minus character (-) as the last character in
the class name indicates an abstract class.

• A concrete class can have instances stored in the database. In contrast, an abstract
class cannot have any instances. If concrete class is created with an intent to store
instances then appropriate keys needs to be defined in the class form.

16
 Class Groups

• Class groups are commonly used to cause the system to store instances of similar or
related work object concrete classes together in one relational database table. This
is also known as a work pool. It causes the system to store the instances
corresponding to two or more concrete classes that share a common key format in a
single database table.

• For rule resolution purposes (not database storage purposes) classes in the class
group can derive from (inherit rules from) the class with the same names as the
class group, but this is not required. Because of directed inheritance, classes in the
class group can inherit rules from elsewhere in the hierarchy.

17
 Pattern Inheritance

• Pattern inheritance causes the system to search for a rule in classes derived from
the current class name by truncating, from the right, alphanumeric segments that
follow a hyphen (dash) character. “Find by name first (Pattern)? “check box on
the Class rule form to instruct the system to use pattern inheritance for this class. A
dashed black arrow ( ) indicates a pattern inheritance relationship; the arrow
head identifies the pattern parent class. For example, a request for a rule in the
WalCare-Financial-Credit class causes the system to search through these classes, in
the order indicated:
• WalCare-Financial-Credit
• WalCare-Financial-
• WalCare-Financial
• WalCare-
• WalCare

18
 Directed Inheritance

• PRPC allows you to name a parent class in the class form, which is not related to the
name of this class. A solid arrow indicates a directed inheritance relationship( ).
The arrowhead identifies the class of the immediate directed parent.

• Class rule resolution algorithm

1. Search each class formed by repeatedly truncating the original class name,
identifying it to be a potential rule to be executed if the needed rule is found.
2. If the pattern search finishes without finding a rule, go back to the original
class and use directed inheritance to find the parent of the original class.
3. If the parent class identified in step 2 was searched during step 1, skip it and
skip to step 5.
4. If the parent class was not previously searched, search it. Identify to be a
potential rule to be executed if the needed rule is found.

19
 Directed Inheritance (Contd.)

5. If not found, determine whether the parent class uses pattern inheritance. If
so, repeat this algorithm, starting at step 1, with the parent class.

6. Otherwise, identify the parent of the parent. Continue at step 4.

The ultimate base class @baseclass is searched last.

20
 Pattern and Directed Inheritance

 In the Rule-Obj-Class form

pattern and directed inheritance
are configured as shown in the
diagram.

 By checking the ‘find by name

first (Pattern)’ checkbox it is
ensured that PRPC will follow
pattern inheritance first. Once
saved this cannot be unchecked.

 For directed Inheritance we can

give any class name in the field
shown. This reference can be
changed later also.

21
 Work- Class

• The Work- base class, one of fourteen standard top level abstract classes, is a
superclass to all the classes that define work objects. A work object is the
fundamental unit that records processed work in an application.
• Properties, HTML forms, and flows in the Work- class are available to support the
behavior and appearance of every type of work objects, including
• Ordinary work objects, typically belonging to the a class derived from the standard
abstract class Work-Object-
– Covers, typically belonging to a concrete class derived from the Work-Cover-
class
– Folders, typically belonging to a concrete class derived from the Work-Folder-
class
– The external key to all work objects is recorded in the pyID property, and
typically consists of an alphabetic prefix, a dash, and an arbitrary but unique
number.

22
 Work- Class (Contd.)

The external key to all work objects is recorded in the pyID property, and typically
consists of an alphabetic prefix, a dash, and an arbitrary but unique number.

23
 Inheritance Structure of Work Classes

• @baseClass
Work-
Cover-
Folder-
Object-

• When to inherit from work-object- versus work-cover-

Generally we use Work-Object- inheritance for individual work objects, if we want
to process multiple dependent work objects which are tightly coupled, covers
(work-cover-) can be used. If the work objects are not tightly coupled then we can
use Folders for resolution of multiple tasks.

24
 Creating PRPC Class Structure

Base Class: CTSTrainingBase-

It’s a Top Level Base Class
Generally an Abstract Class
Direct Inheritance: from @baseclass class

Class Group: CTSTrainingBase-CTSTraining

It’s a Class Group
Should be a Concrete Class
Direct Inheritance: from Work- class
Pattern Inheritance: CTSTrainingBase-CTSTraining

Work Class: CTSTrainingBase-CTSTraining Training

It’s a Work Class
Should be a Concrete Class
Direct Inheritance: from Work-Object- class
Pattern Inheritance: CTSTrainingBase-CTSTraining-Training

25
 PRPC Class Structure Example

Class Group Inheritance

26
 PRPC Class Structure Example (Contd.)

27
 PRPC Class Structure Example (Contd.)

Extending from Work-Cover- (not just Work-) is required for applications that leverage
case management features. In PRPC V7, extending from Work-Cover- is the default
(when the class is created using application express) to make it easier for all newly
generated applications to leverage case management.

28
 Reusability

• Reusability is the ability of PRPC to share the same instance of a rule, RuleSet,
and/or service so that it can be used by other portions of the same application
and/or other applications.

 Process Commander offers multiple facilities to promote reusability, such as

– Class Inheritance — Rules that apply to more general (higher) classes are also
available for lower (derived) classes. This is a major benefit of object-
orientation.
– A library of standard rules — Thousands of standard rules, including flows,
flow actions, properties, HTML rules, and others are available for your use.
– Subflows — Because one flow can start another, you can create common flow
rules once and call or branch to them (with the flow shape ) from multiple
other places.
– Organizational Hierarchy — Access groups are associated with both
Organizations (Data-Admin-Organization class) and Divisions (Data-Admin-
OrgDivision class).
29
 Class Structure and Reusability

• A robust class structure is the foundation of reuse throughout your application. The
PRPC recommended class structure design pattern offers flexibility in your design
and provides for more level of reuse.

• The class structure provides the first and most important layer of reuse in
PRPC due to its precedents in the rule resolution algorithm.

• The class structure provides you with a hierarchy in which rules can be
placed. The higher a rule is in the hierarchy, the more potential reuse there is.

• The key to a good class structure is that there are enough layers and classes
to hold the most fundamental levels of reuse but not too many that it
becomes cumbersome to navigate and unclear as to the intent.

30
 Examples of Reusability and Security

• An Insurance company has a division Long Term Care which is accessed by its
various line of businesses like Retail, Group etc. The top most layer is myCo-LTC-
Claims where the base rules are defined. For different LOBs there are classes like
myCo-LTC-Claims-Retail, myCo-LTC-Claims-Group, myCo-LTC-Claims-Fortis etc

• Rules that are common across all the divisions in the organization are to be defined
in the top layer (myCo-LTC-Claims) and also can be reused if any new division is
introduced later in the organization.

31
 Class Structure and Security

• Class Structures also help in applying security controls across the organization.

• It can be achieved by defining access role objects which map access roles to certain
classes. Users having those roles can then Open/modify/delete instances of that
particular class.

• Then assign these roles to the users who you want to be able to access the
functionalities defined via those classes.

32
 Class Structure and Security (Contd.)

An Rule-Access-Role-Obj rule PegaRules:User1 is created and mapped to some of the

classes as shown below. When this role is set to a certain access group, user belonging
to that access group can access these parts and others can’t.

33
 Work Id Creation

• A work object ID is the permanent, external identifier of a work object, the value of
property Work-.pyID.
• For every work object, prefix must be present whereas suffix is optional. The
standard utility activity named Work-.GenerateID uses the standard properties
pyWorkIDPrefix and pyWorkIDSuffix in its computation.
• For example, the prefix of work object Q-1432 is Q. The prefix of the work object
MORT-763-K4 is MORT. The suffix of work object is K4.
• If you don't specify a prefix, the Work-.GenerateID activity uses W as the prefix and
no suffix. The Work-Cover-.GenerateID activity uses C as the default prefix which is
specified in the models present in Work-Object- and Work-Cover- classes.
Conventionally, the F prefix identifies folder work objects.
• The internal class Data-UniqueID supports work object numbering, and ensures
that work object IDs are unique system-wide, not just within an application or
organization.

34
 Learn How - Coding Standards

• Next topic slides must have the following:

– Sample codes in adherence to the industry standard, to be provided

– You may need more than one slide for each topic. To add a slide, click New Slide
on the Insert menu, or press Ctrl+M and add a suitable slide depending upon
the content

35
 Questions

36
 Welcome Break

37
 Case Study

Case Study: Leave Management System

• The Employee Services unit of the Human Resources division of Cognizant needs an
application to track and manage all leave requests raised by its employees. This
application will allow the employees to raise two different types of leave requests –
Simple Leave Request and Special Leave Request. Employees can raise requests for
multiple leave intervals under one simple or special leave request. Leave requests
will be approved or rejected by the Project Manager or the Employee Services
Manager.
• At all times, the remaining number of leaves available for each employee will be
maintained in a Data table called the Employee Leave Records.
• An employee can raise a Simple Leave Request if the total number of days of leaves
requested does not exceed the number of leaves available to him/her. To avail
leaves beyond the available number of leaves, he/she needs to raise a Special Leave
Request.

38
 Best Practices and Industry Standards

1. Classes
• PRPC is enterprise software. Therefore, we must design applications with re-
usability and scalability in mind. As an integral part of every PRPC application the
class hierarchy is the foundation for reuse. PRPC has both pattern and directed
inheritance, mechanisms which provide superior flexibility for reuse. The best
practice Enterprise Class Structure (ECS) design pattern is the basis for divisional
and enterprise-wide reuse.
• The Best Practice is to use Enterprise Class Structure
• Avoids name space collisions and allows PRPC applications to coexist with each
other and with Pega and 3rd party frameworks;
• Allows applications to integrate with legacy systems;
• Enables you to harness the power of PRPC by taking full advantage of Rule
Resolution and rule specialization in your design;
• Helps avoid costly re-factoring;
• Is the class structure that the Enterprise Application Express generates

39
 Best Practices and Industry Standards
(Contd.)

1.1 Name:
• Start Class name with capital letters. Start Words within name with capital letters
and ensure that class name does not contain underscore.
• Example:
Good Practice:
• (1) MyCom-
• (2) MyComp-MyDiv-
• (3) MyComp-MyDiv-MyApps- etc

Bad Practice:
• (1) My_Com-
• (2) Mycomp-My_Div-
• (3) Mycomp-Mydiv-My_Apps- etc

40
 Best Practices and Industry Standards
(Contd.)

Classes represent units of work, so class names are generally nouns to distinguish them
from actions and processes
Example:
(1) MyCom-
(2) MyComp-MyDiv-
(3) MyComp-MyDiv-MyApps- etc
• Adopt logical, descriptive naming conventions for class structure
• Class names are visible labels in forms, work lists, reports, and other areas of an
application. Hence these should be self-explanatory and reflect the purpose of the
work
• Avoid class names that reflect status or action, instead of a unit of work
Example:
MyComp-MyDiv-MyApps-EmailAgent-EmailProcessing
MyComp-MyDiv-MyApps-EmailAgent-ReplyStatus

41
 Best Practices and Industry Standards
(Contd.)

• Choose class names that support pattern inheritance, as well as directed

inheritance
Example:
Refer to point above

• Related objects should be named similarly, with consistent prefixes, for quickly
locating similar classes in an alphabetical list.
• By convention, abstract class names end with a dash, while concrete class names
don’t
• Indicate class behavior by self-explanatory name whether it’s a work object, a cover,
or a folder
• Example: The RulePro sample application has PegaRP-Work-Object- (parent class
for work objects) and PegaRP-Work-Project- (parent class for covers)

42
 Best Practices and Industry Standards
(Contd.)

• To distinguish hierarchy position and inheritance, use class names that visually
reflect pattern inheritance. Subclasses should include the names of all parent
classes (including your top-level class), separated by dashes.

• Example: If the parent class YourCoLoan-Request- has child classes for mortgage
and car loan applications, name them YourCoLoan-Request-Mortgage- and
YourCoLoan-Request-Auto-

1.2 Do not create Base Classes:

• In general, do not create base-level classes (i.e., classes such as Work-, Rule-, Data-
and Assign- whose names don’t start with the name of an existing “parent” class)

43
 Source

• http.pdn.pega.com
• Developer help available with PRPC 7.1.4

Disclaimer: Parts of the content of this course is based on the materials available from the Web sites and books
listed above. The materials that can be accessed from linked sites are not maintained by Cognizant Academy and
we are not responsible for the contents thereof. All trademarks, service marks, and trade names in this course are
the marks of the respective owner(s).

44
Class Structures & Hierarchy
Design

You have successfully completed -

Class Structures & Hierarchy Design