Alias pattern – its Configuration & Usage in PEGA

Before We Begin

Before entering into the discussion, let’s understand what is a data model in PEGA and how efficiently it can be designed in our application.

What is Data Model?

As the name defines, it is all about defining the data elements, standardizing how they relate to one another and to the properties of the real-world entities.

> For instance, when we have a requirement of collecting customer details for a CRM application, then we might need the following information before setting up a customer profile

In the above example, Data modeling involves the process of defining each customer element & it’s the format, how they can be defined in the case hierarchy and how these details can be exposed for reporting requirements.

The best way to define a data model for the above scenario is to create a page property that would extend from “Data-Party-Person” and collect all the details related to the customer. With this implementation, we can reuse all the customer attributes from OOTB class without defining new attributes.

Reporting requirements can be achieved by adding it as a work party in the work class. When added as a work party, we can reuse the OOTB Index rule “Index-WorkPartyUri” for reporting requirements without introducing our own logic of exposing customer attributes for reporting.

Let’s start with our actual discussion !!!

There are many ways in PEGA to access the required data.
> System of record pattern
> Snapshot pattern
> Reference pattern
> Keyed access pattern
> Alias pattern

Let us discuss the alias pattern in this post. Alias pattern is commonly used when playing with large sets of data. It can drastically reduce the effort in manipulating data multiple times.

What is an alias pattern?

Alias generally means having a reference to the actual source. In the same way, alias pattern is about referring one property to another of the same or different types. At run time when the actual value changes, then alias value will refer to the updated version of actual value without any re-computation.

How to implement alias pattern?

Alias pattern in PEGA can be implemented using the “Property-Ref” method.

Where,
LineItems – Actual property -> Page List
RefLineItems – Alias property -> Page Group

Pre-Requisites

1) Actual property and alias property types should be defined in advance. Few examples are,
Page group can have reference to another page list
Value list can have reference to another value group

2) Alias property can be enabled for reference by selecting the below configuration under the “Advanced” tab of the property rule.

Business Scenario

Assume that as part of the CRM application, we are required to collect address details from the customer. Customers should have the ability to add multiple addresses of different types and it is not restricted to be in any specific order. Based on the collected address details, we have specific business logic to implement.

To start off with the implementation, we should first design the data model.

• Defining attributes to collect address
• Defining class for data elements
• Defining the structure of the Data Model

Defining attributes to collect address

We have included few attributes for demo purpose which might grow in case of actual development.

Defining class for data elements

In our case, we can define a data class to contain address related attributes. This data class directly extends from Data-Party-Person to reuse available address attributes.

Defining the structure of Data Model

It’s mandatory to define the data structure for our model. Since the address can repeat more than once, we can have a page list property to hold all the entered address details.

Implementing alias pattern

Information can be collected from the customer using any repeating layouts in PEGA.

As the address details are available in a page list property, fetching a particular address type details from the list becomes complex. Hence a page group property with address type as subscript can be defined as a reference property.

Create a property of the type page group and define it as a reference property for an address list.

“Property-Ref” is used to create alias/reference between source and target properties. The address type can be used as the subscript for the reference property as it becomes easy to fetch a specific address type anywhere when required.

Now, whenever address details in the list get updated, the corresponding page in the page group will refer to the updated property.

It now becomes easy to fetch values of different address types directly from reference property rather than looping through the list and having when conditions to find the same. When an update is made to the specific address type, then alias property refers to the updated value by itself without any explicit logic to copy.

PROS

• It becomes easy to look up items in complex data structures.
• Alias property updates itself when the actual property is updated.

CONS

• When we sort our actual property, then reference to alias property will break. Then we need to delete the alias property from the clipboard and should recreate the reference using the “Property-Ref” method.

Stay tuned for discussions on other access patterns in our later posts