Integration set up

The integration architecture in SDAA follows a structured approach that promotes usability and simplifies implementation. When you connect your application with different payment type services, you establish a communication channel that enables automated data exchange throughout the dispute resolution process.

The following diagram illustrates the high-level design and approach for implementing the service:

The architecture consists of several key components that work together to facilitate this integration.

Service configuration

At the heart of the integration framework is the Service config <payment type> Data Type. This component defines the parameters for each payment type service your application needs to connect with. Each record in this data type represents a specific service and contains essential information:

• Service Name: The name of the service.
• Service Description: A description of the service.
• Service URL: The URL of the service.
• Request Data Transform Name: The name of the service request Data Transform Rule.
• Response Data Transform Name: The name of the service response Data Transform Rule.
• Service Type: The payment type service type (Service Inquiry or Transaction Inquiry).
• HTTP Method: The REST service method type.
• Simulation Data Transform Name: The name of the service simulation Data Transform Rule.
• Is Multi-Part Request: A Boolean value that identifies whether the application can send attachments or supporting documents as part of this service.
• Is Active: A Boolean flag that indicates whether the service is active and currently in use.

The following figure shows an example, the Service config Visa Data Type:

Connector flow

The integration framework uses specialized flow Rules to manage service invocation:

• Invoke<payment type>Connector: The system creates this flow Rule on the PegaFSPE-Work class layer to invoke payment type services. This flow Rule accepts ServiceName as a parameter to facilitate the invocation of the Payment type services.

The following figure shows an example, the InvokeVisaConnector flow:

• InvokeRESTConnector: The system creates this generic flow Rule has to invoke REST services in the Smart Dispute applications. InvokeRESTConnector takes ServiceName as a parameter to facilitate the invocation of the services.

The following figure shows the InvokeRESTConnector flow:

When the Smart Dispute application invokes payment type services, the following process occurs to integrate with the payment type system:

1. The system runs the Invoke<payment type>Connector flow Rule and passes the ServiceName parameter to the generic InvokeRESTConnector flow Rule.
2. The system usesthe ServiceName parameter to copy the current service configuration details to the .CurrentService page by invoking the SetCurrentServiceConfig Data Transform Rule. This Data Transform pulls data from the Service Config <payment type> Data Type and maps it to the .CurrentService page.
3. The system verifies the validity of the invoked service by using the ValidateServiceName flow Rule. If the service is valid and active, the process continues; otherwise, the flow run ends because the service is invalid or inactive.
4. The system invokes the InvokeRESTConnector activity Rule to call the REST service. The first step in this activity is to run the PreInvokeRESTConnector activity, which sets up any required preprocessing before invoking the REST services.
5. The system then runs the InvokeREST activity, which in turn calls the InvokeREST<payment type> activity to invoke the payment type REST service.
6. During the run of the InvokeREST<payment type> activity, the system invokes the D_Invoke<payment type>TIService or D_Invoke<payment type>SIService Data Page, depending on the payment type service type (TI or SI). This Data Page calls the service request Data Transforms to build the request data.
7. After the system invokes REST connector, it maps the response data to the payment type Data Model by running the service response Data Transforms. If simulation is active, the simulation Data Transforms run instead of invoking the REST services.
8. After the service run is complete, based on the service invocation result (Pass/Fail/Error), the system saves all service audit data to the data table by invoking the AddServiceAudits activity, which is called in the InvokeREST<payment type> activity.
9. If the service invocation is successful, the Case proceeds further. In the event of an error, the system classifies the error, and appropriate exception handling occurs as defined in the InvokeRESTConnector flow Rule.

The services invoked during the lifecycle of dispute resolution must undergo auditing for transparency and traceability. This audit should include the service details, data sent in the request, data received as a response, and the status of the service (failure or success). This audit is displayed on the Service Audit tab in the Dispute Case.

When the system invokes a service, the details of the invocation persist in the Service Audit Data Type. The reusable base infrastructure that invokes the service implements this functionality. The Data Type holds the following information:

• Metadata of the service (for example, name, URL, and method)
• Request data
• Response data
• Status (for example, error codes and failure messages)

A configuration in the config set can control the level of auditing. There are three levels for this configuration, which determine the data stored in the Service Audit Data Type:

• Complete: All details (metadata, request, response, and status) are saved to the Data Type.
• Limited: Only key attributes (metadata and status) are saved to the Data Type.
• None: Auditing is off completely, and no data persists.

Based on the nature of the organizations and the volume of service integrations, you must select the appropriate setting. Consider the following:  

• None: When the count of service calls is large (millions in a day) and/or service audit is unimportant.
• Limited: When the count of service calls is large (thousands in a day) and/or storing the complete service audit payload is unimportant.
• Complete: When the count of service calls is moderate (hundreds in a day) and/or storing the complete service audit payload is critical.

The Service Audit Data Type contains the following details:

• Class: PegaFSPE-Data-ServiceAudit
• Primary keys: ClientId, ServiceName, CreateDateTime
• Database table: Dedicated database table with BLOB (pzpvstream)
• Important properties:
  • ClientId: Exception case ID
  • Service Name
  • Service URL
  • Service Method
  • Network: Indicates the network (for example, Visa or MasterCard); alternatively, the class can undergo specialization for payment type.
  • IsLiveOrSimulation: Picklist that indicates whether to store simulated call details.
  • ServiceCallStatus: Status returned by the service (for example, success or failure).
  • ServiceCallStatusMsg: Description of the status, primarily used in case of an error.
  • RequestMessage: JSON string that represents the request message.
  • ResponseMessage: JSON string that represents the response message.
  • Properties provided by the system that begin with pxCreate and pxUpdate.
  • Sensitive Data Marking: Identification of sensitive data, such as card numbers and account numbers.

During the payment type service integration, if any problems (technical or functional) arise, the process must be halted. The errors fall into one of the following categories:

• Transient errors: These errors occur because of service unavailability or other network problems and are recoverable on retry without any intervention.
• Technical errors: These errors arise either while establishing the connection (for example, authentication problems) or during the processing of the service (for example, invalid data or missing required data). After some time, the system automatically retries the service to check if connection issues are resolved and proceed forward. The errors that are not resolved even after retrying require manual intervention. A system administrator must identify and address the problem.
• Functional errors: In this scenario, there may not be any error with the service outcome, but the data received from the service may be incomplete or not as expected. A functional administrator must intervene to identify and resolve the issue in such scenarios. The system moves the Case back to the previous user Assignment with error details for the user to change the details that are causing the error.

The ClassifyServiceError decision table Rule manages the service error classification. The InvokeRESTConnector flow Rule invokes this decision table when an error occurs. Based on the outcome of the ClassifyServiceError decision table, the system follows a corresponding outcome path for exception handling.

Note: Currently, the Smart Dispute application supports only functional type errors, and the ClassifyServiceError decision table always returns Functional as the outcome. In such scenarios, the system routes the Case to the previous Assignment from which the service was invoked, and the service error is displayed on the screen. Users can extend the InvokeRESTConnector flow rule in their implementation layer to handle other types of transient and network errors and verify the same.

The integration framework provides several configuration options and extension points:

• Service audit level configuration: This setting determines the type and amount of audit information recorded for service calls during dispute processing.

The following figure shows the Service audit level configuration:

• Payment type connectivity configuration: To establish secure connections with payment type systems, the application uses the following information:
  • PE <payment type> Truststore
  • PE <payment type> Keystore
  • PE <payment type> Issuer Auth Profile
• Supporting Rules: The integration framework includes numerous rules that support payment type integration:
  • Flow Rules: Invoke<payment type>Connector, InvokeRESTConnector, ValidateServiceName
  • Activity Rules: InvokeRESTConnector, InvokeREST, InvokeREST<payment type>, AddServiceAudits
  • Data Pages: D_Invoke<payment type>TIService, D_Invoke<payment type>SIService
  • Connect REST configurations: <payment type>_Rest_Connector for TI and SI services

The following figure shows the InvokeVisaConnector flow:

The following figure shows the InvokeRESTConnector flow:

The following figure shows the ValidateServiceName flow:

The following figure shows the InvokeRESTConnector activity:

The following figure shows the InvokeREST activity:

The following figure shows the InvokeRESTVisa activity:

The following figure shows the AddServiceAudits activity:

The following figure shows the D_InvokeVisaTIService Data Page:

The following figure shows the D_InvokeVisaSIService Data Page:

The following figure shows the Visa_Rest_Connector (TI service) Connect REST configuration:

The following figure shows the Visa_Rest_Connector (SI service) Connect REST configuration:

By understanding these components and their interactions, you can effectively implement and maintain integrations between Pega Smart Dispute Agentic Automation and payment type services to enable efficient dispute resolution processes.