FAQ - Integrações / Central de logs

Esta documentação abrange a área de troubleshooting, essencial para resolver problemas técnicos e manter sistemas funcionando adequadamente. Exploraremos a abordagem sistemática de análise de sintomas, testes e diagnóstico, além de destacar a importância da colaboração e compartilhamento de conhecimento. O guia fornece informações valiosas para aprimorar habilidades técnicas e enfrentar desafios com confiança, garantindo a eficiência operacional. Mantenha-se atualizado com as últimas tendências nesse campo em constante evolução.

Central de logs

A Central de Logs é uma ferramenta que tem agrupa informações de eventos que ocorrem nas mais diversas áreas da aplicação Omnichannel, passando desde acessos nas plataformas, integrações entre APIs, bem como da utilização pelo usuário final (beneficiário) no uso dos nossos fronts, sejam eles mobile ou WEB.

Interface

A interface será apresentada em uma janela no painel de configuração do Omnichannel (https://painel.mosiaomnichannel.com.br/) onde o usuário poderá filtrar os logs.

Para acessar a interface da central de logs, acesse: Segurança → Central de logs

Open

Open

Novo filtro de busca

Para que seja apresentado os novos filtros de busca, basta clicar no botão “Acessar novo filtro“ conforme print abaixo.

Open

Após acessar os novos filtros, será apresentado as seguintes informações

Open

1. Data e hora do início da busca:

Aqui deverá ser preenchido o início do período que deseja buscar.

2. Data e hora do final da busca:

Aqui deverá ser preenchido o final do período que deseja buscar.

3. Chave Única:

Caso deseja pesquisar os logs de determinado beneficiário, preencha o campo com a chave única para que seja retornado apenas os dados do beneficiário em questão.

4. Origem:

   1. A base do MosiaOmnichannel é baseada em ocorrências, e neste campo podemos direcionar a busca para um origem em específico. As origens disponíveis são:

      • App:

        • Ocorrências com origem do aplicativo. Exemplo: Cartão virtual, logout e Relogin.

      • Chatbot:

        • Ocorrências com origem no Chatbot. Exemplo: Status de Atendimento.

      • Connect:

        • Ocorrências no qual se faz necessário fazer uma requisição no Connect e retornar dados. Exemplo: Integração.

      • Mensageria:

        • Ocorrências voltadas a mensageria. Exemplo: E-mail e WhatsApp.

5. Categorias:

   1. Categorias disponíveis para afunilar a busca dependendo da escolha da Origem da busca. Exemplo: Cartão virtual, Logout, Status do Atendimento, etc.

6. Subcategoria:

   1. Subcategorias disponíveis para afunilar a busca dependendo da escolha da Categoria da busca. Exemplo: Acesso Funcionalidade, Boleto PDF, Detalhe da Consulta, Elegibilidade, Lista Débito, etc.

Como analisar retornos de APIs usando o painel do Mosia Omnichannel?

Contexto: Inúmeros clientes tem dificuldades de analisar situações de falha nas APIs. Muitas vezes, relatos de usuários do app para a operadora indicam que “beneficíario não consegue verificar seu extrato de autorização”, por exemplo. A operadora tem condições de realizar uma análise completa, usando o painel público

Como?

1. Acesse o painel público com seu usuário/senha e siga conforme esses passos: Segurança => Central de logs. Selecione as datas e horários das tentativas e filtre se desejar por Operação → Extrato de autorização.

Open

2. Clique no evento e verifique os logs. Uma tela será demonstrada. O JSON de retorno conterá informações sobre o request. Para analisar o RESPONSE da API (que deve conter informações sobre o problema) vá até o fim do log, ou utilize o botão de “copiar”. A partir daí, basta colar o conteúdo em uma aplicação que indentará o JSON, tornando-o mais legível.

Open

Atente-se aos atributos “status”, “statusText” e objeto “data”.

3. De acordo com o caso acima, é possível perceber que a API não devolve o resultado esperado (conteúdos válidos para exibição). Um status 400 indica que existe uma falha na obtenção de dados, e o detalhamento do erro indica que, por algum motivo, sua API não está sendo capaz de obter informações do seu ERP de saúde. Nesses casos, você deverá analisar sua API ou barramento OMNILINK para corrigir o problema.

Determinado beneficiário não aparece na funcionalidade desejada

Caso todos os procedimentos de integração e regra de negócios da operadora estejam corretos, se faz necessário verificar algumas etapas:

1 - Verifique o objeto de permissões do login desejado (conforme nossa documentação1.1 - LoginPreview )

Open

2 - Verifique se existe a integração do método beneficiariosAcessoFuncionalidade se a mesma está configurado, em caso de positivo verifique se os dados do contrato e chaveUnica batem com os do login informado, como no exemplo abaixo:

Open

Como funciona o Relogin?

1. Início da contagem do tempo
   A contagem do intervalo para re-login começa a partir do momento em que o beneficiário faz login no aplicativo. Ou seja, assim que o login é realizado, o "relógio" já está em andamento.

2. Re-login após inatividade
   Se o usuário abrir o aplicativo novamente após um período superior a 24 horas (por exemplo, 4 dias depois), o app solicitará um novo login. Isso acontece porque o tempo limite de sessão foi ultrapassado.

3. Processo de re-login
   Ao ser solicitado, o re-login envolve os seguintes passos:

   • O sistema inicia a solicitação de dados de autenticação.

   • Esses dados são buscados via API do cliente, caso ela esteja disponível no momento.

   • Assim que os dados são recebidos, o sistema notifica o aplicativo.

4. Fatores que podem impactar a experiência do usuário

   • Disponibilidade da API de re-login: Se estiver funcional, a resposta é praticamente imediata (segundos ou poucos minutos).

   • Comportamento do usuário: Se o acesso ao app for muito rápido, pode acontecer de os dados de re-login só estarem totalmente disponíveis em uma próxima tentativa de uso.

Documentação - Relogin: 1.8 - ReloginPreview

Documentação - Login : 1.1 - LoginPreview

Open

Recuperação de Senha com E-mail Opcional

Open

1. Visão Geral do Incidente

• Resumo claro e direto do problema: Este guia aborda falhas hipotéticas na funcionalidade de recuperação de senha para usuários, especialmente aqueles que não possuem um e-mail pré-cadastrado na base de dados. A funcionalidade permite que o usuário informe um novo e-mail durante o fluxo de recuperação para receber o token de acesso e, opcionalmente, atualizar seu cadastro.

2. Contexto Técnico

• Ambiente: Produção.

• Stack envolvida:

  • Backend: API de autenticação e gerenciamento de usuários.

• Componentes afetados:

  • Endpoint da API de "Esqueci minha senha" / "Recuperar Senha".

  • Lógica de validação de CPF e Data de Nascimento no backend.

  • Lógica de criação/validação de e-mail no form-builder (frontend).

  • Serviço de atualização de e-mail do usuário.

  • Serviço de envio de tokens por e-mail.

3. Impacto

• Usuários afetados: Todos os usuários que dependem da funcionalidade de recuperação de senha, especialmente aqueles sem e-mail cadastrado ou que desejam usar um novo e-mail para o processo.

• Funcionalidades comprometidas: Recuperação de senha de usuário

cURL

O cURL é uma ferramenta de linha de comando que permite transferir dados para ou de um servidor usando vários protocolos da internet. Pense nele como um "navegador para desenvolvedores" que funciona diretamente no terminal.

Há uma forma de capturar o cURL da sua requisição diretamente no Postman
O cURL nos ajuda a testar endpoints de API rapidamente.

Com estes passos, você poderá capturar o cURL da sua requisição.

Capturar uma requisição do Postman em cURL

1. Abra a sua requisição no Postman (GET, POST etc).

Open

2. No canto direito, clique no botão “</> Code”.

Open

3. Aqui você terá o acesso ao cURL da sua requisição que pode ser enviado junto ao chamado para analise caso necessário.

Open

Exemplo de cURL