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

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.