Page scope types for data and declare pages
The fields on a rule form's Definition tab depend on the page scope value selected.
- Data page (Pega 7 Platform)
- Declare page (PRPC versions 5.1 - 6.3 SP1)
Data page
Data pages are used in the Pega 7 Platform. The page scope can be Node, Thread, or Requestor.
- Node – any requestor executing on the current node can access the pages.
- Thread – the page is created in a single requestor thread, and can be accessed as often as needed by processing in that thread. Access by separate requestors causes the rule to create distinct pages, which might have different contents.
- Requestor – all threads for the current requestor.
Declare page
Declare pages are used in PRPC versions 5.1 - 6.3 SP1. The page scope can be either Node or Thread. Starting in PRPC 6.2, the page scope can also be Requestor.
Node page scope
If a Declare Pages instance is defined as a Node page scope, it displays on the clipboard in the same area as other node-level pages (such as pxProcessPage), and is shared across all of the requestors for that node.
Configuration settings for using the Node page scope
In a cluster or multi-node system, each node has its own copy of the clipboard pages created by this Declare Pages rule. For each node, the first user to reference the Declare Pages instance causes the load activity to run on that node, creating the page on the clipboard.
For a multi-node system, depending on when the first user runs the load activity on the node, and what refresh rate is specified for that Declare Pages instance, the pages created on each node for this instance might not be exactly identical to each other at every second. However, because they all use the same rule definition in the system for this Declare Pages instance, the pages on each node across the system should have similar information.
The Access Group field on the Definition tab is used to establish a common authorization context for loading the pages so they can be shared (see Data pages - Understanding the access group field). Like the code generated from the Rules Assembly process, the declare pages for each node are identified by a hash code based on user ruleset lists.
Because Declare Pages instances all have unique names in the system, there are not different instances in different rulesets; however, there might be different versions of a Declare Pages instance in the system.
Additionally, although the Declare Pages instance itself must have unique names and call one Load Activity, different definitions of that activity (with different data to load) can be saved in different rulesets, with the appropriate activity chosen at run time by rule resolution.
Thread page scope
If a Declare Pages instance is defined as a Thread page scope, it is loaded and maintained in each thread that references this page name. If a requestor has multiple threads, then each thread has its own instance of this page.
This page scope type provides clipboard pages that are created when needed and are dependent upon the current work item context that exists. Additionally, this page scope type allows the use of the Refresh Page When field on the Definition tab for a Declare Pages instance.
For example, a call center might want to include historical customer data from an external customer information database when a call work object is opened for a caller. Because each operator in the call center can handle a call from any customer at any time, the external customer information must be specific to each operator’s work object. Accordingly, a CustomerInfoPage shared across operators would not be useful, and the CustomerInfoPage must be individually populated for each operator's current work object.
Configuration settings for using the Thread page scope
A requestor can have one or more threads, which are where the work and user pages are stored (such as pyWorkPage). A user could have multiple Threads if they are working on multiple work objects, or have spawned off a new portal screen. Most of the time though, the typical requestor only contains one thread.
In some cases, it is simpler to create an embedded page in the work object for external information, rather than using a Declare Pages instance (for example, the Data-Party page). However, if customer data is fetched from an external system, and other applications are updating that external data, it is important to make sure that PRPC reflects the most recent information. In such cases, rather than creating an embedded page to hold the data, create the declare page and set it to refresh the page at a useful interval.
- Although a declare page with a Thread page scope is limited to one Thread in one requestor, once the data has been loaded onto that page, the page is still read-only.
- The rules that define and load the page (the Load Activity and the rules that it calls) are subject to rule resolution based upon the loading requestor’s ruleset.
Requestor page scope
If a Declare Pages instance in PRPC 6.2 - 6.3 SP1 is defined as a Requestor page scope, it affects the usage of tabs in PRPC. This is because each work object opens in a tab, which is a thread, and all tabs are located under the same Requestor page scope.
Configuration settings for using the Requestor page scope