Connect Data and Integration Design to Pega Infinity
A validated Data and Integration Design gives Authoring a clear account of what the data means, where it belongs, how the Case uses it, and which dependencies cross the application boundary. Pega Infinity™ carries that intent into connected implementation responsibilities.
Experienced Solution Designers use their understanding of Pega Infinity to evaluate whether the implementation continues to serve the business purpose established in Pega Blueprint™. This enables focused collaboration with Solution Builders as the Data Model, data access, accepted changes, external interactions, and imported application foundation are developed during Authoring.
Follow one design from Blueprint into Pega Infinity
Selected Tour and Determine Tour Viability provide one connected example. In Blueprint, Tour Booking references an existing Tour record and records the need for current Operating Conditions for the selected location and scheduled time. In Pega Infinity, a Data Page makes the selected Tour or available Tours accessible, request and response mapping aligns external weather and tide values with the Pega Data Model, refresh behavior supports the required time context, and the Decision uses those values to determine the next Case path.
The implementation constructs are not the design outcome by themselves. The review question is whether the connected classes, properties, Data Pages, mappings, refresh behavior, connectors, and Rules continue to preserve the business meaning, source responsibility, point of use, and expected Case effect established in Blueprint.
Tip: Trace one business need across both environments. Confirm what Blueprint establishes, what Pega Infinity implements, and which business intent must remain unchanged.
Connect the validated Data Model to Pega Infinity
A well-designed Data Model gives each Field, Data Object, and relationship a clear business purpose. Pega Infinity carries that purpose into classes, properties, data relationships, and Views. The implementation remains coherent when those connected constructs preserve the meaning, ownership, structure, and Case use established in Blueprint.
The following figure shows how validated Data Model constructs in Blueprint translate into corresponding implementation constructs in Pega Infinity:
Review how Tour Booking takes shape in Pega Infinity
Tour Booking brings these constructs together in one coherent design. Number of travelers supports pricing and Determine Tour Viability through a Case property with the Field Type and validation required by those uses. Equipment Assignments remains structured within the Case, while Tour becomes a reusable data class. Selected Tour identifies the Tour Data Record used by the booking. Primary Fields and purposeful Views then present the relevant data when users need it.
Together, these constructs carry the Field definitions, data structures, relationships, and Case use established in Blueprint into Pega Infinity. The next question is how Tour Booking obtains the required Data Records from their intended sources.
Tip: Confirm that the connected Pega Infinity constructs preserve the meaning, structure, ownership, and Case use established in the validated Data Model.
Make the required Data Records available when the Case needs them
The Data Model defines the data that Tour Booking uses. The application may need one Data Record, such as the selected Tour, or a list of Data Records, such as the Tours available for selection. Data Pages make that data available at runtime from local or external sources. Refresh behavior determines when sourced data is reused or retrieved again. Where the source represents data differently from the application, mappings or Data Transforms convert the relevant values into the structure and format required.
|
Blueprint design |
Tour Booking example |
Pega Infinity construct |
Design intent carried forward |
|---|---|---|---|
|
Data Reference Field configured for multiple Data Records |
Tours available for selection |
List, read-only Data Page |
Tour Booking receives Tour Data Records from the intended source that meet the defined criteria and are retrieved again when required. |
|
Data Reference Field configured for one Data Record |
Selected Tour |
Single-record, read-only Data Page |
The selected Tour Data Record is available from its intended source when Tour Booking needs it. |
|
Data Reference Field configured for one Data Record, with an Automation Step that submits an accepted change |
Customer Account details reviewed and amended during Tour Booking |
Single-record Savable Data Page with a save plan
|
Tour Booking can work with proposed changes to the existing Customer Account. Persistence of the accepted changes remains a separate responsibility. |
|
Integration System and Resource with supplied and returned Fields and mapping intent |
Tour location and scheduled time exchanged for applicable weather and tide data |
Request and response mapping or Data Transform |
Business meaning, Type, units, format, and level of detail remain aligned across the Pega and external representations. |
|
Data currency requirement recorded with the source or point of use |
Operating Conditions applicable to the Tour location and scheduled time used by Determine Tour Viability |
Data Page caching and refresh behavior |
Runtime data represents the time or business condition required by the Decision that uses it. |
Review how the Case accesses data
Tour Booking uses different access patterns for different purposes. A list Data Page provides the Tours available for selection, while a single-record Data Page provides the selected Tour. Where the Case supports proposed changes to an existing record, read-and-write access provides an editable runtime representation.
Operating Conditions adds two further responsibilities. Mapping aligns the weather and tide data received from the external capability with the Pega Data Model. Caching and refresh behavior help provide conditions that apply to the Tour’s location and scheduled time when Determine Tour Viability runs.
Tip: Align with the Solution Builder and Lead System Architect (LSA) to ensure each data access design supports its business purpose, including the system responsible for the data, the record or collection required by the Case, access mode, mapping, and refresh behavior.
Save accepted changes
Runtime access and persistence are related yet distinct implementation responsibilities. Tour Booking can hold proposed Customer Account changes while they are reviewed. Once accepted, a Savable Data Page uses its save plan to save the values to the system that owns the Customer Account. Mapping keeps the values aligned where the Case and owning system use different representations.
The Solution Designer defines which changes are accepted, which system must retain them, when they must be saved, and how the Case uses the save result. The Solution Builder refines the save plan, transaction handling, and supporting configuration during Authoring.
Connect outbound and inbound interactions to Pega Infinity
Tour Booking exchanges data and actions with capabilities beyond the application boundary. It can initiate an outbound interaction to request data or an operation, while an inbound event can create or update work in Pega. In each direction, begin with the business purpose and expected Case effect, then connect these to the Pega Infinity responsibilities that support the interaction.
Outbound interaction
Tour Booking initiates an outbound interaction when it needs data or an operation from an external capability. The design must explain what the Case supplies, what the capability returns or changes, and the business purpose that the complete exchange serves.
|
Blueprint design |
Tour Booking example |
Pega Infinity construct |
Design intent carried forward |
|---|---|---|---|
|
Integration System and Resource with the selected operation, supplied Fields, and known authentication or trust assumptions |
Tour Booking supplies Tour location and scheduled time to the Operating Conditions Service |
Connector with supporting endpoint, application and authentication configuration |
The required operation, destination, supplied data, and authentication requirements remain visible for Authoring. |
|
Expected result, returned Fields and documented mapping intent |
Applicable weather and tide data returned for the requested location and time |
Connector response mapping or Data Transform |
Mapping converts the returned data into the structure and format required by the Pega Data Model while preserving its business meaning. |
Operating Conditions brings the outbound interaction together. Tour Booking sends the Tour location and scheduled time through a connector. Mapping converts the returned weather and tide data into the structure required by the Pega Data Model, and a Data Page makes it available to Determine Tour Viability. Together, these responsibilities support the complete business interaction.
Inbound event
An inbound event enables an external party or system to initiate work in Tour Booking. Pega receives the event, uses its data to create a new Case or identify an existing Case, and returns a response that reflects the outcome.
|
Blueprint design |
Tour Booking example |
Pega Infinity construct |
Design intent carried forward |
|---|---|---|---|
|
Inbound Event with category, sending system, business purpose, exchanged data, and known authentication or trust assumptions |
An approved partner submits a booking request or change through a partner API |
Service or other supported inbound entry point with authentication configuration |
The event source, business purpose, exchanged data, expected Case effect, and known authentication or trust assumptions remain visible for Authoring. |
|
Affected Case Type, Create or Update intent and matching information |
Create a Tour Booking or locate an existing booking using an accepted identifier |
Case creation, routing, matching and correlation behavior |
The event affects the correct Case while preserving identity and repeated-event expectations. |
|
Expected response, unsupported-request path and follow-up |
Confirm acceptance of the partner request or direct it for investigation |
Response, exception, recovery and Workflow behavior |
The event creates or updates the intended Case while preserving identity and repeated-event expectations. |
A partner booking request brings the inbound interaction together. A service, listener, or channel receives the request. Matching behavior creates a new Tour Booking Case or identifies the existing Case, while response and recovery behavior communicate the outcome and guide the next action. Together, these responsibilities support the complete business interaction.
Review the complete interaction
Outbound and inbound interactions begin on opposite sides of the application boundary. In both directions, the Solution Designer maintains a clear view of the business purpose, exchanged data, expected Case effect, and response. The Solution Builder refines the supporting configuration, mappings, authentication, matching, exception handling, and recovery behavior during Authoring.
Tip: Align with the Solution Builder and LSA to ensure each interaction preserves its business purpose from initiation through to the expected Case effect and response.
Understand what Blueprint import provides
A high-fidelity Blueprint gives the delivery team a strong implementation starting point. Blueprint import creates an initial Pega Infinity application foundation from supported design elements. The target application, selected import scope, and import choices influence what is created or connected.
The delivery team reviews this foundation against Blueprint before Authoring progresses. For Data and Integration Design, confirm that imported or connected Data Objects, Fields, relationships, and available configuration preserve the intended business meaning and application structure.
Authoring then develops the source, currency, mapping, saving, outbound interaction, inbound event, authentication, matching, response, and recovery responsibilities.
Tour Data Object example
The Tour Data Object shows how Blueprint import carries a validated design into Pega Infinity. The import creates or connects the supported Fields and relationships. The team validates that this foundation preserves Tour’s business meaning, key attributes, relationship role, and intended reuse, then refines its data source and runtime access during Authoring.
Tip: Review the generated application foundation against Blueprint. Confirm that the imported or reused assets preserve the agreed business intent, then align any required refinement with the Solution Builder and LSA during Authoring.
Summary
Pega Infinity carries the validated Data and Integration Design into implementation. Classes, properties, relationships, and Views represent the data; Data Pages make the records required by the Case available; Savable Data Pages support saving approved changes; and connectors and services enable interactions across the application boundary.
Experienced Solution Designers work with Solution Builders to keep these implementation responsibilities aligned with the business meaning, ownership, source, Case use, and expected outcome established in Blueprint. Blueprint import creates the application foundation, which the team validates and progressively refines during Authoring.
The Design Review Challenges now bring these responsibilities together. They trace consequential dependencies across the complete design, identify where business intent needs focused refinement, and prioritize the changes that most increase delivery confidence.
Knowledge check
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?