Árvore de páginas

Você está vendo a versão antiga da página. Ver a versão atual.

Comparar com o atual Ver Histórico da Página

« Anterior Versão 12 Próxima »


Com mudança de paradigma aplicada no Portal Autorizador HAT em 2022/2023, o mesmo passa a ser cada vez mais acoplado ao Sistema de Gestão SIGAPLS. A maioria das informações utilizadas e processadas no HAT são acionadas de maneira instantânea no SIGAPLS através de API´s.

Este documento tem como objetivo explicar alguns conceitos para que auxiliar principalmente o Suporte na análise de dúvidas e problemas.

Importante: Todos os prints e testes abaixo foram utilizado nosso ambiente de DEV integrado com o Ambiente Único. Quando for realizar uma análise de um cliente, basta realizar os mesmos passos com os dados de acesso do cliente.


O primeiro passo é saber qual a URL do PLS o HAT vai acionar ao realizar uma solicitação. Para isso, acesse o Portal de Administração, no menu acesse Configurações / Configurações de Integração. Nesta tela, indicamos várias URL´s, cada uma para uma finalidade diferente, mas a maioria dos casos, a URL a ser utilizada é a Integrações genéricas Protheus PLS.



Ou seja, para a maioria dos casos nossa URL que será utilizada no PLS será http://10.171.80.125:3269/rest/totvshealthplans/v1/


ANÁLISE DE REQUISIÇÕES REST 


Agora vamos para alguns exemplos práticos. Geralmente o acesso ao PLS se dá por duas maneiras. Uma é através de alguma regra específica no Backend do HAT onde indicamos a chamada ou atráves da chamada de frontend genericPLS. Toda a chamada no PLS tem também um parâmetro que controla se realizará a chamada ou não, exemplos: 

Não é uma regra, mas geralmente parâmetros que indicam acesso ao SIGAPLS tem PLS no nome


CHAMADA VIA BACKEND

Vamos usar um exemplo que busca o SIGAPLS com regra de Backend: Elegibilidade de Usuário. Pressione a tecla F12 ao realizar uma Elegibilidade em alguma jornada de atendimento.

Perceba que foi realizada uma solicitação para uma API do HAT. Na aba Headers, nos conseguimos ver a requisição POST que foi realizada:


Na aba Payload teremos o JSON de envio (quando existir) e na aba Response, o JSON de resposta:


Porém, a requisição acima foi feita para o HAT. Como vou faço para saber se essa requisição foi feita para o SIGAPLS? No Portal de Administração, acesse Monit. de Integrações / Solicitações REST. Quase todas as requisições realizadas para o SIGAPLS são registradas nessa rotina. Vamos acessar a Elegibilidade de Beneficiário utilizada no exemplo acima:


Acessando ela, conseguimos mais dados dessa requisição:


Agora, vamos testar ela via POSTMAN.

Vamos utilizar a URL http://10.171.80.125:3269/rest/totvshealthplans/v1/ que pegamos no início do documento no Portal de Administração.  Veja acima que o HAT fez um GET para o PLS. A API que utilizada será a beneficiaryElegibility. Os queryparams utilizados são cardNumberOrCpf=439.027.288-84&authorizationType=2&healthProviderCode=000004. Com essas informações, vamos montar a chamada para o SIGAPLS


Acionando o botão SEND, essa requisição é enviada para o PLS, e na caixa inferior é nos exibido a resposta.


Com isso nós fechamos o ciclo onde realizamos uma requisição no FrontEnd do HAT e vamos até o SIGAPLS para processar uma informação quando a mesma é registrada na rotina de Requisições REST.


CHAMADA VIA GENERICPLS

Há porém, um modelo de chamada que não é registrada na rotina de Requisções REST: genericPLS. Vamos realizar um teste com este modelo.

Uma rotina que utiliza este modelo é o Consultar Guias:

Perceba que a requisição realizada foi: https://10.171.40.51:4200/api/healthcare/hat/v1/genericPls?apiName=authorizationsList&queryParam=healthProvider=000004%26page=1%26pageSize=10

Para montar a URL utilizada devemos utilizar:

  • URL do SIGAPLS: http://10.171.80.125:3269/rest/totvshealthplans/v1/ 
  • Nome da API - Extraímos do apiName acima. Neste exemplo será authorizationsList
  • QueryParams - Extraímos do queryParam acima. Neste exemplo termos healthProvider=000004%26page=1%26pageSize=10


IMPORTANTE

Note que no exemplo acima, os query params são separados pelos caracteres %26. Isso porque no esquema de Encode, esses caracteres indicam & (caracter padrão de quebra de queryparams). A lista geral pode ser encontrada aqui: https://www.w3schools.com/tags/ref_urlencode.ASP



Com essas informações, conseguimos montar na requisição para o SIGAPLS: http://10.171.80.125:3269/rest/totvshealthplans/v1/authorizationsList?healthProvider=000004&page=1&pageSize=10


Assim, encerremos os dois ciclos que o Portal Autorizador HAT aciona o SIGAPLS através de API´s. Note que ainda algumas API´s que são acionadas somente no HAT, mas a grande maioria hoje tem busca no SIGAPLS e a tendência é cada vez mais ir buscar no SIGAPLS. Importante lembrar também que para realizar a busca no SIGAPLS sempre há um parâmetro para controlar isso. Isso é feito pois o cliente precisa aplicar um patch com a API no SIGAPLS.


Caso precise analisar, ver uma data de alguma API no PLS, as mesmas são definidas neste caminho no TFS: $/Protheus_Padrao/Fontes_Doc/Master/Fontes/Plano de Saude/APIs


T





  • Sem rótulos