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:

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.