Pega Digital Experience API

Pega Digital Experience provides a consistent and branded experience across channels. Pega Digital Experience (DX) API is a set of model-driven REST API endpoints that enable the ability to view, create, and update cases and assignments programmatically. It allows developers to build a custom front-end experience for Pega Platform™ applications without encoding business logic into each channel. Pega Platform provides REST APIs that you can use to populate your non-Pega Platform user interface. The response APIs include the UI elements, layouts, actions, and styling, thus making it different from the traditional API.

These REST APIs are known as digital experience APIs because they leverage Pega Platform user interface rules (harnesses and sections) together with Pega Platform business rules to return JSON-equivalent structures that you can render with your native interface. For example, while making a Vehicle purchase, the vehicle details are captured on the screen. The response API includes all the details of how the details were captured, and it mimics the same on the rendering UI. 

The DX API version 2 mainly focuses on view-based authoring. It lets you manage data views to explore metadata and retrieve specific fields using data view endpoints.

As a lead system architect (LSA), one has to ensure that the application is DX API compliant. The compliance ensures that developers build an appropriate front-end component in the UI system of choice and supports the principle of center-out architecture. Following are a few guidelines to consider while designing an application using DX API's:

• Harnesses must use a screen layout as the top container.
• Visibility expressions must consist of only references to when rules.
• Sections should be auto-generated.
• Sections should use one of the following layouts:
  • Table
  • Dynamic layout
  • Repeating dynamic layout (not sourced from data pages)
  • Embedded section
• If a flow action uses editable pages (named pages, thread-level data pages, or requestor-level data pages), edited values are not available in post-processing data transforms or activities. In such cases, use the pattern of auto-populated properties (which obtain data from data pages) and savable data pages in post-processing of flow actions.
• Applications are to be always configured to use optimistic locking
• V2 DX API tests require authorization to generate a sample response to an endpoint call. You need an OAuth 2.0 client registration data instance.

The following enhancements are found in DX API version 2:

•     New endpoints have been introduced, and the structure of messaging now separates the data and layout. 
•     Applications using the View-based approach benefit from DX API v2 centered around App Studio and views.

Security Settings for DX API

The DX API endpoints need to be accessed securely. Authentication settings and access role privileges provide secure access.
Authentication settings are provided for the Service Package. The following types of authentication are available for a service package:

• Basic
• OAuth 2.0
• Custom

To access endpoints more securely, use OAuth 2.0 as the authentication type.

Access role privileges; every endpoint is mapped to a privilege. You can provide users with specific privileges to perform the actions associated with the corresponding endpoints.

The privileges are included with the PegaRULES:PegaAPI access role. By default, this role is available only to the Administrator and Author access groups. To grant a user access to the DX API, add the PegaRULES:PegaAPI access role to the user's access group. Additional privileges can be given to enable field-level security while performing specific actions.

For more information on DX API, see the following Pega Community and Pega Academy content:

• DX API Version 2
• Pega User Experience (UX) Essentials
• Creating custom screens with the digital experience APIs