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.
Match the numbers to the following image to see how using a keyed Data Page reduces the number of database queries:
- Browse vehicles: Using a keyed Data Page reduces the number of database transactions, allowing the customer to view as many different combinations as they choose, without affecting database performance.
For example, an automobile dealer configures keyed access to a Data Page listing the vehicles in inventory to reduce the number of queries to the inventory system. The dealer configures the application to load the current inventory to a Data Page on the first request by the customer that day. When the customer changes the selected vehicle, the data is returned from the pre-loaded Data Page rather than from the inventory database, reducing the number of queries made to the system of record and improving the user experience. -
Change options: Each line in the Browse vehicles Case represents the customer selection of a different vehicle type, color, model year, and price. The application accesses the data from keyed Data Pages instead of making a trip to the system of record for each selection.
Without a keyed Data Page, the application is required to access and return data from the database for each selection, potentially slowing application performance for all users. -
Keyed Data Page: Keyed Data Pages are used to reduce the number of trips required to obtain data from a database. On the first request, the data is pulled into the Data Page. Because the Data Page uses a key, additional trips to the system or record are not required unless the source data changes.
-
Database: SOR represents the database that houses the source data, including the vehicle type, color, model year and price. The data may be housed externally in a client legacy system, or in a third party database, such as a manufacturer's website, accessed through an interface.
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.
Match the numbers to the following image to see how the Data Page accesses the system of record without keyed data access:
- New insurance quote: When a customer requests an insurance quote, a new insurance quote Case opens, and the application loads a non-keyed Data Page to populate the customer's information.
-
Another new insurance quote: Each new insurance quote is unique to the customer who requested it.
-
Data Page: The Data Page stores the customer information, such as their date of birth and driver's license information, used during the quoting process. As the customer information is unlikely to change during the quote, there is no need to make multiple trips to the system of record. A non-keyed Data Page works well in this scenario.
-
Database: The system of record stores insurance customer information, including name, date of birth, and contact information.
When a new insurance quote is opened, the Data Page checks the database to see if the customer exists. If the customer exists, the database provides the customer data to the Data Page.
If the customer does not exist, the Data Page is configured to write a new customer record to the database.
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.
Match the numbers to the following image to see how a keyed Data Page improves database performance by reducing the number of database interactions:
-
New catering order: When a customer requests catering, a new catering order is opened using a keyed Data Page pre-populated from the system of record with menu options, table sizes, chair types, and pricing.
-
Customer choices: As the customer chooses different options for their catering event, such as appetizers or decor colors, the application provides a list stored in a keyed Data Page. Additional trips to the database system are not required, as all the data needed for the Case is pre-loaded into keyed Data Pages.
-
Database interactions: The Data Page accesses the catering options for the Case only once because the catering options, including menu, chair types, and table sizes, do not change frequently. Once the customer finalizes options for their catering event, the Data Page writes a new record to the database to store the client's catering event selections.
-
Database: In this example, only one database or system of record is shown.
However, your application may require multiple databases to support a Case Type, such as one database that stores catering locations, another that stores tables, chairs, and linen inventory, and a third that contains catering staff schedules.
Reducing the number of times your application accesses databases to populate the Data Page can significantly improve your application performance.
Check your knowledge with the following interaction:
This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?