You are on page 1of 32

Understanding Inheritance in Rule Resolution

PegaRULES Process Commander v 4.2

Copyright 2006 Pegasystems Inc., Cambridge, MA


All rights reserved.

This document describes products and services of Pegasystems Inc. It may contain trade secrets and proprietary information. The document and product are protected by copyright and distributed under licenses restricting their use, copying distribution, or transmittal in any form without prior written authorization of Pegasystems Inc. This document is current as of the date of publication only. Changes in the document may be made from time to time at the discretion of Pegasystems. This document remains the property of Pegasystems and must be returned to it upon request. This document does not imply any commitment to offer or deliver the products or services described. This document may include references to Pegasystems product features that have not been licensed by your company. If you have questions about whether a particular capability is included in your installation, please consult your Pegasystems service consultant. For Pegasystems trademarks and registered trademarks, all rights reserved. Other brand or product names are trademarks of their respective holders.

This document is the property of: Pegasystems Inc. 101 Main Street Cambridge, MA 02142-1590 Phone: (617) 374-9600 Fax: (617) 374-9620 www.pega.com PegaRULES Process Commander Document: Understanding Inheritance Software Version 4.2 SP6 Updated: May 22, 2006

Contents
Understanding Inheritance in Rule Resolution for Process Commander Applications .........................................................................................................1 Overview of Rule Resolution ..............................................................................1 Enabling Rule Resolution on rules...............................................................1 Rule Instances of this class................................................................... 2 Class Inheritance and Rule Resolution........................................................3 Inheritance...........................................................................................................5 Pattern Inheritance .......................................................................................6 Directed Inheritance......................................................................................6 Class Hierarchy Search Protocol .................................................................7 Example: Inheritance paths.........................................................................8 Scenario 1............................................................................................ 10 Scenario 2............................................................................................ 12 Additional Inheritance Examples ..................................................................... 14 Scenario 1............................................................................................ 17 Scenario 2............................................................................................ 19 Scenario 3............................................................................................ 23 Scenario 4............................................................................................ 25

Understanding Inheritance in Rule Resolution for Process Commander Applications


Overview of Rule Resolution
Pegasystems patented Rules technology is the foundation of Process Commander BPM solutions, providing flexibility and agility. Rule resolution is the process used to identify which rules are applied to a specific business decision. At execution, Process Commander dynamically selects the right process or business rule depending on the business purpose, product, organization, RuleSet and version, date, time, customerassociated circumstance, and security for each rule required. Through dynamic rule selection, Process Commander provides flexibility that is otherwise impossible (except with the alternative of applying rules specified in code). This document is not an in-depth exploration of Rule Resolution itself, but an explanation of how the concept of class inheritance is used in a Process Commander system to facilitate Rule Resolution.

Enabling Rule Resolution on rules


Rules, as defined in this document, are all instances of classes which descend from the Rule- class, including Activities (Rule-Obj-Activity), Streams (Rule-Stream), Models (RuleObj-Model), Properties (Rule-Obj-Property), etc. The ability of a particular rule type (Activity, etc.) to be rule-resolved is dependent upon the definition of that rule, as shown by the Class form. Important: Not all rules are rule-resolved; Rule Resolution must be enabled on the class definition.

CONFIDENTIAL

Overview of Rule Resolution

When classes are defined, different features are enabled which affect inheritance and rule resolution. These features are contained in two sections on the Class form: Rule Instances of this Class Class Inheritance (described in a later section of this document)

Rule Instances of this class


Important: This option is only available for classes which start with Rule-, and as such, should not be changed. The features are described below so that developers may understand the functionality available for each Rule, and can predict the rule resolution for these classes. This section of the class form enables rule resolution for the rule. The different checkboxes control different functionality for resoution.

Allow multiple versions with the same key values (Rule Resolution) This is the most important choice for Rule Resolution, as it enables or disables the functionality. If this box is not checked, then none of the other checkboxes will appear on the class form. If checked, this field allows more than one rule with the same name and class to be present in the system. When this box is checked, the following Rule qualifiers will be enabled (i.e., Rule Resolution is used):

CONFIDENTIAL

Overview of Rule Resolution

RuleSet & Version Circumstance Date/Time Circumstance Date Availability

Therefore, if this box is checked, Rule Resolution will be used to open instances of this class. NOTE: It is possible for Rules to have this box checked and not have the Use classbased inheritance to arrive at the correct rule to execute box checked, as they operate independently. If only Allow multiple versions with the same key values is checked, then Rules (such as Rule-Message) are allowed to be saved and modified in different RuleSets/Versions; users will only use one of the same-named objects, based on their own Profile of RuleSets and Versions.

Allow selection of rules based on property values (Circumstance Qualified) This checkbox allows the rule to be Circumstance-qualified. If this box is not checked, Circumstances and Circumstance Dates may not be used with this rule. (For example, Declarative rules may not use Circumstances, and this feature is missing from those rules.) NOTE: If the Allow multiple versions with the same key values box is not checked, then this choice is not valid.

Allow rules that are only valid for a certain period of time (Date Range Availability) This checkbox allows the rule to be qualified by a Date Range. If this box is not checked, then a Date Range is not valid for this rule. (Declarative rules also may not use Date Ranges.) NOTE: If the Allow multiple versions with the same key values box is not checked, then this choice is not valid.

Use class-based inheritance to arrive at the correct rule to execute This field defines how inheritance (through the class hierarchy) affects this rule. For rules which are defined on other rules (such as Activities), this checkbox will affect how rule resolution searches for rules in the system. (Details on the functionality enabled by this checkbox are in the next section.)

Class Inheritance and Rule Resolution


As stated above, the Use class-based inheritance to arrive at the correct rule to execute checkbox defines how inheritance (through the class hierarchy) affects this rule. For this functionality, there are two main types of rules: those that can be defined as attributes or aspects of other classes those that are not aspects of other classes, but stand alone

CONFIDENTIAL

Overview of Rule Resolution

There are some types of rules, like Activities, Models, Whens, Decision Tables, etc., which may be applied to or defined on other classes.

In the above example, the activity DisplayFlowAction is defined on the class Work-. Other rules, such as Rule-Method, do not have the Use class-based inheritance box checked.

Instances of this rule will not be defined on any classes, and will not have the Applies To field on its instances.

CONFIDENTIAL

Inheritance

Inheritance
For rules such as activities which are defined on classes, inheritance applies. PegaRULES models data by defining it in a class hierarchy, following an object-oriented paradigm (much like Java). As Java methods can be inherited from the Java classs parents, Rules in PegaRULES such as Activities can be inherited from the defined class hierarchy. Thus, an instance of the class Work-Cover-GeneralTask will not only be able to 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 a particular activity (or property or other such rule) is called during processing, the application will search for that rule in the class where it was called. If the rule is not present in that class, Process Commander will search other classes, based on specific procedures. This section describes the paradigm used to search the class hierarchy during rule resolution. In PegaRULES, each class that is defined in the system may have one or two parents, depending upon the type of inheritance specified: pattern inheritance directed inheritance

Note that directed inheritance always applies, whether pattern inheritance is enabled or not. The Class Inheritance section of the class form defines the class hierarchy and inheritance for this class, which is then used when determining what rule to use in Rule Resolution.

CONFIDENTIAL

Inheritance

Find by name first (Pattern) determines pattern inheritance. If this box is checked, then when the system is searching for a particular rule defined on this class, it will use 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 & dashes in the class name to define inheritance. For example, the class YourCo-CustService-Data-Lender might have the following ancestors in the class hierarchy: YourCo-CustService-Data YourCo-CustService-Data YourCo-CustServiceYourCo-CustService YourCoYourCo If pattern inheritance is being followed, then all Activities, Whens, Models, etc. that are defined on any of the above classes would be available to be applied to YourCoCustService-Data-Lender (unless there is another more specific version of the instance defined on the YourCo-CustService-Data-Lender class itself). Pattern inheritance is always checked first. Note that pattern inheritance will cause the system to search all the way through the class pattern hierarchy before checking directed inheritance. If an instance of Rule-Obj-Activity called Display is defined on the class YourCoCustService above, then this Activity could be applied (if there is nothing more specific available) to all classes that inherit from YourCo-CustService. It is possible to independently change the definition of Display in any or all of these other classes, and then, depending upon Rule Resolution - what circumstances are present and what rules are being used at the time - different versions of Display will be selected by the system. Rule Resolution will search for the activity Display, and choose 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 the user to specify or direct from what classes the current class may inherit. Directed inheritance classes do not have to have the same name as the current class. A directed inheritance class is required for each class being defined. The field will default to the pattern class parent; the developer then may change this if they wish. By default, all base classes (Work-, Data-, etc.) will have directed inheritance to @baseclass.

CONFIDENTIAL

Inheritance

Important: The system will not prevent users from creating classes with inheritance that is circular, although this is definitely NOT PegaRULES Best Practice. If this kind of circular inheritance does happen, however, the system knows to go through a class only once. Example: YourCo-CustService-Data- (Data Dash) inherits via Pattern inheritance from YourCo-CustService-Data. YourCo-CustService-Data has directed inheritance to YourCoCustService-Data- (Data Dash). Again, this is NOT PegaRULES Best Practice, and should never be created. Developers who are creating classes should be very careful whether they create the class with a dash on the end or not.

Class Hierarchy Search Protocol


When the system is searching for a particular rule defined on a class (the activity Display, for example), it will search by pattern inheritance first (unless the pattern inheritance is unchecked, which should be extremely rare ). First, the class itself is checked for the rule; then the classs parent, by pattern inheritance; then that classs parent, and so on, up the chain of inheritance. If a match is not found, the first directed inheritance link is followed, and then pattern inheritance is used again, until the system finds an appropriate match. (See Scenario 1 in the example.) If Pattern inheritance is enabled, rule resolution will follow a name pattern all the way up through the pattern hierarchy, no matter what the inheritance settings are for classes higher in the pattern hierarchy. Directed inheritance is evaluated on a class-by-class basis, and only one link is followed at a time. Although pattern inheritance allows the system to search through an entire chain of classes, directed inheritance will only search to the specified directed inheritance class, and then stop and evaluate the next place to search, depending upon the definition of that class. Thus, for the class defined above (PegaSample-Folder), if searching for a specific rule (Display) defined on that class, the system would check the current class, and then follow pattern inheritance to PegaSample. If the activity were not found there, the system would follow the directed inheritance link and check Work-Folder-, and then, depending upon the settings in Work-Folder-, follow either pattern or directed inheritance from there.
1

For almost every class, Pattern inheritance should remain enabled (checked). A possible exception might be a situation where the hierarchy was built incorrectly, and now inheritance must be forced into a certain path.

CONFIDENTIAL

Inheritance

Example: Inheritance paths


The following classes are in the system: YourCoYourCo-CustService YourCo-CustService-CustCall YourCo-CustService-CustCall-Lender DataData-Party Work@baseclass @baseclass
Directed (defaulted)

YourCoPattern

Directed (defaulted)

Directed (defaulted)

YourCoCustService

WorkData-

Pattern

YourCoCustServiceCustCall-

Directed

Pattern Directed

Data-Party
Pattern

YourCoCustServiceCustCallLender

Directed

CONFIDENTIAL

Inheritance

Inheritance is set up for the above diagram by checking inheritance boxes on Class forms:

Class

On Class Form: Find by Name Pattern First checked (pattern inheritance) Most Immediate Ancestor:

Inherit From (Parent) field entry (directed inheritance) Most Immediate Ancestor: Data-Party

YourCo-CustServiceCustCall-Lender YourCo-CustServiceCustCall YourCo-CustService YourCoData-Party DataWork-

YourCo-CustServiceCustCall YourCo-CustService

Data-

YourCo-

YourCo@baseclass*

Data-

Data@baseclass* @baseclass*

*As stated previously, all classes are assumed to have directed inheritance to @baseclass; if there is not a specific class chosen for directed inheritance, @baseclass should be used.. In the above setup, the user wishes to use the Activity Display. There are several paths that rule resolution for this Activity could take, depending upon what inheritance options are chosen.

CONFIDENTIAL

Inheritance

Scenario 1
If the class being requested is YourCo-CustService-CustCall-Lender, and the pattern and direct inheritance for this class both point to YourCo-CustService-CustCall (and pattern inheritance is enabled for all of these classes), the system will search for Display in the following order:

1. 2. 3. 4. 5. 6.

YourCo-CustService-CustCall-Lender YourCo-CustService-CustCall YourCo-CustService YourCoWork@baseclass

NOTE: Since the class YourCo-CustService-CustCall was checked by pattern inheritance after YourCo-CustService-CustCall-Lender, it is not checked again for directed inheritance. Therefore, the first directed link goes to Work-.
10

CONFIDENTIAL

Inheritance

As stated above, all classes end with directed inheritance to @baseclass, so after checking YourCo- and then following directed inheritance from YourCo-CustServiceCustCall up through Work-, the last class checked in this pattern is @baseclass. All the above rules in any available RuleSet and Version will be selected to begin Rule Resolution.

CONFIDENTIAL

11

Inheritance

Scenario 2
NOTE: The example has changed slightly for this scenario as part of the application development, the developer has changed directed inheritance for the class YourCoCustService-CustCall-Lender to point to Data-Party. In this scenario, due to this change, the first directed link becomes the one from YourCoCustService-CustCall-Lender, up to Data-Party. This link will be followed after all the classes were checked using pattern inheritance. Therefore, the system will search for Display in the following order:

1. YourCo-CustService-CustCallLender 2. YourCo-CustService-CustCall 3. YourCo-CustService 4. YourCo-

5. Data-Party 6. Data7. @baseclass

12

CONFIDENTIAL

Inheritance

Realize that inheritance can be changed by adding new classes. In the first scenario, the system is looking for the Activity Display and may find it in the Work- class. However, if another class is added later which is located lower in the chain (such as Data-Party, which is then the directed link), then that class will be used for directed inheritance, and Workwill not be checked. Thus, although there is a directed link to Work- from YourCo-CustService-CustCall, this directed link is not followed in this scenario. Since YourCo-CustService-CustCallLender now has a directed link to Data-Party, that first directed inheritance link is followed, and no other directed link off the main Pattern Inheritance chain is followed. If the required version of Display is defined on Work-, the system may not find that version. The class Work- is blocked by Data-Party; any items which were inherited from Workby YourCo-CustService-CustCall-Lender will no longer be available. Instead, items inherited from Data-Party and Data- will be available.

CONFIDENTIAL

13

Additional Inheritance Examples

Additional Inheritance Examples


These examples are less likely to be seen in Process Commander applications. (They are included as an exercise, to show the effect of turning off pattern inheritance, which is not recommended.)

The following classes are in the system: YourCoYourCo-CustService YourCo-CustService-Data YourCo-CustService-Data-Lender YourCo-CustService-Data-Lender-InvestmentBank YourCo-CustService-Data-Party DataData-Party

14

CONFIDENTIAL

Additional Inheritance Examples

@baseclass
Directed (defaulted)

YourCoPattern

Directed (defaulted)

YourCoCustService

DataDirected

Pattern

Directed

Pattern

YourCoCustServiceDataPattern

Data-Party

Directed

Pattern

YourCoCustServiceData-Party

YourCoCustServiceData-Lender

Directed

Pattern
Directed

YourCo-CustServiceData-LenderInvestmentBank

CONFIDENTIAL

15

Additional Inheritance Examples

Inheritance is set up for the above diagram by checking inheritance boxes on Class forms:

Class

On Class Form: Find by Name Pattern First checked (pattern inheritance) Most Immediate Ancestor: YourCo-CustService-DataLender YourCo-CustService-Data YourCo-CustService YourCo@baseclass YourCo-CustService-Data Data-

YourCo-CustService-DataLender-InvestmentBank YourCo-CustService-DataLender YourCo-CustService-Data YourCo-CustService YourCoYourCo-CustService-DataParty Data-Party Data-

Inherit From (Parent) field entry (directed inheritance) Most Immediate Ancestor: YourCo-CustServiceData-Lender YourCo-CustServiceData-Party Data@baseclass* @baseclass* Data-Party Data@baseclass*

*As stated previously, all classes are assumed to have directed inheritance to @baseclass; if there is not a specific class chosen for directed inheritance, @baseclass should be used.. In the above setup, the user wishes to use the Activity Display. There are several paths that rule resolution for this Activity could take, depending upon what inheritance options are chosen.

16

CONFIDENTIAL

Additional Inheritance Examples

Scenario 1
If the class being requested is YourCo-CustService-Data-Lender-InvestmentBank, and pattern inheritance is enabled for all of these classes, the system will search for Display in the following order: 1. YourCo-CustService-Data-LenderInvestmentBank 2. YourCo-CustService-Data-Lender 3. YourCo-CustService-Data 4. YourCo-CustService 5. 6. 7. 8. 9. YourCoYourCo-CustService-Data-Party Data-Party Data@baseclass
KEY: Name Pattern - YES means that the field Find by Name Pattern First was checked, and Pattern Inheritance is enabled. Name Pattern - NO means that the field Find by Name Pattern First was unchecked, and Pattern Inheritance is disabled.

9
YourCoName Pattern - YES Inherit From: @baseclass

@baseclass

Directed (defaulted)

Pattern

YourCo-CustService
Name Pattern - YES Inherit From: YourCo-

DataName Pattern - YES Inherit From: @baseclass

Pattern Pattern

YourCo-CustServiceData
Name Pattern - YES Inherit From: Data-

Data-Party
Name Pattern - YES Inherit From: Data-

Directed

Pattern

YourCo-CustServiceData-Party
Name Pattern - YES Inherit From: Data-Party

YourCo-CustServiceData-Lender
Name Pattern - YES Inherit From: YourCoCustService-Data-Party

Directed

Pattern

YourCo-CustService-DataLender-InvestmentBank
Name Pattern - YES Inherit From: YourCoCustService-Data-Lender

CONFIDENTIAL

17

Additional Inheritance Examples

NOTE: Since the class YourCo-CustService-Data was checked by pattern inheritance after YourCo-CustService-Data-Lender, it is not checked again (with pattern inheritance) after checking YourCo-CustService-Data-Party. As stated above, all classes end with directed inheritance to @baseclass, so after checking YourCo- and then following directed inheritance from YourCo-CustService-Data-Party up through Data-, the last class checked in this pattern is @baseclass. All the above rules in any available RuleSet and Version will be selected to begin Rule Resolution. Important: Most Rule Resolution points to the class closest (in the inheritance path) to the one that is being requested (YourCo-CustService-Data-Lender) before checking the more general class (YourCo-), but depending upon the path that the inheritance searching follows, the fact that an item is defined in a more specific class does not mean it will automatically be chosen: as soon as the system finds a match for the rule it is searching for, it ends the search. (In the example above, if the Activity Display were defined in class Data-Party and then defined differently in class Data-, Rule Resolution would use the Display that was defined on class Data-Party and stop.) Note that although there is a directed link to Data- from YourCo-CustService-Data-, this directed link is not followed in the scenario. Since YourCo-CustService-Data-Lender has a directed link to YourCo-CustService-Data-Party, and is closer to the starting class of YourCo-CustService-Data-Lender-InvestmentBank, that first directed inheritance link is followed, and no other directed link off the main Pattern Inheritance chain is followed.

18

CONFIDENTIAL

Additional Inheritance Examples

Scenario 2
NOTE: The example has changed slightly for this scenario - YourCo-CustService-DataParty and Data-Party were removed. In this scenario, the first directed link becomes the one from YourCo-CustService-Data-, up to Data-CustService. This link will be followed after all the classes were checked using pattern inheritance, even though it is not at the bottom of the pattern chain. Therefore, the system will search for Display in the following order: 1. YourCo-CustService-DataLender-InvestmentBank 2. YourCo-CustService-DataLender 3. YourCo-CustService-Data 4. 5. 6. 7. YourCo-CustService YourCoData-CustService @baseclass

CONFIDENTIAL

19

Additional Inheritance Examples

7 5
YourCoName Pattern - YES Inherit From: @baseclass

@baseclass

Directed (defaulted)

KEY: Name Pattern - YES means that the field Find by Name Pattern First was checked, and Pattern Inheritance is enabled. Name Pattern - NO means that the field Find by Name Pattern First was unchecked, and Pattern Inheritance is disabled.

Pattern

YourCo-CustService
Name Pattern - YES Inherit From: YourCo-

Data-CustService
Name Pattern - YES Inherit From: @baseclass

Pattern Directed

YourCo-CustService-Data
Name Pattern - YES Inherit From: Data-CustService

Pattern

YourCo-CustServiceData-Lender
Name Pattern - YES Inherit From: YourCoCustService-Data

Pattern

YourCo-CustService-DataLender-InvestmentBank
Name Pattern - YES Inherit From: YourCoCustService-Data-Lender

20

CONFIDENTIAL

Additional Inheritance Examples

Realize that inheritance can be changed by adding new classes. In the above scenario, the system is looking for the Activity Display and may find it in the Data-CustService class. However, if another class is added later which is located lower in the chain, then that class will be used for directed inheritance, and Data-CustService will not be checked. In the below example, the class YourCo-CustService-Data-Party has been added to the system, and the class YourCo-CustService-Data-Lender now has directed inheritance to that class. The system will search for Display in the following order: 1. YourCo-CustService-DataLender-InvestmentBank 2. YourCo-CustService-DataLender 3. YourCo-CustService-Data 4. YourCo-CustService 5. YourCo6. YourCo-CustService-DataParty 7. Data-Party 8. Data9. @baseclass

CONFIDENTIAL

21

Additional Inheritance Examples

If the required version of Display is defined on Data-CustService, the system may not find that version. The class Data-CustService is blocked by Data-Party.
KEY: Name Pattern - YES means that the field Find by Name Pattern First was checked, and Pattern Inheritance is enabled. Name Pattern - NO means that the field Find by Name Pattern First was unchecked, and Pattern Inheritance is disabled.
Directed (defaulted) Pattern

9 5
YourCoName Pattern - YES Inherit From: @baseclass

@baseclass

YourCo-CustService
Name Pattern - YES Inherit From: YourCo-

Data-CustService
Name Pattern - YES Inherit From: @baseclass

DataName Pattern - YES Inherit From: @baseclass Pattern

Pattern

7 3
YourCo-CustService-Data
Name Pattern - YES Inherit From: Data-CustService

Data-Party
Name Pattern - YES Inherit From: Data-

Directed

Pattern

YourCo-CustServiceData-Party
Name Pattern - YES Inherit From: Data-Party

YourCo-CustServiceData-Lender
Name Pattern - YES Inherit From: YourCoCustService-Data-Party

Directed

Pattern

YourCo-CustService-DataLender-InvestmentBank
Name Pattern - YES Inherit From: YourCoCustService-Data-Lender

The above scenarios assume that Pattern Inheritance is enabled for all the above classes. There are a number of different inheritance paths that could be followed through this system, based on what settings are chosen in each class.

22

CONFIDENTIAL

Additional Inheritance Examples

Scenario 3
Because pattern inheritance will cause the system to search all the way through the hierarchy before checking directed inheritance, if Find by Name Pattern First? were checked (pattern inheritance enabled) for YourCo-CustService-Data-LenderInvestmentBank, then then the path through the list of rules searched for Display would remain the same as Scenario 1, even if Find by Name Pattern First? were unchecked (pattern inheritance disabled) for other classes (YourCo-CustService-Data-Lender, YourCo-CustService-Data, YourCo-CustService, YourCo-). 1. 2. 3. 4. 5. 6. 7. 8. 9. YourCo-CustService-Data-Lender-InvestmentBank YourCo-CustService-Data-Lender YourCo-CustService-Data YourCo-CustService YourCoYourCo-CustService-Data-Party Data-Party Data@baseclass

CONFIDENTIAL

23

Additional Inheritance Examples


KEY: Name Pattern - YES means that the field Find by Name Pattern First was checked, and Pattern Inheritance is enabled. Name Pattern - NO means that the field Find by Name Pattern First was unchecked, and Pattern Inheritance is disabled.

@baseclass

YourCoName Pattern - NO Inherit From: @baseclass

Directed (defaulted)

Pattern

YourCo-CustService
Name Pattern - NO Inherit From: YourCo-

DataName Pattern - YES Inherit From: @baseclass

Pattern Pattern

YourCo-CustServiceData
Name Pattern - NO Inherit From: Data-

Data-Party
Name Pattern - YES Inherit From: Data-

Directed

Pattern

YourCo-CustServiceData-Party
Name Pattern - YES Inherit From: Data-Party

YourCo-CustServiceData-Lender
Name Pattern - NO Inherit From: YourCoCustService-Data-Party

Directed

Pattern

YourCo-CustService-DataLender-InvestmentBank
Name Pattern - YES Inherit From: YourCoCustService-Data-Lender

Although Find by Name Pattern First? might be unchecked (pattern inheritance disabled) for YourCo-CustService-Data-Lender, the inheritance path would continue on to YourCo-CustService-Data, YourCo-CustService, and YourCo- before checking directed inheritance.

24

CONFIDENTIAL

Additional Inheritance Examples

Scenario 4
If Find by Name Pattern First? were unchecked (pattern inheritance disabled) for YourCo-CustService-Data-Lender-InvestmentBank, the system would then follow directed inheritance to YourCo-CustService-Data-Lender. Since checking is done on a class-byclass basis for directed inheritance, the inheritance path would then be determined by the settings in YourCo-CustService-Data-Lender. If Find by Name Pattern First? were checked in YourCo-CustService-Data-Lender, then the path for inheritance for YourCoCustService-Data-Lender-InvestmentBank would be the same as Scenario 1:

1. 2. 3. 4. 5. 6. 7. 8. 9.

YourCo-CustService-Data-Lender-InvestmentBank YourCo-CustService-Data-Lender YourCo-CustService-Data YourCo-CustService YourCoYourCo-CustService-Data-Party Data-Party Data@baseclass

CONFIDENTIAL

25

Additional Inheritance Examples


KEY: Name Pattern - YES means that the field Find by Name Pattern First was checked, and Pattern Inheritance is enabled. Name Pattern - NO means that the field Find by Name Pattern First was unchecked, and Pattern Inheritance is disabled.

@baseclass

YourCoName Pattern - YES Inherit From: @baseclass Pattern

Directed (defaulted)

YourCo-CustService
Name Pattern - YES Inherit From: YourCo-

DataName Pattern - YES Inherit From: @baseclass

Pattern Pattern

YourCo-CustServiceData
Name Pattern - YES Inherit From: Data-

Data-Party
Name Pattern - YES Inherit From: Data-

Directed

Pattern

YourCo-CustServiceData-Party
Name Pattern - YES Inherit From: Data-Party

YourCo-CustServiceData-Lender
Name Pattern - YES Inherit From: YourCoCustService-Data-Party

Directed

Directed

YourCo-CustService-DataLender-InvestmentBank

Name Pattern - NO Inherit From: YourCoCustService-Data-Lender

26

CONFIDENTIAL

Additional Inheritance Examples

However, if Find by Name Pattern First? were unchecked in YourCo-CustService-DataLender and YourCo-CustService-Data, then the path for inheritance for YourCoCustService-Data-Lender-InvestmentBank would change: 1. 2. 3. 4. 5. 6. YourCo-CustService-Data-Lender-InvestmentBank YourCo-CustService-Data-Lender YourCo-CustService-Data-Party Data-Party Data@baseclass
KEY: Name Pattern - YES means that the field Find by Name Pattern First was checked, and Pattern Inheritance is enabled. Name Pattern - NO means that the field Find by Name Pattern First was unchecked, and Pattern Inheritance is disabled.

@baseclass

Directed (defaulted)

YourCoName Pattern - NO Inherit From: @baseclass

DataName Pattern - NO Inherit From: @baseclass


Directed

YourCo-CustService
Name Pattern - NO Inherit From: YourCo-

4
YourCo-CustServiceData
Name Pattern - NO Inherit From: Data-

Data-Party
Name Pattern - NO Inherit From: Data-

Directed

YourCo-CustServiceData-Party
Name Pattern - NO Inherit From: Data-Party

YourCo-CustServiceData-Lender
Name Pattern - NO Inherit From : YourCoCustService-Data-Party

Directed

Directed

YourCo-CustService-DataLender-InvestmentBank
Name Pattern - NO Inherit From: YourCoCustService-Data-Lender

CONFIDENTIAL

27

Additional Inheritance Examples

Note that in this scenario, the classes YourCo-CustService-Data, YourCo-CustService, and YourCo- are not checked at all.

28

CONFIDENTIAL