Pega - Class Interview Q&A

Difference between Work- and Data- classes?

The Work- base class, one of thirteen standard top-level abstract classes, is a superclass to all the classes that define work objects. A work object is a fundamental unit that records processed work in an application.

The Data- the base class is an abstract class above various classes that define and contain static data and cumulative data. For example, the Data-Admin- classes contain information created by your Process Commander developers defining who can use the application, their privileges and security, and where they belong in the organization.

 What are the different layers in Architecture?

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

 There are four distinct layers in the PRPC best practice class structure design pattern:

PRPC Shared Product:  The PRPC Shared Product represents the out-of-the-box Process Commander classes such as Work-, Work-Object-, Work-Folder-, Work-Cover-, and Data-

Enterprise Shared Product Layer:  The Enterprise Shared Product Layer is a library of extensions to the PRPC base functionality.  You should always include this layer.  It is rare, but this layer may be omitted in some very small one-off applications.

Generalized Application Layer:  The Generalized Application Layer represents a generic base application to use as a framework for application instances.  Here we will define most of the rules for our base application.

Organizational and Specialized Application Layer:  The Organizational and Specialized Application Layer represents an organizational application instance.  Here we will be implementing the generic application.


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

The class structure provides us with a hierarchy in which rules can be placed.  The higher a rule is in the hierarchy, the more potential reuse there is.  However, a rule can only reference other rules at the same level in the hierarchy or higher.  For example, a rule X at class A- cannot call Rule Y defined at A-B if no rule Y exists at A-.

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.

Shared RuleSets provide a grouping mechanism for sharing both classes resolved and non-class resolved rules.  For example, Rule HTML properties and utility functions are non-class resolved.  RuleSets are key to reusability as they are the mechanism by which shared rules are moved to different rule bases and/or environments.


What is a class group and what are its advantages?

A Class The group is an instance of the Data-Admin-DB-ClassGroup class.

A class group instance causes the system to store the instances corresponding to two or more concrete classes that have a common key format in a single database table. Class groups are commonly used to cause the system to store instances of similar or related Work- concrete classes together in one relational database table.

All the classes who belong to a class group can inherit all the rules cleared and defined at the class group level.

 What are the Inheritance types?

Process Commander provides two kinds of class inheritance, known as directed inheritance and pattern inheritance.

Pattern inheritance, an optional feature we can set up for a class in the Rule-Obj-Class rule, affects the first steps in the rule resolution algorithm. This approach is sometimes called “dual” inheritance.

During rule resolution, pattern inheritance causes a class to inherit rules first from classes that match a prefix of the class name.

Directed inheritance — allows us to name a parent class, choosing a name that is not related to the name of this class.

 How pattern and directed inheritance works?

Pattern Inheritance works as follows:

Rule resolution always looks first for a rule it needs in the class initially provided,

Regardless of the state of this, check box. If the box is checked and the rule is not found, it forms a sequence of candidate classes to search by truncating, from the left, portions of the class name that consist only of a dash character, or consist only of characters other than a dash. If no class exists for one of these computed names, rule resolution continues with the next prefix.

For example, a search for a rule in the MyBank-LoanOrg-LoanDept class could search

Through these classes, in the order, indicated:






Directed Inheritance works as follows:

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.


What are the types of classes?

A class is an instance of the Rule-Obj-Class rule type.

An abstract class is a rule (an instance of the Rule-Obj-Class class) 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 concrete class can have instances stored in the database. An abstract class cannot have any instances.

 What are Pega default classes?

A base class is one of twelve standard abstract classes that are immediately below the top class in the hierarchy. This top class, known as the ultimate base class, is identified by the symbol @baseclass.

The three base classes of greatest interest to application developers are Data-, Assign- and Work-.

The base classes are:

Assign- Assignment instances, each identifying a step in a workflow that requires human input or work by an outside organization, person, or system.

Code- Classes that directly reference server program code. Pages belonging to classes derived from the Codebase class exist only temporarily in memory and are not saved in the PegaRULESdatabase.

Data- Parent class of concrete classes containing reference data, including data for system administration and security.

Embed- Defines the structure of pages embedded within other pages. Pages belonging to classes

                Derived from the Embed- base class cannot be renamed or directly saved.

History- Append-only instances record the change history of objects in another class.

Index- Secondary access keys are defined to provide fast retrieval of other instances.

Link- Instances that record associations between two objects.

Log- Parent of concrete classes containing cumulative logs of important system-wide events.

PegaAccel- Parent of special classes that support the Application Accelerator tool.

Rule- Rule types, for defining applications.

System- Contains operational status information about the entire Process Commander system.

Work- Work objects, covers, and folders.

No comments:

Post a Comment