Summary

For rules such as activities which are attributes of (defined on) classes, inheritance applies. 

Process Commander models data by defining it in a class hierarchy, following an object-oriented paradigm (much like Java).  Just as Java methods can be inherited from the Java class’s parents, Process Commander rules such as activities can be inherited through the defined class hierarchy.  Thus, an instance of the class Work-Cover-GeneralTask can use the activities, properties, etc. which are defined on that class, but also those defined on the class Work-Cover-, and the class Work-.

When an activity (or property or other such rule) is called during processing, rule resolution first searches for that rule in the class where it was called.  If the rule is not present in that class, rule resolution then searches other classes in the hierarchy, based on specific procedures. 

This article describes how rule resolution searches the class hierarchy.

Suggested Approach

Each class may have one or two parents, depending upon the class specified for each type of inheritance.  There are two types of inheritance:

• pattern inheritance
• directed inheritance

Note that directed inheritance always applies, whether pattern inheritance is enabled or not. 

Inheritance is defined in each class in the Class Inheritance section of the Class form; this information is used at runtime as rule resolution determines what rule to execute:

Find by name first (Pattern) – determines pattern inheritance.  When this box is checked, then when the system is searching for a particular rule defined on this class, it will use the name-pattern inheritance to search through all the classes linked in the hierarchy.

Parent class to inherit from (Directed) – determines directed inheritance.  This field holds the immediate parent, by directed inheritance, to use for this class.

Pattern Inheritance

Pattern inheritance follows the pattern of the names and dashes in the class name to define inheritance.  For example, the class Acme-Auto-ClaimsEntry-Accident might have the following ancestors in the class hierarchy:

Acme-Auto-ClaimsEntry

Acme-Auto

Acme-

When the system is using pattern inheritance to find a rule, then all activities, When rules, properties, and other rules that are defined on any of the above classes would be available to be applied to Acme-Auto-ClaimsEntry-Accident (unless there is another more specific version of the instance defined on the Acme-Auto-ClaimsEntry-Accident class itself).

During rule resolution, classes are always checked through pattern inheritance first.  Note that pattern inheritance will cause the system to search all the way through the class pattern hierarchy before checking classes through directed inheritance.

If you define an activity called Display on the class Acme-, then this activity will be applied to all classes that inherit from Acme-.   You can also copy this Display activity into any or all of these “descendant” classes (using Save As), and then change those activities to have different functionality in the different classes.  At runtime, depending upon rule resolution - what circumstances are present and what rules are being used at the time -  the most appropriate version of Display for the situation will be selected by the system.   Rule resolution searches for the activity Display, and chooses the Display which is defined on the class closest (in the inheritance path) to the one that is being requested. 

Directed Inheritance

Directed inheritance allows you to specify or direct from what classes the current class may inherit.   Directed inheritance classes do not have to have a name which includes the “pattern parent prefix” of the current class.  (For example, Acme-Auto-ClaimsEntry could have directed inheritance to Work-Object-; the directed inheritance does not have to follow the “Acme-Auto-“ prefix.)

On the Class form, specify a directed inheritance class for each class being defined.  The field defaults to the pattern class parent; you may change this if you wish.

By default, all base classes (Work-, Data-, etc.) have directed inheritance to @baseclass.

Important:  The system does not prevent you from creating classes with inheritance that is circular, although this is definitely not a good practice.  If this kind of circular inheritance does happen, however, the rule resolution processes a class only once.

Example:

Acme-Auto-ClaimsEntry-  (“ClaimsEntry Dash”) inherits using pattern inheritance from Acme-Auto-ClaimsEntry.

Acme-Auto-ClaimsEntry has directed inheritance to Acme-Auto-ClaimsEntry-  (“ClaimsEntry Dash”).

(Do not create such circular relationships).  When creating a class, be careful whether or not to include a dash character as the last character of the name..

Class Inheritance Viewer

Beginning in V5.2, the Class Inheritance display shows pattern and directed inheritance for each class.  This tool is available from the Application Explorer tree:  Right-click on any class, and its inheritance is shown.

For example, the PegaSample-Task class is shown below:

Based on the class form, the inheritance is as follows:

When right-clicking on the PegaSample-Task class and choosing Inheritance from the menu, the following diagram appears:

This display clearly shows the inheritance path for each class,allowing you to determine from which ancestors a class will inherit objects.