Enjoyed this article? See more similar articles in Constellation 101 series.

Why:

Connecting data from outside sources using REST connectors in Pega Constellation helps businesses stay up to date with real-time information. As companies need fast and accurate data for better decision-making and customer service, setting up data reference fields properly is crucial. This article explains how to get data from REST APIs and use it in Pega applications, making sure they work smoothly and meet business needs. Knowing this process helps keep applications efficient and responsive.

Business use cases:

1. Product Inventory Management: Integrating REST APIs to source product inventory data allows businesses to manage stock levels dynamically, providing accurate inventory details to both staff and customers.
2. Order Tracking and Management: Implementing REST connectors to track order statuses enables businesses to provide customers with up-to-date information about their purchases, improving transparency and customer satisfaction.
3. Financial Data Integration: Financial institutions can leverage REST connectors to integrate real-time financial data into their Pega applications, facilitating better decision-making and risk management.

Prerequisites:

1. REST API Service: Ensure you have a functional REST API to connect to. In this article I will be using https://pokeapi.co as system of record.

Pokémon references are trademarks of The Pokémon Company/Nintendo and used in the article only for educational purposes.

2. Data Object: Create a data object to link with the REST API. Data class type must be concrete. This is important for setting up keys necessary for data retrieval, even if you aren't storing the data in Pega.
3. Data Pages: In Pega Constellation, you can configure dropdowns to not only list items but also show detailed information for selected records, therefore at least two Data Pages are usually necessary: one with a List structure to source the dropdown with keys and a Page structure to retrieve the details of referenced record.

Implementation:

When you query the PokeApi, it responds with a list containing names and links to each resource. This whole list is smaller in size compared to a single Pokemon resource. This example illustrates the concept of having two separate calls: one for retrieving the list and another for fetching detailed information about selected object.

Let's examine a GET response from the endpoint (https://pokeapi.co/api/v2/pokemon/):

In the response, you'll find the "results" attribute, which contains the names and direct URI links for all Pokemon. Each record is identified by an ID number, but the API also allows using the name as a resource identifier, so I'll be using that as the key.

Data pages:

D_PokeDexList – a single-page structure utilizing a connector as its data source to map and store responses from a web service. This data page is optional and its inclusion depends on the chosen implementation strategy.

D_PokemonList – is structured as a list, and if your API allows, a REST connector can be used for direct data retrieval. In my scenario, I used a Data Transform (GetPokeDexList) as the data source, supplying this data page with the D_PokeDexList.results list.

D_Pokemon – a single-page structure that contains the actual resource data. Sourced by a REST connector (PokeDex)

Since SoR is external, select “Is this page used for alternate key storage?” option and link Connector resource path parameters to respective properties.

Best Practices:

Presented use case is relatively simple, but if there's a need to query the Data Page using multiple properties, selecting one of the options in the Query Options section is recommended:

    - Allow querying any column (REST Connector based connections only)

    - Allow query using a JSON object (recommended for queries using many fields)

Next, in load management tab check “Limit to a single data page” reduce memory consumption. It is relevant when the Data Page is referred to with a different set of parameters in the same server interaction.

For more details see: Searchable Data Page, Specifying a data page as queryable

UX configuration

At first glance, data reference fields in Constellation may seem like simple text boxes or picklist controls. However, fields such as Autocomplete or Dropdown are in fact self-referencing properties. which means that the field refers to itself or to another instance of the same data type. This allows for the creation of relationships within the data model, enabling the application to maintain consistency and avoid redundancy.

In the case workflow, the "Catch Pokemon" field was introduced to facilitate user interaction with the dropdown sourced from an external system of record. This field is designed to dynamically reference data, allowing users to select a Pokémon from a list and retrieve detailed information seamlessly.

In the screenshot below, you can note that when an item is selected from a list data page, the key (.CatchPokemon.name) is passed to the D_Pokemon data page.

This field is configured to select a Pokemon from a list and retrieve comprehensive details effortlessly. The screenshot below demonstrates its configuration in App Studio, showcasing how the selected item's key is linked to the corresponding data page, which is shown in the UI instantly thanks to Constellation’s capability to display details.

Conclusions:

Now you should know how to connect external systems of record to Pega Constellation using REST connectors, allowing your applications to leverage real-time data for operational efficiency. The article covers the steps necessary to ensure a functional REST API, create data objects, and configure data pages to effectively source dropdowns for business applications like inventory management and order tracking.

I also encourage you to get familiar with whole CRUD operations in Pega Platform journey in Pega Documentation which covers similar topics