Configuração de integração

A arquitetura de integração no SDAA segue uma abordagem estruturada que promove a usabilidade e simplifica a implementação. Ao conectar sua aplicação a diferentes serviços de tipo de pagamento, você estabelece um canal de comunicação que permite a troca automatizada de dados durante todo o processo de resolução de disputas.

O diagrama a seguir ilustra o design de alto nível e a abordagem para implementar o serviço:

A arquitetura consiste em vários componentes principais que trabalham juntos para facilitar esta integração.

Service configuration

No centro da estrutura de integração está o Tipo de Dados Service config <payment type>. Este componente define os parâmetros para cada serviço de tipo de pagamento com o qual sua aplicação precisa se conectar. Cada registro neste tipo de dados representa um serviço específico e contém informações essenciais:

• Nome do serviço: O nome do serviço.
• Descrição do serviço: Uma descrição do serviço.
• URL de serviço: A URL do serviço.
• Nome da Transformação de Dados de solicitação: O nome da Regra de Transformação de Dados de solicitação de serviço.
• Nome da Transformação de Dados de Resposta: O nome da Regra de Transformação de Dados de resposta do serviço.
• Tipo de serviço: O tipo de serviço de tipo de pagamento (Consulta de Serviço ou Consulta de Transação).
• Método de HTTP: O tipo de método de serviço REST.
• Nome da Transformação de Dados de Simulação: O nome da Regra de Transformação de Dados de simulação do serviço.
• É Solicitação de Várias Partes: Um valor booleano que identifica se o aplicativo pode enviar anexos ou documentos de suporte como parte deste serviço.
• Está ativo: Um sinalizador booleano que indica se o serviço está ativo e em uso no momento.

A figura a seguir mostra um exemplo, o Tipo de Dados Service config Visa:

Connector flow

A estrutura de integração usa Regras de fluxo especializadas para gerenciar a invocação de serviço:

• Invoke<payment type>Connector: O sistema cria esta Regra de fluxo na camada de classe PegaFSPE-Work para invocar serviços do tipo de pagamento. Esta Regra de fluxo aceita ServiceName como um parâmetro para facilitar a invocação dos serviços do tipo Pagamento.

A figura a seguir mostra um exemplo, o fluxo InvokeVisaConnector:

• InvokeRESTConnector: O sistema cria esta Regra de fluxo genérica para invocar serviços REST nos aplicativos Smart Dispute. InvokeRESTConnector usa ServiceName como um parâmetro para facilitar a invocação dos serviços.

A figura a seguir mostra o fluxo InvokeRESTConnector:

Quando o aplicativo Smart Dispute invoca serviços de tipo de pagamento, o seguinte processo ocorre para integrar com o sistema de tipo de pagamento:

1. O sistema executa a regra de fluxo Invoke<payment type>Connector e passa o parâmetro ServiceName para a regra de fluxo genérica InvokeRESTConnector.
2. O sistema usa o parâmetro ServiceName para copiar os detalhes da configuração do serviço atual para a .CurrentService page invocando a regra de Transformação de Dados SetCurrentServiceConfig. Esta Transformação de Dados extrai dados do Tipo de Dados Service Config <payment type> e os mapeia para a página .CurrentService.
3. O sistema verifica a validade do serviço invocado usando a regra de fluxo ValidateServiceName. Se o serviço for válido e estiver ativo, o processo continua; caso contrário, a execução do fluxo termina porque o serviço é inválido ou inativo.
4. O sistema invoca a regra de atividade InvokeRESTConnector para chamar o serviço REST. A primeira etapa nesta atividade é executar a atividade PreInvokeRESTConnector , que configura qualquer pré-processamento necessário antes de invocar os serviços REST.
5. O sistema então executa a atividade InvokeREST , que por sua vez chama a atividade InvokeREST<payment type> para invocar o serviço REST de tipo de pagamento.
6. Durante a execução da atividade InvokeREST<payment type>, o sistema invoca a página de dados D_Invoke<payment type>TIService ou D_Invoke<payment type>SIService, dependendo do tipo de serviço de tipo de pagamento (TI ou SI). Esta página de dados chama as Transformações de dados de solicitação de serviço para construir os dados da solicitação.
7. Após o sistema invocar o conector REST, ele mapeia os dados de resposta para o Modelo de Dados de tipo de pagamento executando as Transformações de dados de resposta de serviço. Se a simulação estiver ativa, as Transformações de dados de simulação são executadas em vez de invocar os serviços REST.
8. Após a conclusão da execução do serviço, com base no resultado da invocação do serviço (Pass/Fail/Error), o sistema salva todos os dados de auditoria do serviço na tabela de dados invocando a atividade AddServiceAudits , que é chamada na atividade InvokeREST<payment type> .
9. Se a invocação do serviço for bem-sucedida, o Caso prossegue. No caso de um erro, o sistema classifica o erro e o tratamento de exceção apropriado ocorre conforme definido na regra de fluxo InvokeRESTConnector.

Os serviços invocados durante o ciclo de vida da resolução de disputas devem passar por auditoria para transparência e rastreabilidade. Esta auditoria deve incluir os detalhes do serviço, os dados enviados na solicitação, os dados recebidos como resposta e o status do serviço (falha ou sucesso). Esta auditoria é exibida na guia Service Audit no Caso Dispute.

Quando o sistema invoca um serviço, os detalhes da invocação persistem no Tipo de Dados Service Audit. A infraestrutura base reutilizável que invoca o serviço implementa esta funcionalidade. O Tipo de Dados contém as seguintes informações:

• Metadados do serviço (por exemplo, nome, URL e método)
• Solicitar dados
• Dados de resposta
• Status (por exemplo, códigos de erro e mensagens de falha)

Uma configuração no conjunto de configurações pode controlar o nível de auditoria. Existem três níveis para esta configuração, que determinam os dados armazenados no Tipo de Dados Service Audit:

• Concluída: Todos os detalhes (metadados, solicitação, resposta e status) são salvos no Tipo de Dados.
• Limitado: Apenas atributos-chave (metadados e status) são salvos no Tipo de Dados.
• Nenhum: A auditoria está completamente desativada e nenhum dado persiste.

Com base na natureza das organizações e no volume de integrações de serviço, você deve selecionar a configuração apropriada. Considere o seguinte:

• Nenhum: Quando a contagem de chamadas de serviço for grande (milhões por dia) e/ou a auditoria de serviço não for importante.
• Limitado: Quando a contagem de chamadas de serviço for grande (milhares por dia) e/ou o armazenamento do payload completo da auditoria de serviço não for importante.
• Concluída: Quando a contagem de chamadas de serviço for moderada (centenas por dia) e/ou o armazenamento do payload completo de auditoria de serviço for crítico.

O tipo de dados Service Audit contém os seguintes detalhes:

• Classe: PegaFSPE-Data-ServiceAudit
• Chaves primárias: ClientId, ServiceName, CreateDateTime
• Tabela do banco de dados: Tabela de banco de dados dedicada com BLOB (pzpvstream)
• Propriedades importantes:
  • ClientId: ID do caso de exceção
  • Nome do serviço
  • URL de serviço
  • Método de serviço
  • Rede: Indica a rede (por exemplo, Visa ou MasterCard); alternativamente, a classe pode passar por especialização para o tipo de pagamento.
  • IsLiveOrSimulation: Lista de opções que indica se deve armazenar detalhes de chamadas simuladas.
  • ServiceCallStatus: Status retornado pelo serviço (por exemplo, sucesso ou falha).
  • ServiceCallStatusMsg: Descrição do status, usada principalmente em caso de erro.
  • RequestMessage: String JSON que representa a mensagem de solicitação.
  • Mensagem de resposta: String JSON que representa a mensagem de resposta.
  • Propriedades fornecidas pelo sistema que começam com pxCreate e pxUpdate.
  • Marcação de dados confidenciais: Identificação de dados confidenciais, como números de cartão e números de conta.

Durante a integração do serviço de tipo de pagamento, se surgir qualquer problema (técnico ou funcional), o processo deve ser interrompido. Os erros se enquadram em uma das seguintes categorias:

• Erros transitórios: Esses erros ocorrem devido à indisponibilidade do serviço ou outros problemas de rede e são recuperáveis em uma nova tentativa sem qualquer intervenção.
• Erros técnicos: Esses erros surgem ao estabelecer a conexão (por exemplo, problemas de autenticação) ou durante o processamento do serviço (por exemplo, dados inválidos ou falta de dados obrigatórios). Após algum tempo, o sistema tenta novamente o serviço de forma automática para verificar se os problemas de conexão foram resolvidos e prosseguir. Os erros que não são resolvidos mesmo após a nova tentativa exigem intervenção manual. Um administrador do sistema deve identificar e solucionar o problema.
• Erros funcionais: Neste cenário, pode não haver erro no resultado do serviço, mas os dados recebidos do serviço podem estar incompletos ou não conforme o esperado. Um administrador funcional deve intervir para identificar e resolver o problema em tais cenários. O sistema move o Caso de volta para a Atribuição do usuário anterior com detalhes do erro para que o usuário altere os detalhes que estão causando o erro .

A regra de tabela de decisão ClassifyServiceError gerencia a classificação de erro de serviço. A regra de fluxo InvokeRESTConnector invoca esta tabela de decisão quando ocorre um erro. Com base no resultado da tabela de decisão ClassifyServiceError, o sistema segue um caminho de resultado correspondente para o tratamento de exceções.

Note: Atualmente, o aplicativo Smart Dispute suporta apenas erros do tipo funcional, e a tabela de decisão ClassifyServiceError sempre retorna Funcional como resultado. Nesses cenários, o sistema encaminha o Caso para a Atribuição anterior da qual o serviço foi invocado, e o erro de serviço é exibido na tela. Os usuários podem estender a regra de fluxo InvokeRESTConnector em sua camada de implementação para lidar com outros tipos de erros transitórios e de rede e verificar o mesmo.

A estrutura de integração fornece várias opções de configuração e pontos de extensão:

• Configuração do nível de auditoria de serviço: Esta configuração determina o tipo e a quantidade de informações de auditoria registradas para chamadas de serviço durante o processamento de disputas.

A figura a seguir mostra a configuração do nível de auditoria de serviço:

• Configuração de conectividade de tipo de pagamento: Para estabelecer conexões seguras com sistemas de tipo de pagamento, o aplicativo usa as seguintes informações:
  • PE <payment type> Truststore
  • PE <payment type> Keystore
  • PE <payment type> Issuer Auth Profile
• Regras de suporte: A estrutura de integração inclui inúmeras regras que suportam a integração de tipo de pagamento:
  • Regras de fluxo: Invoke<payment type>Connector, InvokeRESTConnector, ValidateServiceName
  • Regras de atividade: InvokeRESTConnector, InvokeREST, InvokeREST<payment type>, AddServiceAudits
  • Páginas de dados: D_Invoke<payment type>TIService, D_Invoke<payment type>SIService
  • Configurações Connect REST: <payment type>_Rest_Connector para serviços TI e SI

A figura a seguir mostra o fluxo InvokeVisaConnector:

A figura a seguir mostra o fluxo InvokeRESTConnector:

A figura a seguir mostra o fluxo ValidateServiceName:

A figura a seguir mostra a atividade InvokeRESTConnector:

A figura a seguir mostra a atividade InvokeREST:

A figura a seguir mostra a atividade InvokeRESTVisa:

A figura a seguir mostra a atividade AddServiceAudits:

A figura a seguir mostra a Data Page D_InvokeVisaTIService:

A figura a seguir mostra a Data Page D_InvokeVisaSIService:

A figura a seguir mostra a configuração Connect REST Visa_Rest_Connector (serviço TI):

A figura a seguir mostra a configuração Connect REST Visa_Rest_Connector (serviço SI):

Ao compreender esses componentes e suas interações, você pode implementar e manter efetivamente integrações entre o Pega Smart Dispute Agentic Automation e os serviços de tipo de pagamento para permitir processos eficientes de resolução de disputas.