Keyed Data Pages
Data pages provide a performance improvement for Pega Platform™ applications by caching information in memory, rather than querying a data store, such as a database or web service. Data pages typically return either a list of items or information about a single item.
Applications that use data pages extensively can introduce performance issues due to frequent exchanges with a data source. For example, an automobile dealer provides an application that allows customers to browse the current inventory of vehicles and view the details on each vehicle in stock. The dealer notices that the inventory system of record receives thousands of requests each day due to customers browsing the vehicles that are in stock. These recurring queries impact the access to vehicle information on the dealer website, which affects the user experience for potential customers.
To provide instant access to a particular item in a list-structure data page, you can enable keyed access. By using keyed access, you avoid maintaining two separate data pages: one page to return a list of items and a second page to return information about a single item. Using a keyed data page when retrieving data for application use can make processing more efficient by reducing the number of exchanges with a system of record.
In the previous automobile dealer example, the dealer can configure keyed access to a data page listing the vehicles in inventory to reduce the number of queries to the inventory system. The dealer configures a keyed data page that loads the current inventory to a data page on the first request by the customer that day. When a customer changes the selected vehicle, the data is returned from the pre-loaded data page rather than the inventory system, reducing the number of queries to the system of record and improving the user experience.
In the center of the following image, slide the vertical line to compare how the number of database queries can differ between keyed and non-keyed data pages.
Check your knowledge with the following interaction.
Keyed data pages use cases
When deciding whether to use keyed data access on a data page, consider the performance and data management needs of your application. Choosing between a non-keyed configuration and a keyed configuration for a data page depends on the number of requests that occur before the information on the data page is considered stale. Consider the following two use cases.
Use case 1: Non-keyed configuration
A case type for quoting and issuing insurance policies must populate customer information from a system of record. The case type accesses only a single customer record, and the information in the customer record is accessed once for each case.
In this example, the customer information is accessed infrequently, and the case type requires only a single trip to the server to obtain customer information. Because each case focuses on a single customer, information about other customers is not pertinent to the case. In this use case, a keyed data page provides no performance improvement.
Use case 2: Keyed configuration
A caterer provides customers with a case type for customizing menus and dining options for events. Customers make menu selections over multiple steps in the case type. Each step focuses on a specific portion of the menu or dining option, such as appetizers, main course, table size, and chair type. Pricing and inventory information changes daily at most.
In this example, frequent requests for data are expected for each case, and the source data tends to remain unchanged between requests. In this use case, a keyed data page can improve performance by reducing the number of exchanges with the system of record for a single case.
Keyed data page configuration
Keyed access can only be configured for data pages that satisfy specific requirements concerning the scope, mode, and structure of the page.
In the following interaction, click the + icons to learn how to configure a data page to support keyed access.
Want to help us improve this content?