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.
- 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
Rules can reference data pages directly or by using auto-population properties to obtain quick access to data.
- Creating a data page
To enable your system to access data from a range of sources on demand, create a data page. 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 US stock prices in a Value Group property that is indexed by a 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
- Configuring parameters for loading data pages
Define the behavior of data pages in your Pega Platform application when the cache is no longer valid. For example, you can indicate that the data is no longer valid after a certain amount of time, or set Pega Platform to reload the page the first time a user interacts with it.
- Data page rules - Using the Pages & Classes tab
Leave this tab blank unless you entered a fully qualified property reference as the value of a parameter for the activity specified on the data page's Definition tab in the Activity name field.
- Data page rules - Using the Usage tab
This tab displays rules that are currently using the data page. The scope of this list is all applications in your application's stack.
- More about data page rules
Benefits of using data pages
- Configuring keyed access in a data page
To provide instant access to a particular page in a list-structure data page, enable keyed access. For example, you can easily access a list of products with an embedded page that holds information about a particular product.
- Savable data pages
Use a savable data page to save data to a system of record without using an activity.
- Configuring multiple data sources for a data page
Configure multiple data sources in your data page and set parameters that determine which data source to use, so that your application gets the right data every time. By setting parameters in your data page, you eliminate the labor and maintenance cost of creating and maintaining hard-coded calls for data.
- Changing the data source of a data page
You can easily change the data source of an existing data page without creating a new data page. For example, if you are currently using an activity to populate your data page, and you want to retrieve data from an external source instead, you can change your data source to a REST connector.
- Handling data page errors by using a data transform
To specify error handling for each data source in your data page, use a data transform. You can use this data transform across multiple data sources and data pages in the application. For example, with an activity data source, the same data transform can be used to handle data page errors.
- Robotic automation as a data page source
Robotic process automations (RPAs) are automations that run in the back office. For example, you can use an RPA to obtain a credit score from a legacy system that you can then display on a Pega Customer Service application account overview dashboard.
- Robotic desktop automation as a data page source
A robotic desktop automation (RDA) runs on client desktops and automates tasks and workflows. You can use an RDA as a source for a data page when the data page is requested from a browser on a Microsoft Windows client that is running Pega Robotics™ Runtime.
- Unit testing a data page
Test a data page to ensure that you get the expected results by using the Run Rule feature before testing it in the context of the application that you are developing. Additionally, you can convert the test run into a Pega unit test case for reuse.
- Read-only data page instance limit management
Change the maximum number of read-only data page instances to manage when older instances are deleted.
- Loading data pages asynchronously
Allow users to take action on a work item while other content is still being loaded by loading data pages asynchronously.
- Data pages and parameters
Parameters can be passed to data pages from several sources:
- Removing a data page
Cause a data page to refresh the next time it is accessed by removing or forcibly expiring the data page.
- Viewing declarative processing with the Tracer tool
The Tracer tool is used to display information about when a load activity starts and about each reference to a data page. To view declarative processing (by your own requestor session) with the Tracer tool:
- Assessing the effect of data page processing on performance
To assess the effect (in your own requestor session) of data page processing on performance, access the Performance tool and review the Full Details display. This page includes three elapsed times statistics, three counts, and three CPU time statistics:
- Overriding the default load activity for a data page rule
The standard data page rule Declare_CachedDataSystemSettings creates a Node-scope declare page containing your system settings that is refreshed every 10 minutes. Because no database accesses are required, fetching a value from this in-memory page by referencing a property is faster than using PublicAPI functions.
- Use case: Loading data into a page property
In Pega Platform, data pages can provide automatic data access, populating page and page list properties with data relevant to the circumstances. A case, another data page, or some other data object can use a property to automatically access the data that it needs from a data page.
- Use case: Referencing data in a data page by using parameters
Data pages provide quick, accurate access to the data that your application needs. Calling data pages with parameter values lets the data page provide exactly the data required for a situation, from the most appropriate data source, on demand. The system waits until a user action or some other trigger causes a data request, and then loads the data automatically.
- Errors in data sources
Data source errors occur during the execution of a data source, and cause the data source to return incorrect, flawed, or missing data.
- Use case: Loading data into a page list property
In Pega Platform, data pages provide automatic data access, populating page and page list properties with relevant data. Cases, other data pages, and data objects can use a property to automatically access the data needed from a data page.
- Understanding errors in a data page
Data pages store the data that cases use for populating properties, calculations or other processes. Developers determine where that data originates and how it gets to where it is supposed to be by defining data sources on the data page record.
- Populating a data page by using a report definition
Data pages organize and make data from a range of sources available to your application. The data sources available include data transform, activity, connector, database lookup, robotic automation, robotic desktop automation and report definition. Report definition allows you to make your reports more adaptive and flexible by customizing them with various options. For example, you can add custom columns to your report, and then include a chart to make data analysis more efficient.
- Setting the context of a data page
A single data page can create many instances of itself and tailor each instance to the context in which you are using it in the application. This process simplifies creation and maintenance of your code, since one data page can serve multiple references.
- Understanding invocation errors
Data page errors occur for a variety of reasons, all of which prevent data from loading as expected. Invocation errors prevent requested data pages from loading correctly.