Pega Interview Concepts on Integration Management
What are the different types of authentications allowed as part of connecting to a service provided?
BASIC Authentication is used to store the external service provided user name and password in an Authentication profile and refer to the same in the connect rule forms.
OAuth Authentication is a two-step process verification
Step 1: Register the OAuth2.0 Client Registration rule with the service provider Client ID and Client Secret Key.
Step 2: Retrieve the token using the OAuth Service Provider service.
How does it work?
Connect Service will retrieve the token using the provided Client ID and Client Secret Key, then the token is passed as part of the actual service call in the header. Token will have an expiry defined at the service provider end. The majority of Google, AWS, and Facebook products come with this type of authentication.
How is the SSO Authentication is implemented through SAML Integration?
SSO- Authentication Service is used to log in through windows active directory credentials.
- Provide Identify Provider Metadata Information that we got from Windows Active Directory — Entity Identification URL, Login Location and Logout Location. This information is specific to the Windows Active Directory environment.
- In the mapping tab, map the information from the SAML fields to the OperatorID Page fields
- There are two activities that are present — Pre-authentication and Post-authentication processing activities. In the Post-authentication processing activity, we can perform the save of the OperatorID Page to save information mapping from the SAML file to the OperatorID Page.
What is the CORS (Cross-Origin Resource Sharing) Policy?
The Cross-Origin Resource Sharing policy is allowed to define the allowed origins (kind of whitelisting the IP’s), allowed headers, allowed methods, and credential usage for a specific REST Service.
Map the CORS record to a service rule.
What are the connect and service request processors?
The connect and service request processors are used for the asynchronous processing of connect-soap or service-soap calls. These are the queue data instances, processed by the PEGA-Intsvcs agents.
What are the different ways that we can invoke a connector service?
They are three different ways as follows
Run: Synchronous way of invoking a service
The design approach for invocation: In the invoke activity, call the Connect-REST in run mode
Run in Parallel: Create a pool using the Load-DataPage or Call-Async-Activity methods and execute the multiple service calls in a parallel mode. This execution mode creates the child requestor from the current requestor.
The design approach for invocation: Use the Connect-Wait method, to wait for all child requestors to complete processing and merge into the current requestor.
Queue: This mode is for Asynchronous processing.
The design approach for invocation:
Step 1: Create the Connector Requestor instance with the custom System Queue class. Refer to this instance as the Queue Processing Option in the Connect-REST/Connect-SOAP instance.
Step 2: Call the Connector service in the Queue mode in the invoke activity. As part of the execution, it will create the System Queue class for processing. Pega-IntSvcs Agent Connector standard agents process these requests.
Step 3: As part of the case design, invoke this connector in the queue mode. Then place the assignment in the waiting queue workbasket. Create the advance agent to process the System Queue class instances with Success status. This advance agent will progress the case to the next step.
LSA Level
How to extend PEGA service to another consumer with different authentication?
Detailed context: PEGA Application exposed a service to one consumer with OAuth authentication. A new consumer wants to leverage the service with basic authentication.
Option #1: If we have a middleware like AWS API Gateway / APIGEE then that layer will handle this transformation. But, this adds a network latency.
Assumption: There is no middleware and clients are hitting the PEGA App directly.
Option #2: Create a separate service package for the new consumer. This option adds overhead maintenance. For single service rest operation, we are maintaining two different service packages.
Option #3: In this case, have a custom authentication service for the service package — then conditionally handle both authentications in the respective authentication activity. This option avoids network latency and overhead maintenance.
Option #3 is recommended.
How to orchestrate the dependent API calls to have better performance?
Scenario: In customer service applications, need to pull confirmation from different sources. But, we have a dependency that every API is dependent on one or another API response.
Let’s say an example of API dependency is customer details are from one source and then the customer address is from a different source — To pull the customer address we need to pass the response details of customer details API.
Option #1: Generally, to provide better UX and to have a better performance approach — All data pages are loaded ahead asynchronously using Load-DataPage with a Pool ID and then defining a Connect-Wait method on the Pool ID. Here the con is all D Pages should be independent of each other.
In the above scenario, the APIs are dependent.
Option #2: Load the information on demand. For example, implement a tabbed UI approach. On click of the address tab — then only invoke the D Page to display the information.
Option #2 is recommended.
