Class hierarchy and inheritance

The Pega Platform class hierarchy is a hierarchy for storing rules and data, not for Java variables or Java methods. Each class, whether abstract or concrete, can contain properties, activities, data transforms, and many other rules. Only objects in concrete classes can be saved as persistent or enduring instances in the PegaRULES database.

At the top of the hierarchy is the ultimate base class, identified by the keyword @baseclass. Its immediate child classes are known as the base classes. Concrete classes under two of these base classes, Rule- and Data-, hold rules and data instances that application developers create and update to build their application.

Instances of concrete classes derived from the Assign- base class and the Work- base class (and perhaps a few others) hold the dynamic transaction data and status details as your Pega Platform application operates.

When any object is held in memory, it has an XML (eXtensible Markup Language) format visible on your clipboard as pages and property name-value pairs. When stored into the PegaRULES database, the persistent object instance becomes a row in a SQL-based relational database table. Three data classes, accessed through the Database, Database Table, and Class Group forms, together determine how Pega Platform saves and retrieves the XML data as relational database rows.

You application may need custom classes derived from these base classes:

  • Work- base class (common)
  • Assign- base class (rare)
  • Data- base class (common)
  • Embed- base class (occasional)
  • Index- base class (occasional)
  • History- base class (created automatically)

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.

A database administrator can help design and plan Database Tables and class groups, as these decisions can influence database performance and backup needs.

Many rules apply to a specific class, and potentially to subclasses of that class. Rule resolution is the Pega Platform search and lookup algorithm that uses inheritance to search through parent classes in a defined sequence for a rule. For example, if a property named CreditLimit is needed at runtime in the context of a class named Delta- CustomerCard, the system may search for a property with this name in several classes:

  • Delta-CustomerCard
  • Delta-
  • Work-Cover-
  • Work -
  • @baseclass (the topmost class)

The search ends when a rule is found. Settings in the class rule ( Rule-Obj-Class rule type) define whether and how two mechanisms — directed inheritance and pattern inheritance — are employed during this search.

Class groups and inheritance

The names of all classes belonging to a common class group start with the class group name, followed by a hyphen. For example, if you define a class group named Work-Object-Thorr-Task, the classes in the class group can be named Work-Object-Thorr-Task-Ordering, Work-Object-Thorr-Task-Shipping, and Work-Object-Thorr-Task-Billing.

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.

For instance, in the above example, Work-Object-Thorr-Task-Ordering can be configured to inherit rules from Work-Object-, while the other two classes inherit from Work-Cover-Thorr-. All the classes in one class group, however, are associated with one common database table, regardless of their parent class for rule resolution purposes.

When one system hosts two or more organizations using a common application, each organization should have its own dedicated work pools. Work object numbering is per work pool; each organization can then have a work item numbered W-1234. The Clone a Class Group landing page tab is useful in this situation. See Data Model category — Classes and Properties landing page.