Dúvidas comuns sobre a ferramenta
Pergunta: O que é a FVP Manual Restrita e qual a diferença dela para a FVP Manual Aberta e a FVP Automática?
Resposta: A FVP Automática é executada diariamente de forma automática. Nela, são realizados testes de DCR, DCM e testes de todas as fases que vão até a etapa de autorização de consentimento. A FVP Manual, diferentemente da FVP Automática, inclui testes que realizam a jornada completa de compartilhamento de dados e de iniciação de pagamentos. Ou seja, por necessitarem de uma etapa de interação do usuário para autorização do consentimento e realização de iniciações de pagamento, a interação manual do usuário é necessária para a finalização do teste. Além disso, o que diferencia a FVP Manual Aberta da FVP Manual Restrita são alguns poucos módulos de testes que estão disponíveis para a estrutura do Open Finance Brasil como, por exemplo, um teste para a validação dos limites do usuário.
Pergunta: Recebi a mensagem “Failed to fetch” na ferramenta, o que isso significa?
Resposta: Erros com a mensagem “Failed to fetch” estão relacionados à timeout da sessão da FVP, que é um erro esperado para sessões longas ou após transições de abas no navegador. Esse erro não impede a execução do módulo de testes, ou seja, basta recarregar a página para seguir acompanhando normalmente a sua execução.
Dúvidas comuns sobre as notificações e encerramento dos tickets
Pergunta: Recebi um ticket de notificação da FVP Manual Restrita, porém não consigo comentar ou encerrar ele. O que devo fazer?
Resposta: Os tickets relativos às notificações da FVP Manual Restrita, de fato, não podem ser comentados ou encerrados pela instituição. Para que o ticket seja encerrado, uma reexecução com sucesso do módulo de teste da FVP deve ser obtida exclusivamente pelo fornecedor responsável pela execução dos testes. Para solicitações de pedidos de reexecução, um novo chamado deve ser aberto na categoria: Requisição > Reexecução > FVP Manual - Testes restritos.
Para esclarecimento de dúvidas com relação à FVP, um chamado deve ser aberto na categoria: Requisições > Solicitação de Informações > Conformidade > Ferramenta de Validação em Produção
Pergunta: Solicitei um pedido de reexecução. Como não possuo nenhuma atuação até o retorno do resultado, o SLA do meu ticket será impactado?
Resposta: Não, o SLA do ticket não será impactado após solicitação de pedidos de reexecução. A partir do momento em que um pedido de reexecução é aberto, o ticket mencionado terá seu status alterado para “Aguardando Requisitante - Essencial”. Tendo-se em vista que a instituição não possui nenhuma ação a ser realizada enquanto aguarda o retorno da reexecução, a cada 24h o ticket ganhará 24h adicionais de SLA. Após encerramento do pedido de reexecução, o status voltará normalmente para “Encaminhado N2 Atendimento”, recontando, a partir desse momento, o SLA normalmente.
Pergunta: Ao invés dos logs, recebi como evidência um JSON com a mensagem “DCR Error – Failure on generating a client”, o que isso quer dizer?
Resposta: Em cada execução de testes da FVP, um cliente (client) é sempre criado no início e excluído ao final. Esse processo de registro é chamado de DCR (Dynamic Client Registration). Quando ocorre uma falha de DCR no início dos testes, o módulo de teste não consegue ser executado, pois a geração do cliente é fundamental para dar início ao teste.
Atualmente, na FVP, cada módulo de teste inclui uma etapa prévia de DCR, onde um cliente é registrado para o servidor em teste. Ao final do teste, esse cliente é excluído. Isso acontece porque, conforme os parâmetros de infraestrutura acordados, a FVP não pode reter as informações do cliente. Cada teste deve excluir o cliente criado para evitar falhas em tentativas subsequentes de DCR, pois os servidores podem rejeitar múltiplos registros do mesmo cliente. Essa abordagem é necessária devido às especificações da OPF, que permitem o registro de apenas um cliente por software statement.
Quando ocorre uma falha durante a etapa de pré-DCR, enquanto o módulo de teste está sendo configurado, o módulo não chega a ser iniciado e uma mensagem de erro é retornada: "DCR Error – Failure on generating a client". Junto com essa mensagem, normalmente é gerado um log detalhando o motivo da falha no processo de registro, além de um botão para baixar esses logs. Enquanto o DCR falhar, o módulo de teste não poderá ser criado, pois ele depende da geração do cliente para ser executado.
Dúvidas comuns sobre o comportamento dos testes
Pergunta: O teste não chegou até o final, visto que o status está como “INTERRUPTED” e os logs apresentam a falha “Test was interrupted before it could complete”, o que isso significa?
Resposta: A mensagem de erro “Test was interrupted before it could complete" pode ser gerada pelos seguintes motivos:
Falha bloqueante: Durante a execução do teste, a FVP identificou uma falha que impossibilita a continuidade das próximas etapas de validação do módulo. Isso significa que o teste não pôde ser finalizado. Um exemplo comum é uma falha no fluxo de autorização. O código de autorização é essencial para obter o token de acesso, que permite a realização de requisições para as APIs. Quando ocorre uma falha nessa etapa, o teste é geralmente interrompido.
Interrupção espontânea: Durante a execução, o responsável pela criação do teste pode, a qualquer momento, acionar o botão "stop", o que interrompe o teste. Essa interrupção pode ocorrer por diversos motivos, como a identificação de falhas no ambiente da detentora de conta que não geram um "retorno de erro" para a FVP. Nesses casos, as falhas não aparecem nos logs, deixando o usuário sem alternativa a não ser interromper manualmente o teste.
Para obter mais detalhes sobre as falhas observadas no ambiente da detentora de conta, é possível utilizar as informações das requisições presentes nos logs, como o xfapi-interaction-id, para identificar o erro diretamente no ambiente da detentora.
Pergunta: O motor realizou chamadas de “Delete” de consentimentos ou pagamentos no momento indevido do teste, por quê?
Resposta: A chamada de "Delete" de consentimentos ou pagamentos pode ocorrer pelos seguintes motivos:
Como parte do processo de "Cleanup" final: Após a execução do fluxo do módulo de testes, durante a sua finalização, seja com sucesso ou falha, a FVP inicia a etapa chamada "Cleanup". Nessa fase, os recursos criados durante o teste são deletados para garantir que não permaneçam armazenados nos bancos de dados da instituição detentora. Isso evita o acúmulo de dados de teste desnecessários.
Como "Cleanup" preventivo: Caso o teste encontre uma falha crítica durante sua execução, a etapa de "Cleanup" é acionada de forma preventiva, mesmo antes da conclusão do teste. Isso é feito para garantir que dados temporários ou indesejados não fiquem armazenados nos sistemas das detentoras após a execução do teste.
Importante: se o teste falhou antes da criação de um consentimento ou pagamento, a etapa de "Cleanup" pode gerar um erro, já que não haverá recurso a ser deletado. Contudo, nesses casos, deve-se considerar a primeira falha que interrompeu o teste e acionou o "Cleanup". A etapa de "Cleanup" geralmente inclui ações como "Unregister dynamically registered client", "Deleting consent" e "Patch consents endpoint".
Pergunta: Após execução do teste, baixei os logs e eles vieram vazios, por quê?
Resposta: Cinco minutos após o término da execução, as informações são apagadas da FVP. Por razões de segurança, a FVP não pode armazenar as informações usadas durante o teste. Assim, após esse período de 5 minutos, os logs da FVP são excluídos automaticamente. Embora eles fiquem visíveis inicialmente na página, depois de 5 minutos, se for feito um reload da página, os logs também não estarão mais disponíveis. Desta maneira, o download dos logs da FVP deve ser realizado em até 5 minutos após a finalização do teste. Caso seja feito posteriormente a esse tempo, o arquivo de logs estará vazio.
Dúvidas comuns sobre as mensagens de erro dos testes
Para apoiar as instituições na identificação e correção das falhas identificadas pela FVP, abaixo estão listadas algumas mensagens de erro que são mais frequentemente encontradas nos logs, juntamente com seu detalhamento do porquê ele ocorre e como solucioná-lo:
40x na requisição do DCR - Client already present for this Software Statement on Server
Problema: O servidor não aceita um novo DCR porque já existe um client_id gerado para esse Software Statement. O client foi criado em um módulo de teste de DCR anterior e, devido a um problema no servidor, a solicitação de exclusão do registro foi recusada, resultando na não exclusão correta do client.
Solução: Verifique o plano de teste e confirme se o problema com a solicitação DELETE ocorreu em algum dos módulos de teste existentes.
a. Se positivo, identifique a causa do problema e implemente uma correção. Exclua manualmente o client criado usando a chave SoftwareStatementID fornecida neste documento.
b. Se negativo, o problema de exclusão ocorreu em um teste anterior contra a instituição e não pode ser rastreado corretamente com as evidências fornecidas.
Exclua manualmente o client criado usando a chave SoftwareStatementID fornecida neste documento e aguarde a próxima execução para avaliar a possível causa do problema na exclusão.
Test was unable to call the Consents API on test
Problema: No teste consents-bad-logged, não foi possível chamar a API POST Consents porque o URI da API de Consentimento não foi fornecido no plano de teste.
Solução: Verifique no diretório se o Servidor de Autorização está registrado com uma API de Consentimentos válida para a Fase 3 e/ou Fase 2, dependendo da fase em que a instituição participa. Consulte o Guia Operacional do Diretório para registrar a API de Consentimentos no servidor.
DCR is not being accepeted because of missing optional fields on the request
Problema: O servidor recusa o DCR porque um campo opcional não foi incluído no corpo da solicitação.
Solução: O servidor deve aplicar um padrão suportado para todos os campos opcionais, garantindo que a solicitação seja processada pela instituição.
Routine was unable to confirm within the well-known endpoint the supported token authentication methods Causas potenciais que podem ser:
Causas potenciais que podem ser:·
Well-Known utilizou certificados SSL inválidos, impedindo o acesso às informações.
...
response_body não inclui private_key_jwt ou tls_client_auth no objeto token_endpoint_auth_methods_supported.
...
O servidor negou acesso a FVP ao tentar verificar o conteúdo do endpoint
...
WellKnown
Solução:·
Assegure-se de que o endpoint Well-Known está utilizando um certificado SSL EV válido de CA ou ICP-Brasil, conforme especificado na Documentação de Padrões de Certificado.
...
Garanta que o retorno esteja em conformidade com o RFC8414.
...
Verifique se o payload JSON retornado contém os métodos de autenticação de token esperados.
Server claims the authorization token is invalid or expired
Problema: O servidor não está aceitando tokens de acesso válidos. Algumas instituições identificaram um problema de sincronização no cache de tokens entre diferentes instâncias do authorisation server.
Solução: Implementar uma estratégia de fallback para consultar o token no banco de dados quando não for encontrado no cache.
Failure when calling the directory endpoints - Token or Assertion
Problema: O diretório retornou um erro 50x ao chamar um de seus endpoints devido ao alto uso da plataforma durante o teste.
Solução: Nenhuma mudança é necessária para a instituição, ignore os resultados do teste e aguarde uma nova execução.
Server returned that the client presented invalid certificates
Problema: Em todas as solicitações de DCR, o servidor testado está retornando credenciais do cliente emitidas como inválidas, resultando em falhas em todos os testes.
Solução: O servidor não está reconhecendo o certificado emitido como válido. Certifique-se de que o API Gateway confia no certificado e na CA que emitiu este certificado.
State was passed in request, but is missing from response
Problema: Alguns casos de falha, como no caso da mensagem de erro “State was passed in request, but is missing from response”, ocorrem em redirecionamentos de volta à FVP. A causa dessa falha, após a finalização da jornada no ambiente da detentora, está relacionada ao fato de que, se o usuário que está realizando o teste não estiver logado no navegador padrão de seu dispositivo móvel, as informações transmitidas na URL de redirecionamento se perdem no momento em que o navegador solicita a autenticação. Isso ocorre pois o link de redirecionamento é único, ou seja, se ele for acessado uma vez, e a sessão do usuário não estiver ativa, o link se perde, resultando na falha do redirecionamento.
Solução: Para execuções que são realizadas via leitura de QR Code, recomenda-se sempre realizar a autenticação em seus dispositivos móveis, no navegador em que será utilizado, previamente ao início ao início do teste. Isso garante que o fluxo de redirecionamento funcione corretamente e os parâmetros sejam transmitidos de forma adequada.