The document discusses the structure and hierarchy design of class definitions in Pega, focusing on three main class types: work classes for processing tasks, data classes for data structures, and history classes for tracking changes. It explains the inheritance and rule resolution process, distinguishing between abstract and concrete classes, as well as class groups, work objects, and work pools. This overview highlights how these components interact to optimize application performance and organization.

1. Pega Test Topics
Class Structure and Heirachy Design % of Exam: 10%
Concepts
When designing the class structure of the application, we define classes that are derived
usually from three standard PRPC base classes:
1. Work. These classes are needed for processing work. They are the starting
point for work-related classes. Every application needs at least one concrete
class derived from the Work- base class.
2. Data – these classes define the data structures for supporting info that the
application uses to process work.
3. History – these are created automatically and hold instances that track changes
to instances of other classes. They are created automatically as a byproduct of
the creation of other classes.
All classes in the application inherit properties and other rules from the base classes.
Class structure determine the path rule resolution takes. Here’s how inheritance works for
rule resolution: Given an instance in a class in order to resolve a rule in it at run time, the
pattern inheritance is always checked first. If unresolved then the *first* possible directed
inherited path is chosen and this method of searching is repeated till finally the
@baseclass- is reached. If after the entire search the rule is not found an error is thrown.
An abstract class is a class which is created to *support* other rules, including other
classes. They don’t have instances in the database. Concrete classes on the other hand can
have instances saved in the database. If the last character in the name is a “-“ this
indicates that this is an abstract class (and vice versa).
Concrete classes corresponding to instances saved in the PegaRULES db are called
“internal classes” whereas concrete classes corresponding to instances saved in an
*external* db are called “external classes”.
Concrete classes derived from the Rule- base class are called “rule types”.Concrete
classes derived from the Work- base class are called “work types”. (don’t ask me why
these stupid names were chosen).
A “class group” is used to group similar classes together. In practical terms this means
creating different (usually concrete) classes with the same name as its prefix. That prefix
is the name of the class group. A class group instance causes the system to store such
concrete classes in a single database table. (I imagine this leads to huge performance
gains).

2. A “work object” is the primary unit of work completion in an application and the primary
collection of data that a flow operates on. Every work object has a unique Id (pyID), an
urgency value and a status (pyStatusWork). As an application is used, work objects are
created, updated, and eventually resolved. The workobject ID is automatically assigned
by the system when it is created. The format of the ID is usually W-nnnn for ordinary
work objects, F-nnnnn, and C-nnnnn for folder objects and cover objects respectively.
(pdn says: “The prefix is set in the model rule of the work type or work pool”. I think
they mean “work type or class group”.. but that may just be me.)
A “work pool” for a user is the set of all work objects (open and resolved) of all the
Work- classes that a user can enter in an application.