Table of Contents

Application stack hierarchy for multiple built-on applications

This article details how the Pega Platform™ processes various hierarchical structures of multiple built-on applications at design time. However, it is recommended that you first review Using multiple built-on applications for information about the benefits and best practices of using built-on applications during application development.

When an application uses multiple built-on applications, the Pega Platform automatically converts the hierarchical application tree into a single linear application stack, as shown in the following image.

Conversion of the hierarchical application tree into a linear application stack

The Pega 7 Platform creates the linear application stack by adhering to the following rules:

  • PegaRULES is always located at the end of the linear application stack list.
  • Each built-on application is processed by using a depth-first algorithm that searches as far as possible along a tree branch before moving on to another tree branch.
  • For duplicate applications with the same application version, only the application with the lowest position in the tree is retained in the application stack list, and the other application is ignored.
  • For duplicate applications with different application versions, as well as for PegaRULES, the numerically highest available application version is used.

Ruleset behavior at design time

Each application in the hierarchical application tree consists of various rulesets that the Pega Platform automatically assembles into a linear ruleset stack. This ruleset stack defines what rulesets are available for a specific rule to use for context purposes at design time.

Ruleset stack assembly generally follows the same guidelines that are used for creating the linear application stack at run time. However, ruleset stack assembly for a specific rule is based on a rule's "owning application," which is defined as the specific application that the rule belongs to.

After the Pega Platform determines a rule's owning application, it automatically creates the linear ruleset stack for that specific rule starting with the rule's owning application and works through the hierarchical application tree branch to PegaRULES.

The behavior described above is only applicable when saving a rule in a ruleset that uses Application Validation mode. When saving a rule in a ruleset that uses Ruleset Validation mode, prerequisites must be specified on the ruleset's Versions tab.

Because of this behavior, some rulesets that are available at run time cannot be referenced by the saved rule at design time when Application Validation mode is used. This restriction allows for the appropriate isolation of applications, making applications easier to reuse.

Example of linear ruleset stack assembly

In this example, the following hierarchical application tree contains rulesets that all use Application Validation mode:

MortPlus 01.01 (Ruleset1)
Underwriting 01.01 (Ruleset2) Pricing 01.01 (Ruleset4)
MyCoLib 01.02 (Ruleset3) MyCoLib 01.01 (Ruleset5)
PegaRULES PegaRULES

RuleABC is saved in Ruleset2, so the Underwriting application is defined as its owning application. The ruleset stack that is available for RuleABC to use at design time is assembled as follows:

Ruleset2 > Ruleset3 > PegaRULES

The ruleset stack is built starting at the Underwriting application and is processed through PegaRULES in that specific application tree branch. Because the Pricing application is located on a separate application tree branch, ruleset stack processing for RuleABC is unable to reference Ruleset4 and Ruleset5 from the other tree branch at design time.

Run-time behavior

At run time, the Pega Platform creates the linear application stack for the entire tree of built-on applications following the preceding guidelines. This application stack is the basis for application functionality in a live environment.

Use case examples

The following use cases describe how the Pega Platform processes the hierarchical application tree into a single linear application stack at run time.

These examples are for demonstration purposes only and might not represent the application structure of current application offerings.

Use case 1: Multiple applications using the same PegaRULES version

In this example, the TopApp application is built on the BaseApp1, BaseApp2, and BaseApp3 applications. All applications are built on the same version of PegaRULES.

TopApp [Ruleset1, Ruleset2]
BaseApp1 BaseApp2 BaseApp3
PegaRULES

The resulting application stack is structured as follows:

TopApp > BaseApp1 > BaseApp2 > BaseApp3 > PegaRULES

Each built-on application is processed by using a depth-first algorithm.

​Use case 2: Multiple applications using different PegaRULES versions

In this example, the MyCustomerApp application is built on the BillingApp and SupportApp applications. Each of these applications is built on a different version of PegaRULES.

MyCustomerApp (Ruleset1)
BillingApp (Ruleset2) SupportApp (Ruleset4)
BillingPlansApp (Ruleset3) PegaRULES 07.05
PegaRULES 07.01  

The resulting application stack is structured as follows:

MyCustomerApp > BillingApp > BillingPlansApp > SupportApp > PegaRULES:07.05

The numerically highest available version of PegaRULES is used in the application stack list.

Use case 3: A duplicated application with different versions

In this example, the ProductionApp application is built on the FinalAppTemplate application, which is in turn built on the CustomerApp and EmployeeApp applications. Each of these applications has additional built-on applications, including the duplicated MyBusinessApp application, which has two different versions in use. All applications are built on the same version of PegaRULES.

ProductionApp 01-01 (Ruleset1)
FinalAppTemplate 01-01 (Ruleset2)
CustomerApp 07.01 (Ruleset3) EmployeeApp 01-01 (Ruleset6)
ServicesApp 01-01 (Ruleset4) MyBusinessApp 01.01 (Ruleset7)
MyBusinessApp 01-02 (Ruleset5) PegaRULES 07-01
PegaRULES 07-01  

The resulting application stack is structured as follows:

ProductionApp > FinalAppTemplate > CustomerApp > ServicesApp > EmployeeApp > MyBusinessApp:01-02 > PegaRULES

Even though the application with the lowest position in the tree list is retained, the application stack list uses the numerically highest available version for the duplicated application.

Use case 4: A duplicated application with multiple branch points

In this example, the MyCustomApp application is built on several other applications, including two applications that both contain the same application, MyHealthApp. All applications are built on the same version of PegaRULES.

MyCustomApp
ComplexApp BasicApp1 BasicApp2
MyPlanner ResultsApp PegaRULES PegaRULES
MyReports MyHealthApp ​SurveyApp    
MyHealthApp PegaRULES PegaRULES    
PegaRULES        

The resulting application stack is structured as follows:

MyCustomApp > ComplexApp > MyPlanner > MyReports > ResultsApp > MyHealthApp > SurveyApp > BasicApp1 > BasicApp2 > PegaRULES

​​Duplicate applications with the same version use the lowest positioned application in the tree list.

Use case 5: An application with branches

In this example, the MyCallCenter application has two branches, Branch_MyCallCenterRS and Branch_Policies. All applications are built on the same version of PegaRULES.

MyCallCenter

- Branch_MyCallCenterRS

- Branch_Processes

MyStaffingApp Processes
Policies PegaRULES
PegaRULES  

The resulting application stack is structured as follows:

MyCallCenter > MyStaffingApp > Policies > Processes > PegaRULES

An application can branch its own ruleset or the rulesets for the built-on application at design time, but cannot branch the ruleset for the built-on application at run time.

Suggest Edit

96% found this useful


Related Content

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.