Reference Pattern & Keyed Access Pattern in Pega

Before We Begin

Before getting into the discussion, refer to our earlier post on Alias pattern to understand the basics of Data Modeling in Pega.

What is Data Access Pattern?

As discussed in our earlier posts, to build any application in Pega, we definitely need supporting data. For example, Candidate data for HR application, Customer data for CRM application, Employee data for any IT firm application.

Now, where do these supporting data reside & how efficiently Pega can access those data? 😳 .

Data access pattern available in PEGA helps us access those data. There are different types of access patterns available in Pega.

• Alias pattern
• System of Record pattern [SoR]
• Snapshot pattern
• Reference pattern
• Keyed access pattern

We will explore about the Reference pattern & Keyed access pattern in this post.

What is Reference Pattern & Keyed Access Pattern?

Reference Pattern

• This is one of the most commonly used patterns to access data in our day-to-day implementation. The reference pattern is referencing the data whenever required without having the data in the current case.
• For example, We can source a Country field drop-down in a section using a data page. In this case, we don’t maintain the list of Countries in the case data modeling. Instead, we just reference the data to source the drop-down.
• This way of referring data as a separate entity is known as the reference pattern.
• When implementing the reference pattern, data pages are often node-level/requestor-level since the data is not linked to a specific case and can be shared.

Keyed Access Pattern

The keyed access pattern is one of the advanced methods of referencing the data. Let’s quickly see what is keyed data pages in Pega before discussing its configuration.

Keyed Data Pages

Let’s take a common scenario where we want to fetch list of states based on the country. The usual way of implementing this would be,

• Configure a data type to store the list of countries and their states.
• Write a data page that accepts the country as a parameter.
• Source the data page with report definition to fetch the list of states based on the country name.

Each time when user changes the country, a new parameterized data page gets created which hits the database to fetch the list of states. This will cost a lot in terms of performance 😒

Country and state are entities that will not change often. Then why should we hit the database each time to get the information. Can’t we store this information in temporary memory [Clipboard] and retrieve it back whenever required?

Yes, Keyed data pages helps in achieving that 😎.

In general terms, key is used to identify a record pertaining to one unique value.

In Pega, we can have a data page of the list structure and can access the required information from the existing data page using the key(s) instead of maintaining separate data pages that hit the database multiple times.

For Example, we can have a data page to hold the list of Country and State. We can access the list of states for a given country from the data page by passing the country name as a key.

How to configure a keyed data page

To configure a keyed data page, enable Access pages with user-defined keys in the keyed page access section of the data page rule. The keyed data page access is available only for data pages of the structure list.

• Access pages with user-defined keys – Data page is enabled for keyed page access only when this option is enabled.
• Allow multiple pages per key – This should be enabled only when the result will have more than one record for the selected key. In our scenario, the number of states will be more than one for each country and hence this option is enabled.
  • When Disabled: When this option is disabled, the data page will have only one record for the given key. Hence this can only be referenced in the property of type Page.
  • When Enabled: When this option is enabled, the data page will have more than one record for the given key. Hence this can only be referenced in the property of type Page list.
• PAGE LIST KEYS – The fields defined here will be used as a key to fetch the results. We can even have more than one field defined as keys if required. In our scenario, the country name will be the key since the state list is based on the country name.

How to refer a keyed data page

Keyed data pages can be referred in conjunction with SOR and Snapshot pattern. Below is a sample to reference the list of states using the keyed data page.

Property of Mode page list is created and configured to use Copy data from a data page to reference the list of states using Keyed page access.

Keyed data pages – PROS

• It avoids unnecessary database hits when the parameter changes, thereby enhancing the performance.
• Unlike parameterized data pages, it does not create multiple versions of data pages in the clipboard.

Keyed data pages – CONS

• Keyed data pages can only be referred from property rule. If referred in any other rules like section, flow-action, etc. it acts as a normal data page as we don’t have an option to pass key.

Let’s now explore the configuration & usage of these patterns with a real-time example.

Business Scenario

Let’s consider a call center application built for a telecommunication organization. Customers can call service representatives to request for a new plan. The service representative will explain about all the plans available and its benefits. Customers can select their preferred plan and can request a connection.

In the given scenario, we have two supporting data namely the list of plans and Plan detail of each plan. Let’s now see how best we can access this data from Pega.

Accessing list of plans using Reference pattern

We have configured a data type to store the plan information in Pega..

Now let us see how to show the list of plans in UI using reference pattern in the service request case that service representative creates.

• Create a data page to browse all the plan details. This page will be of structure list [since it will have multiple plans] and scope as node [since this will not change often].

• In the section rule, have a drop-down/autocomplete to show the list of plans and source it with the data page created in the above step.

• Now let’s create a new service request case to verify the drop-down values and the clipboard structure of the data page.

This way of referencing the data whenever required without saving the information as part of the case data model is called a reference pattern.

Accessing plan details using Keyed access pattern

Now let us see how to show the details of the selected plan using the keyed access pattern.

• Let’s enable the data page created above to configure keyed access to ensure reusability. Open the data page D_PlanDataList and configure keyed page access by defining keys. In our scenario, Plan ID that customer selects should be used as key to fetch the plan details.

• Create a Page property with context class as OSP-Data-PlanData and configure it to copy data a data page/refer to a data page, based on the business need. In our scenario, plan details need to be updated in the case and hence copy from a data page is selected.

• UI is configured to show the plan details from the created page property.

• Now let’s create a new service request case and select a plan id to verify the plan details based on the key [Plan1] passed.

The plan details are successfully fetched using the keyed access pattern which avoids unwanted DB hits and multiple data page instances in the clipboard.

Difference between Keyed data page and Parameterized data page

Both the keyed data page and parameterized data page do the same job of fetching the data. But it differs in terms of its execution and usage,

• Keyed page access does not hit DB every time to fetch data but the parameterized data page does.
• Keyed page access does not maintain multiple instances of data page in clipboard but the parameterized data page does.
• Keyed data pages cannot be directly referenced in UI to source a section or drop-down whereas parameterized data page can be.

Pointers to remember

• Reference pattern should be used only when we need data for display which are not required to be persisted in the case.
• Use reference patterns wherever applicable. For example, sourcing a drop-down using report definition is not recommended because each time the drop-down is referenced it executes the report definition to fetch the results. With reference pattern, data gets reused based on the scope of the data page.
• With the Keyed access pattern, we can make a single data page to act as a list and a page based on the key-value configuration.
• When the data page is configured to return multiple pages per key, then it should only be referenced in the property of the mode Page list and vice-versa. If not, the system throws an error.

• The keyed access pattern is recommended only for more static information like State list, Plan details in telecommunication application, Job details in the HR application, etc.
• Keyed page access is available for the Thread/Requestor/Node scope data page. So careful consideration is required to define the scope of the data page.
• Keyed page access is only available for the data page with mode as read-only.
• When using keyed page access, keeping the data page up-to-date should be handled explicitly using the refresh strategy.

With this post we have covered all the available data access patterns in Pega.

Stay tuned for more posts on Data Modeling.

We are glad to publish the article requested by @ Rakhesh on “Data Access Patterns in Pega”. If you want us to publish any articles of your choice, please fill out this form & we will make sure it gets published.