FAQ

Esta seção reúne perguntas frequentes sobre o uso do Mock OPIN.

1. Consigo testar meu fluxo de transmissão de dados usando o Mock OPIN como um iniciador (ou seja, fazendo chamadas para meu servidor)?

O cenário descrito corresponde ao papel de uma TPP (Third Party Provider), responsável por executar chamadas e validar as respostas dos participantes.

Atualmente, não é possível usar o Mock OPIN como iniciador para fazer chamadas ao seu servidor pois o mesmo corresponde a um transmissor de dados e não um iniciador. No entanto, esse fluxo pode ser testado completamente pelo motor de conformidade (Conformance Suite), que realiza as chamadas e valida os resultados retornados pelos servidores em questão.

Paralelamente, está em desenvolvimento o módulo Mock TPP, que terá a capacidade de atuar como uma TPP. A primeira release está prevista para outubro, com releases parciais até dezembro para cobrir todas as APIs. Assim, será possível também executar esses fluxos diretamente pelo Mock OPIN.

2. Como posso rodar meu servidor localmente junto com o Conformance Suite local, assim como o Mock OPIN faz?

Para rodar o Conformance Suite (CS) junto com o seu servidor local, de forma semelhante ao que fazemos com o Mock OPIN na opção de execução local, alguns ajustes foram necessários. Em resumo: usamos o `docker-compose.yml` oficial do CS em conjunto com um container chamado `mtls`, que funciona como um proxy. Ele garante que as chamadas da CS (como `auth.local` e `api.local`) sejam encaminhadas para os serviços corretos no ambiente local, como o Authorization Server e o Resource Server. Além disso, os clientes de autenticação já vêm pré-configurados no container `auth` e usam certificados específicos. Isso permite que o CS simule requisições reais e valide o seu servidor como se fosse um participante do ecossistema Open Insurance.

A seguir, detalhamos com maior precisão os exatos ajustes que fizemos para rodar o Conformance Suite localmente e integrá-lo com o Mock OPIN local. Eles podem ser usados como base para adaptar à sua necessidade:

Mais detalhes

Conformance Suite

Nosso setup é baseado no docker-compose.yml oficial do repositório do Conformance Suite. No nosso projeto, usamos insurance-server-lambdas/docker-compose.yml, onde os serviços com prefixo cs- representam o servidor do Conformance Suite e suas dependências.

O Conformance Suite, rodando dentro de um container, faz requisições para hosts como:

• matls-auth.local
• auth.local
• matls-api.local
• api.local
• directory

Esses hosts são resolvidos pelo container mtls, implementado em mock-service-os/mock_mtls. Esse container atua como um proxy, roteando as requisições para:

• auth: representando o Authorization Server (AS)
• mockapi: representando o Open Insurance Resource Server

O container mtls também serve informações de participantes mock, que são definidas em insurance-server-lambdas/participants.json.

Clients e Autenticação

Para autenticar com o Authorization Server, a Conformance Suite usa clientes pré-configurados como client_one e client_two. Esses clientes são carregados no container auth a partir dos arquivos em mock-service-os/mock_as/mongo-seed.

Os clientes usam certificados armazenados em mock-service-os/mock_as/certs e são configurados com URIs de redirecionamento específicas, como:

https://localhost.emobix.co.uk:8443/test/a/mock/callback

Este URI corresponde ao endpoint de redirecionamento que o Conformance Suite cria para o alias mock, conforme especificado no arquivo de configuração cs_config.json.

Configuração de endpoints

Quando os testes são executados, o Conformance Suite envia as requisições para auth.local e api.local, uma vez que esses valores estão definidos no arquivo de configuração dos testes.