Accessing data with Data Pages
Accessing the accurate data at the appropriate time is integral to successful Case resolution. Data Pages are the bridge between data objects and the Case Type, enabling the application to access data from a range of sources on demand. The data values that are associated with the fields that define a data object actually reside on a Data Page that is cached in the application's memory.
In this topic, you learn about the Data Pages that are available in Pega Platform™, and how they facilitate the transfer of information from the data source to a Case instance.
Data Pages provide the link between the data object and the Data Records that are stored locally in the Pega database, or data that resides in an external system of record. In Pega Platform™ applications, a Data Page act as a translation tool, retrieving data from a specified data source and caching that data in memory. A Data Page manages the integration to the data source, separating business processes from any integration details. This separation allows application developers to use sourced data in an application without knowing the data source and connection details.
The ability to quickly and easily define the data required to build applications and then access that data without having to worry about where the data is actually stored and how it is accessed is called Pega Live Data. Pega Live Data is the virtualization layer separating the application's business logic and data utilization from the technical details of how and when the data is accessed. Data Pages are an important component of the Pega Live Data virtualization layer, declaring how data is mapped from the data sources into an application's data objects.
In the following image, click the + ions to learn more about how Pega Live Data uses Data Pages to load and deliver data to an application on-demand:
Every data object includes three default Data Pages:
- A single-record, read-only Data Page
- A list read-only Data Page
- A single read-and-write Data Page
In the following image, click the + icons to learn more about each default Data Page configured for a data object named Request:
Savable Data Pages
Savable Data Pages save a page or page list of data specified in a Data Page back to its system of record regardless of whether the data is stored locally in the Pega database or an external database. By using a Savable Data Page, you can configure an application to update the system of record in real-time with Case data. The Savable Data Page can manage the transaction to ensure that both systems remain synchronized even if an error, such as a network outage, occurs.
The data save plan for a Savable Data Page details how saves are performed.
In the following image, click the + icons to learn more about the data save options:
The Data save options for Savable Data Pages are configured by System Architects in Dev Studio. As a Business Architect, you work with stakeholders from the Business team to determine the best data save plan for each of the application's data objects, weighing application performance against the importance of updated information to Case resolution, and then communicate that information to the IT team for implementation in your application.
Simulated data sources
Data Pages can be production-ready or simulated based on the status of the external data source. For example, during an application's development phase, the integration with an external data source might not yet be complete. A simulated data source can be used to continue the development and testing of the application's workflow as you await the completion of the integration settings by the System Architects.
Simulated Data Pages do not have an associated data source. You must configure the connection to a data source before the Data Pages are ready for production; however, you can use a simulated data source during application development and testing.
As a Pega Business Architect, you will work with the System Architects to create and maintain simulated data sources during the development of your application.
Data Page refresh strategies
Out-of-date data — also referred to as stale data — can lead to bad decisions, costly errors, and inefficient processes. Keeping the contents of a Data Page current is critical for ensuring accurate, desirable Case outcomes.
For example, in the Online Order application, the Products data object retrieves information about the grocery items that are available for delivery from the supermarket's external system of record. Application developers have a choice about how often the Products data object retrieves that information. The list of available products can be retrieved early in the morning and cached into memory for use throughout the day. This will ensure the application runs quickly, but as the day wears on, there is a risk that the information becomes stale and customers order items that are no longer available.
As a Business Architect, you work with stakeholders from the Business team to determine the best refresh strategy for each of the application's data objects that access information from local or external data sources weighing application performance against the need for updated data, and then work with System Architects to implement that information in your application.
Case Type Data Pages
Case Types also have default Data Pages. Case Types have a single, read-only Data Page and a List (read-only) Data Page.
Because Case instances are automatically saved, the Case Type Data Pages are only utilized when one Case Type is requesting information another Case Type using a Case reference data relationship.
Check your knowledge with the following interaction: