Keyed Data Pages
Data pages provide a performance improvement for Pega Platform™ applications by caching information in memory rather than querying a data source, 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 might 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 (SOR) receives thousands of requests each day as customers browse the vehicles that are in stock. The high volume of database queries impacts the access to vehicle information on the dealer website, which affects the user experience for potential customers. Each time a customer selects a different combination of vehicle type, color, model, and price range, the application makes a trip to the database and updates the data page.
To provide instant access to a particular item in a list-structure data page, 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 makes processing more efficient by reducing the number of exchanges with the system of record.
Click the + icons to see how using a keyed data page reduces the number of database queries.
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 populates 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 the following new insurance quote case 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.
In the following image, click the plus + icons to see how the data page accesses the system of record without keyed data access.
Use case 2: Keyed configuration
A caterer provides customers with a case type for customizing menus and dining options for events. Customers make catering selections over multiple steps in the case type. Each step focuses on a specific portion of the event, such as the menu or dining option, appetizers, main course, table size, and chair type. Pricing and inventory information changes daily at most.
In the following 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 improves performance by reducing the number of exchanges with the system of record for a single case.
In the following image, click the plus + icons to see how a keyed-data page improves database performance by reducing the number of database interactions.
Keyed data page configuration
Keyed access can be configured for data pages that satisfy only 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.
Check your knowledge with the following interaction:
This Topic is available in the following Module:
Want to help us improve this content?