I85PREP
⌘ K
Pega CPSSA study materials
Pega CPSSA study resources

Pega CPSSA: Data management in Pega CPSSA

Pega CPSSA · Work through your exam, one topic at a time.

All guide sections

Data management in Pega CPSSA

What the domain tests

Data management covers how a Pega application models, retrieves, caches, maps, and persists data. Senior architects are tested on data types, data pages, data transforms, data sources, scope, refresh, and write-back behavior.

Core rules

  • A data type is a reusable data model backed by a class; case types and data types should not duplicate the same customer or product structure.
  • A data page is a named clipboard page with a data source. Its scope determines sharing: thread, requestor, application, or node. The broader the scope, the more carefully you must handle requestor-specific data.
  • Refresh strategy is a design decision: every request is fresh but costly; reload-if-older balances freshness and load; manually refreshed pages need an explicit refresh path.
  • Use data transforms for mapping, defaults, and page updates; avoid using activities for simple mappings.
  • Include all parameters that identify the data in the data page key. Missing keys cause one requestor to see another's cached record.
  • For writes, use a savable data page or a deliberate save path; do not assume a read-only data page will persist changes.

Worked example

A service case needs a customer profile and that customer's open orders. Model D_Customer as a requestor-scoped data page sourced by a connector, with reload-if-older-than 15 minutes; the customer ID is a parameter and part of the key. Model D_OpenOrders as a thread-scoped, parameterized page keyed by CustomerID, because orders are viewed only during the interaction. When the agent edits the mailing address, use a savable data page or a data transform plus connector to persist, then refresh D_Customer. Reasoning: profile data is reused across cases for the same requestor but must not be stale for long; order data is interaction-specific and parameterized to avoid cross-customer cache collisions.

Traps

Using application scope for operator-specific data is a common security and correctness defect. A data page without the correct parameters can return the first cached result for every key. Treating a data page as a transactional store loses updates. Overusing every-request refresh creates avoidable integration load.