web analytics

Hey there, I am back with another interesting and important topic in PEGA i.e, Datapage. In this post I will be going through basic configurations involved when dealing with the datapage.

Definition

Datapage can be defined as a container for storing data in memory temporarily to eliminate database hits for the same data in future if required. Data in a datapage will be stored in the page structure which is of same as Clipboard.

A datapage comes as part of Data Model category and gets loaded with the data as soon as referred in the flow i.e, no other things are required to populate the data. For this reason, these are also called as Declare Pages. A datapage is always created with the name starting with D_ and this stands for the word Declare.

Point To Note : A page is simply a container of data in the form of name-value pairs. And clipboard is a container many such pages.

Types of Datapages

Data in the datapages can be maintained in two types of structures. This configuration will be made under Structure section in Definition tab.

1. List

  1. Maintains data in the format of list. For example, a list of countries, and details of each country like country name, no. of states etc.,
  2. A list type datapage contains multiple pages each having an index for reference.
  3. Syntax to refer datapage content is <datapage_name>.pxResults(<index_number>).<property_name>

2. Page

  1. Maintains data in the format of a single page. For example, details of the customer like address, date of birth, gender etc.,
  2. A page type datapage contains all the name-value pairs on a single page.
  3. Syntax to refer datapage content is <datapage_name>.<property_name>

Scopes of Datapages

Scope is nothing but the context within which the data can be accessed. PEGA provides three types of scopes for datapage’s. This configuration will be made under Scope section in Definition tab.

1. Thread

  1.  Defines the context for the data in the thread level.
  2. Data can be accessed as many times we want within the thread level.
  3. Datapages storing customer information which are used while processing a case, can be of Thread scope.

2. Requestor

  1. Defines the context for the data in the requestor level.
  2. An example for a requestor context is a user session who logged into PEGA.
  3. A datapage having requestor scope, can be accessed in all the threads that are created in the requestor session.
  4. Datapages storing current logged-in operator details will be an example for requestor type datapage.

3. Node

  1. Defines the context for the data in the node level.
  2. Node context is nothing but the server level context. And the data stored in the node scope will be same for all the users in that node.
  3. An example for a node level is, a datapage containing the stock prices for different markets.
  4. As said above, node level datapages have server node context and therefore to locate the rules used as sources to the datapage, we need to mention Access Group details so that the datapage will take the application context that is pointed by the mentioned Access Group. This configuration will be made under Load Authorization section in Load Management tab and this option is available only for Node scope datapages. Other types takes the context of the logged-in operator by default.

Point To Note : A thread is a small unit of context. A requestor is a collection of such threads. A node is collection of such requestors 🙂

Types of Edit Modes

Once a datapage is loaded, we can change it’s contents based on the below configuration. And this configuration will be under Data page definition in Definition tab.

1. Editable

  1. Contents of the datapage can be modified once loaded through activities,datatransforms etc., just like how we set values to properties.

2. Read-Only

  1. Contents of the datapage cannot be modified once loaded. And when tried to change through property-set in activity/datatransform, you will get an error saying the data is read-only 🙂 (PEGA is very intelligent, it will follow the rules very strictly :P)

3. Savable (New option introduced as part of 7.4, will write a seperate on this 🙂 )

Point To Note : Datapages present under Datapages category in the clipboard are of type Read-Only. And datapages present under Userpages category are of type Editable.

Sourcing a datapage

A datapage can be populated with the following sources and the type of sources will be changed based on the page structure i.e., list/page. And configuration for this can be done under Data sources section in Definition tab.

We can have multiple sources and configure when rule for each source so that datapage will be populated using a source only when it’s associated when rule returns true. Refer to below sample cconfiguration.

1. List Structure

  1. Report Definition
  2. Activity
  3. DataTransform
  4. Connector

2. Page Structure

  1. Lookup
  2. Activity
  3. DataTransform
  4. Connector

Imagine a scenario where the source for the datapage is a connector rule which connects to the external system and the external system is down/not ready yet. In this scenario, to populate datapage with data, PEGA provides an option called Simulate data source. It is nothing but mentioning an alternative source, refer to the below sample screenshot. 

This option is especially useful for the testing purposes as in lower environments (development, testing), connection with external systems will not be proper.

Once a datapage is populated with the data, if we want to do some validation/addition of data, we can take advantage of Post-Processing where we need to mention an activity. This option will be present under Definition tab of a datapage record.

Refreshing a datapage

As said in the starting a datapage will be populated with the data as soon as we refer to the instance 🙂 , but how does a datapage refreshes it’s data if there is any change ?

That is where the configuration for refreshing a datapage comes into action. PEGA provides the following mechanisms for refreshing a data page and we can configure this under Refresh Strategy under Load Management tab.

1. Reload per interaction

  1. Datapage will loaded freshly each time we refer it. Avoid using this option unless it is needed.

Point To Note : For datapages with scope as Node, this option will not be present.

2. Reload if older than

  1. Will configure time period in terms of days/hours/minutes/seconds. After the mentioned time period the datapage contents will be refreshed.
  2. You will also have option to not reload the datapage even though we the mentioned time period expires and this is achieved by mentioning a when condition under Do not reload when field.

In the below screenshot, the datapage is configured to refresh it’s contents for every 6 hours and also the mentioned when rule under Do not reload when section must return false. If it returns true even the time reaches 6 hours of interval, the datapage will not be refreshed with new contents.

Point To Note : Refresh Strategy is only applicable for Read-Only datapages and therefore for Editable datapages, you cannot see this option under Load Management tab. 

Keyed Access Datapage vs Parameterized Datapage

Keyed access datapage works similar to Parameterized datapage. The following table identifies the key differences between both of them.

Keyed Access Datapage Parameterized Datapage
Filtering of the records will be done based on the Keys supplied to the datapage. Filtering of the records will be done based on the Parameters supplied to the datapage.
When examined clipboard structure, the datapage will contain all the records irrespective of the records those correspond to the supplied Key. When examined clipboard structure, the datapage will contain only the records those correspond to the supplied Parameter.
When the key value changes, as all the records are already present in clipboard, no further database hits are needed to search data for the changed key value. The filtering will be done on the available records. When the parameter value gets changed, the database is again searched as the clipboard contains only the records corresponding to previous parameter value.

Below is the sample screenshot showing the clipboard structure for both the types. You can see two instances as part of Parameterized datapage, as we are looking for records of different brand. Where as there will be a single instance as part of Keyed Access datapage. Hope this gives a clear understanding on both of them 🙂

Hope I covered the important configurations while dealing with Datapages.

Please feel free to comment for any add-ons/suggestions/doubts on the topic 🙂 And if you like the post, please share it with your folks to share knowledge to everyone.

Happy Learning !!!

Author - Satish Segu

A passionate and self teaching programmer with lots of love for Android programming. Currently being working as PEGA Developer and posses kowledge in a variety of areas starting from Case Management, Agents, Security, BIX etc., Connect with me through below links.

Happy Learning !!!

Categories: Data ModelPEGA

6 Comments

sabari · March 10, 2019 at 4:38 am

This is wonderful sir…..can you post how to configure backward chaining???

    Satish Segu · March 10, 2019 at 8:52 am

    Hi Sabari,

    Sure, will write a post on the topic soon 🙂

Yaswanth · March 14, 2019 at 4:53 am

Thanks for Posting. It’s very helpful.

    Satish Segu · March 15, 2019 at 2:12 am

    Thanks Yaswanth 😊

naga · May 28, 2019 at 2:07 am

Hi Satish,
Thanks for your valuable time!
as you mentioned the difference between Keyed pages and Parameterized pages can you please little bit more if possible.
Thanks in advance

    Satish Segu · May 28, 2019 at 3:10 am

    Welcome Nagareddy 😊, I will write a post soon explaining on it more.

Leave a Reply

Your email address will not be published. Required fields are marked *