Enterprise Class Structure in Pega

December 10, 2024 Code Vault Curators

In this blog article, we will keep our focus to get clear understanding on the Enterprise class structure in Pega.

This article was created using Pega '24 version.

When an Organization decides to use Pega solution to build their enterprise applications, One of the first questions is to get clear on the Enterprise architecture and define the Enterprise layers in the right way. This is seriously critical for a successful Pega implementation so that it can be easily extended, reused and maintained well in the picture.

To get this going, let’s start with simple OOPS concepts in Java programming.

You want to create a simple Java programming to get the details of the Fulltime employees and Part-time employees in the Organization using the Class Inheritance and Polymorphism.

In the above code, you can clear see that there is a class defined as Employee and then sub-classes FullTimeEmployee and PartTimeEmployee extend the Employee class and can reuse the fields like name and Salary.

You also see the Sub classes overridden the getDetails() function which is available in the base Employee class with its own-calculation. This concept refers to Polymorphism.

Now comparing the concepts to Pega class.

We are going to talk about the different inheritances 😊

Pega can have a base class as – Org-Data-Employee and then have two sub-classes as Org-Data-Employee-Fulltime and Org-Data-Employee-Parttime.

In this way, the sub-classes can inherit the properties in the parent class layers and can also override if needed in their sub-class layer.

We know that we need to specify the right class layer when we want to create rules ( most of the pega rules need a class context to be specified)

Let’s say an activity created in the Org-Data-Employee-Fulltime class can inherit and reuse the properties or activities created in the Org- layer or Org-Data- layer or Org-Data-Employee layer.

This type of inheritance and reuse is called the pattern inheritance.

In Pega, Are we just restricted to reuse properties only on Pattern inheritance path, like the parent class path?? – No!!

If you look at the modular design approach, you should be able to also reuse totally unrelated objects!!

That is where the direct Inheritance comes in!

Any class layer can directly inherit from another class layer.

Let’s say you have an OOTB class layer called Data-Person, which holds all the necessary rules related to Person Object. Now Org-Data-Employee is also a Person kind right? So how can reuse or inherit the rules from Data-Person?

This can be done via direct Inheritance!

I hope you got some info about the direct Inheritance and Pattern Inheritance and able to compare with Java Inheritance and Polymorphism.

Let’s check this with rule resolution.

Let’s say, you want to call ‘GetDetails’ pega activity to get the employee details. When the flow advances to this data object context, Pega use rule resolution algorithm to find the ‘GetDetails’ activity.

Note: Please note the actual rule resolution is more complex than just the inheritance path. For simplicity, We are using only Inheritance in the below example.

1. Pattern Inheritance

Pega uses pattern inheritance to check the activity rule available in the class path.

– It means, first it checks ‘Org-Data-Employee-FullTime’.

– If the rule is not found, then pega checks ‘Org-Data-Employee’ class.

– If it is not found again, then it checks ‘Org-Data’, checking process continues till ‘Org.

2. Direct Inheritance

You can specify a direct inheritance class in the class rule form.

Class ‘Org-Data-Employee-FullTime’’ can directly inherit from OOTB base product data class ‘Data-Person’. It means it can reuse rules from the directly inherited class.

Now the question is on which inheritance, does the rule resolution give priority?

Checking on the pattern inheritance or on the direct inherited class?

The configuration stays in the class rule form, the same place where you configure the direct inherit class. Of course, we don’t want to configure the pattern inheritance because it is in the class path!

a) If ‘Find by name first’ pattern inheritance is checked (the default configuration), then pega checks for pattern inheritance first. If the rule is not found, then the rule resolution algorithm checks the class specified in direct inheritance class field. It goes on till @baseclass. All class inheritance ends in @baseclass.

b) If ‘Find by name first’ pattern inheritance is Ún-checked, then Pega always checks the directed inheritance path. Normally this will be configured at Org layer or the end layer.

You also see a field, where you can specify the Directed inherited parent class.

One more important thing to understand is, Pega also extends this layering into Enterprise level.

Take a look at this class layer – Org-Data-Employee-FullTime’. You can see there is a Org- layer at the very bottom. Org-Data-Employee-FullTime also pattern inherits from Org layer as you can see the hierarchy. It means It can reuse the rules from Organizational layer.

This is the real power of Pega class layers that always extends to the Organizational layers 😊

Now it is time to talk about Enterprise class structure.

We know that Pega helps with building enterprise applications that can be reused across organization and so rightly Pega uses the Enterprise class structure.

In simple words, we are going to map our class structure with the client organization.

Let’s say you are building Pega CRM application for ABC Bank. They have multiple geographic divisions like IN, US, EUR. In each of the geographic locations, they have their dedicated departments like Sales, Service

Now the very first step is to map the Organizational layer with the Pega organizational chart.

In Pega Implementation, we can have a single Organization, with multiple divisions and then divisions can have multiple Units. Note, it is not restricted to having only three-level hierarchy, we can have multiple unit levels as well 😊

Let’s explore this enterprise class structure, and class inheritance more in detail by creating a branch new application.

Step 1: Start the new application wizard.

Navigate to your dev studio or app studio and start creating a new application.

I will build this application from scratch.

On UI Architecture, you can choose either Constellation UI or Traditional UI.

Step 2: Get into advanced configuration

This is the place where you will decide your Enterprise class structure.

Very critical decision of your application. Carefully consider the selection.

The very first step is to choose your Application structure. It can be framework or Implementation. Nowadays, we rarely create any framework application. It is always good to create an Implementation application.

More details are shared in another blog article –

Situational Layer Cake and Framework Vs Implementation Application types

Here we will choose the Implementation application.

The Organization mapping and the class layers are very critical.

Choose your Organizational names. If you are creating your very first Pega application, all these instances will be created.

Note: Organization, division and Unit are data instances in Pega

Now you need to decide on the Class layers. You need to make a decision whether you need to Generate division layer / Unit Layer? In other words, on which layer do you want to deploy your Implementation application?

Let’s say your Organization is very small with simple Pega Implementation, then it is not necessary to generate division or unit layer.

In our use case, our Organization Amazon has Three divisions and we want to create an application for the India Division. It means I may have some business logics, rules which are division specific. Here I can straight away use the Generate division layer checkbox.

Compare the before picture and this picture! You will see the class layer now Includes the Division as well.

It means the Work layer is Org-Div-App-Work = Amazon-In-Onboarding-Work.

You also get an option to further go down and create an application on Unit specific, but in my use case, I don’t need that option!

Step 3: Save and create your application.

This auto-creates a lot of rules at the backend.

Step 4: Check the different class layers.

Let’s start with the Organization layer Amazon-

You see there are 4 layers –

Amazon-Data – Organization Data layer
Amazon-Int – Organization Integration layer
Amazon-FW – Template framework layer (but is not used for Implementation application)
And then, Amazon-In – Division Layer.

Now expand the Division layer in the App Explorer.