REST API Series Part 3.1: Connecting to a GET API in Pega

This video focuses on connecting to a REST service where Pega acts as a consumer, specifically using a GET API.
Strong recommendation to watch Part 1 and Part 2 of the REST API series to build a strong foundation.
The presenter plans to enhance the series to cover different aspects of API interactions with hands-on examples.

Two main rules for Pega and API integration:
- Connect REST: Pega consumes external APIs.
- Connect Service: Pega exposes APIs for external consumption.

Goal: Create a connect REST rule in Pega to consume an external GET API.
Start with a simple GET application before moving to more complex POST applications.
Example API URL: https://dummy.restapiexample.com/api/v1/employee/{id}. The actual URL is https://dummy.restapiexample.com/api/v1/employee. The ID is passed as a parameter.
Construct the URL with a parameter: https://dummy.restapiexample.com/api/v1/employee/{ID}.
Building the REST API:
- Navigate to Configure > Integration > Connectors > Create REST Integration.
- Four tabs are available in the wizard.

First tab: System Details.
- System Name: Give a meaningful name (e.g., Employee).
- Endpoint URL: Input the constructed URL.
Pega automatically interprets the URL and provides options.
- Resource path parameter: Part of the URI (e.g., {ID}).
- Query string parameter: Anything after a question mark in the URL.
Parameterization options:
- Pega identifies {ID} as a parameter.
- Option to parameterize other parts of the URL, but in this case, only the ID is needed.
Additional options:
- Query string parameters: Add if present in the API.
- Headers: Add if the API requires headers.

Second tab: Resource.
- Resource Name: Describe the resource (e.g., Get Employee ID).
- HTTP Method: Choose from GET, POST, PUT, DELETE, and PATCH.
Overriding options:
- Ability to add headers or query string parameters that were missed in the first tab.
Data Model:
- Defines how the data is structured.
- Example response structure: status, data (containing employee details), and message.
Creating the Data Model:
- Option 1: Add a REST Response: Pega hits the API and automatically captures the data model.
- Option 2: Add a File: If the API is down, copy the JSON structure into a file and upload it.

Final step: Review.
Two layers in Pega for API consumption:
- Integration Layer: For integration with external systems.
- Data Layer: For holding the data that is to be consumed.
Rule placement:
- Integration Layer: Typically placed in the organization layer with a parent class like XYZ-Int.
- Data Layer: Used to hold data for processing.
Class and Rule Names:
- Connector Name: (e.g., getEmployee).
- Data Page Name: Should be consistent with the connector name for easy searching.
Ruleset Version:
- Integration Layer rules should go into the INT ruleset version.
- Data Layer rules should go into the data ruleset version.
- Important: Coordinate with the team lead to decide on the appropriate ruleset version.
Branch Development:
- If working on a branch, the version is omitted until the branch is merged.
Character Limit:
- In older versions of Pega (e.g., 6.2), class names had a character limit of 25. Ensure names are within this limit to prevent null pointer exceptions.
Undo Generation:
- If something is created incorrectly, use the Undo Generation feature to delete all created rules.
- If the wizard is closed, use Configure > Integration > Tools > Wizard Cleanup.

Pega generates multiple classes based on your specifications.
Key classes to focus on:
- Integration Class (e.g., XYZ-Int-Employee).
- Data Class (e.g., XYZ-Data-Employee).
Request and Response Data Model:
- Request Data Transform: Used to format the request.
- Response Data Transform: Used to format the response.
Example Data Model:
- Request (ID).
- Response (status, data).
Data Pages: A data page is created (e.g., D_GetEmployeeID) to hold the response. dgetEmployeeId is a database that will be used to do all the magic.

In the data layer:
- Having ID is not required, as the data layer is all about response modeling, the ID is required only for request.
- So the data layer only cares about the response.
Data pages
- It will creates data pages, such as dgetEmployeeId will create a data.
Data Transform
- In data layer you will get the response data transform.
- In integration layer, you will get the request data transform.
First the request data transform will be executed.
All the requests are going to become part of the int layer
The connect rest tool will be executed and the int layer class is assigned to the external API property.
Once the class executed we get all the response which comes from the response underscore gat property which comes from the int class all this will be executed using the response data transform which helps to copy int class data to data class so it can be implemented on work layer.
Database rules
- When connect rest will be running, database will be created.
- We can connect to different activity data transform as well.
- This source will be connected to connect rest.
- There will be connect rules.
- There will be request data trasnform.
- There will be been response data transform.

Running and testing of data transform:
- Run by turning on the tracer.
- Pass the parameter, for example, if you pass $1$ the details will be $$