A data page defines the contents of a clipboard page and enables the system to access data from a range of sources on demand.
For example, a section that displays information for a customer can reference the D_Customer data page instead of getting the information directly from the database.
When the system references a data page, the data page creates an instance of itself on the clipboard and loads the required data. Data pages are created when they are first accessed and are not saved to the database. A data page is valid for the period that you define, and the data is reloaded when you access the data page after it has expired.
The name of a data page starts with the prefix D_. The Data Explorer in Dev Studio lists all the data pages that are available for your application.
Scope of data pages
The scope of a data page defines the thread that can access the data page. You can select the scope on the Definition tab of the data page.
A data page scope can be node, thread, or requestor:
- Thread – The page is created in a single requestor thread and can be accessed as often as needed by processing in that thread.
- Requestor – The requestor can access the page(s) loaded across all threads.
Note: For Customer Service chat interactions, associate requestors have their own copy of requestor-level pages. For editable requestor-level pages, changes made in one chat interaction are not seen by other phone and chat interactions.
- Node – Any requestor executing on the current node can access the pages.
Types of data pages
There are three types of data pages:
- Read-only – This is a read-only page available to only one thread, a requestor, or multiple requestors (on one node) in your application. Read-only data pages can be modified only during page load and post-activity processing. These data pages are displayed in the data page list on the clipboard.
- Editable – This page contains initial contents that can be accessed in read-write mode. Editable data pages do not have a refresh strategy or save plan and cannot be node-level in scope. These data pages are displayed in the user page list on the clipboard.
- Savable – This page provides a save plan through a database source or an activity so that users can update data and write to a system of record. Only savable data pages can be referenced in save data page locations, which are areas in the application where you can list data pages to save. For example, you can list the pages to save in flow actions during postprocessing, the Save Data Page shape to use in Case Designer or the Flow form, and the Save-DataPage method to use in activities.
Benefits of using data pages
Data pages can improve performance and reduce memory requirements when many requestors in an application need to access the same information. For example, a data page can hold last night's closing U.S. stock prices in a Value Group property indexed by ticker symbol, so that the property reference D_Stock.Price("IBM") is the closing price for IBM shares. The first time each evening (after the 4:00 P.M. New York stock market close) that a requestor attempts to access the page, Pega Platform automatically loads the page with the latest end-of-day prices. The page can remain unmodified in memory until the next day's closing.
Data pages create only as many instances as requested. When you reference a data page by using parameters, the data page creates a unique instance of itself for each unique reference, which is identified by a parameter value. For example, a single data page, D_Customer, can create as many instances of itself on the clipboard as your application requires. Each instance has exactly and only the information about one particular customer.
Data pages refresh the data only when required. Pega Platform automatically checks the data page contents (by using a when condition rule) before each property access to see whether a fresh recomputation is needed. For example, a page might list the part numbers or SKU numbers of items that are out of stock, extracted from an inventory control system. Recomputation is needed only when an out of stock condition begins or ends, not each time the inventory changes.
Refresh strategy for data pages
The refresh strategy for a data page determines the time period for which the data page is valid. You can define the refresh strategy on the Load Management tab of the data page.
You can define the following refresh strategies for a data page:
- Reload once per interaction – The system refreshes the data page exactly once per user interaction. This option is available only for data pages with a scope of thread or requestor.
- Do not reload when – You can define a when rule for this refresh strategy. If the when rule evaluates to false, the data page contents are refreshed, but never more than once per user interaction.
- Reload if older than – You can define the amount of time after which the data page is considered expired.
- Restricted feature set for high throughput – When high-speed read-only data pages are impacting system performance, you can use a restricted feature set to improve performance.
For more information, see Configuring the refresh strategy for data pages.
Access restriction while retrieving data from data pages
You can assign access control policies to classes which restrict retrieving data from those classes. If a node-scope data page is defined on such a class, a severe guardrail warning is shown. Also, if a node-scope data page is populated and the data page object class has access control policies assigned to it, a severe security alert is shown.
Data pages (known previous to Pega 7 as "declare pages" and "declarative pages") store data that the system needs to populate work item properties for calculations or for other processes. When the system references a data page, the data page either creates an instance of itself on the clipboard and loads the required data in it for the system to use, or responds to the reference with an existing instance of itself.
Both UI and non-UI elements (like data transforms) can reference data pages, without the use of an activity.
- Data page reference
- Creating a data page
- Configuring parameters for loading data pages
- Data page rules - Using the Pages & Classes tab
- Data page rules - Using the Usage tab
- More about data page rules
- Configuring keyed access in a data page
- Savable data pages
- Configuring multiple data sources for a data page
- Changing the data source of a data page
- Handling data page errors by using a data transform
- Robotic automation as a data page source
- Robotic desktop automation as a data page source
- Unit testing a data page
- Read-only data page instance limit management
- Loading data pages asynchronously
- Data pages and parameters
- Removing a data page
- Viewing declarative processing with the Tracer tool
- Assessing the effect of data page processing on performance
- Overriding the default load activity for a data page rule
- Use case: Loading data into a page property
- Use case: Referencing data in a data page by using parameters
- Errors in data sources
- Use case: Loading data into a page list property
- Understanding errors in a data page
- Populating a data page by using a report definition
- Setting the context of a data page
- Understanding invocation errors