You can build a user interface that combines the resources of Pega Platform with an environment that is well-known to users by
implementing Pega digital experience (DX) REST API. To
fully take advantage of Pega DX API endpoints,
understand their request and response elements.
For example, by using DX API endpoints in your external application, you can create
a screen for creating loan requests that displays case details and fields to collect
data. Then, a case worker can work on the request in a Pega application.
The main user interface elements that you can integrate into external software by
using DX API are pages and views. When you build a custom user interface with DX
API, you can use the Live UI tool as you create and process cases
in a Pega test environment. Live UI shows you the page and view identifiers that you need as parameters for API
calls.
Pages in DX API responses
In the API response body, the page element represents the screen that you build with
a harness rule. The value in the name parameter is the identifier of harness. The
following API endpoints return harness data:
GET /casetypes/{case type ID}
Returns the New harness in the creation_page
element.
PUT /casetypes/{case type ID}/refresh
Refreshes and then returns the creation_page
element, or the New harness. Then, the API refreshes and returns the
body of the request in the response.
GET /cases/{case ID}/pages/{page ID}
Returns the indicated harness from the indicated case. For example, for
a Confirm type harness, the value of the page ID
paramater is Confirm.
Views in DX API responses
The view element in the response body represents the part of a screen that you build
with a section rule. The value in the view ID parameter is the
identifier of the view (section). A view can represent an action form for the end
user to complete, such as a questionnaire that a user fills in. Other types of views
might be informational, for example, an audit trail, or functional, for example, a
place to enter notes about the case. A view can contain other views, just as a
section can contain embedded sections. The following API endpoints return section data:
GET /assignments/{assignment ID}/actions/{action ID}
Returns the section for a specified assignment in the view element.
PUT /assignments/{assignment ID}/actions/{action ID}/refresh
Returns the section for a specified assignment in the view element. Then
the API refreshes and returns the body of the request in the
response.
GET /cases/{case ID}/actions/{action ID}
Returns the section for a specified case in the view element.
PUT /cases/{case ID}/actions/{action ID}/refresh
Returns the section for a specified case in the view element. Then the
API refreshes and returns the body of the request in the response.
GET /cases/{case ID}/views/{view ID}
Returns a section for a case.
For example, in your application, you can use a top-level section in a screen where
users create bugs. The following examples illustrates the structure:
Where:
viewID
is the ID of the section record in Pega Platform.
name
is the name of the section as it appears in Pega Platform.
appliesTo
is the name of the class that contains the section.
Additionally, API endpoints that include action parameters build the response from
flow action rules.
The following sample shows the structure of the top-level block that is returned from
the GET /assignments/{assignment ID}/actions/Create endpoint
call:
Where:
caseID
is the ID of the case related to the assignment.
name
is the name of the flow action as it appears in Pega Platform.
actionID
is the ID of the flow action record in Pega Platform.
