A integração do produto TOTVS Saúde Planos Linha Protheus tem como objetivo, enviar dados dos Beneficiários e Empresas para que possam ser tratados pelos serviços utilizados nos sistemas parceiros da TOTVS.
A comunicação entre as partes será realizada via comunicação API REST.
O processo de integração funcionará no seguinte panorama, que serão detalhados abaixo:
Ao acessar a rotina de Integrações (PLMapIntegra), será possível cadastrar novas integrações, a tela de inclusão terá os seguintes campos a serem preenchidos:
Detalhes dos campos da Integração
Campo | Descrição | Preenchimento |
---|---|---|
Operadora | Código da Operadora do sistema. | Obrigatório. |
Codigo Integ. | Código Incremental das Integrações. | Preenchimento automático, não editável . |
Descrição | Descrição da Integração. | Obrigatório. |
Alias Prima. | Tabela do cadastro que será utilizada para envio. | Obrigatório, essa tabela será detalhada no próximo tópico. |
EndPoint | Endereço de comunicação da API do sistema parceiro. | Opcional no cadastro, mas necessário para comunicação dos pedidos. |
Ativo | Definição se a Integração está ativa, essa informação é usada em alguns processo do sistema. | Obrigatório. |
Máximo Envio | Quantidade máxima de tentativas de comunicação, antes de cancelar o pedido, caso não tenha sucesso. | Obrigatório. |
Classe Stamp | Classe do sistema que será utilizada para gravar os pedidos via schedule. | Opcional no cadastro, mas necessário para realizar a gravação dos pedidos via schedule, esse preenchimento será detalhado no próximo tópico. |
Classe Comu. | Classe do sistema que será utilizada para montagem do json da integração, além da comunicação. | Opcional no cadastro, mas necessário para a comunicação dos pedidos, esse preenchimento será detalhado no próximo tópico. |
Login Auten. | Login para autenticar no sistema parceiro da Integração. | Opcional no cadastro, mas necessário para comunicação dos pedidos. |
Senha Auten. | Senha para autenticar no sistema parceiro da Integração. | Opcional no cadastro, mas necessário para comunicação dos pedidos. |
EndPoint Aut | Endereço de comunicação da API de Autenticação do sistema parceiro. | Opcional no cadastro, mas necessário para comunicação dos pedidos. |
Bearer Aut. | Bearer utilizado pelo sistema para autenticação na API do sistema parceiro. | Não editável, o sistema utiliza esse campo para controle interno ao realizar a comunicação. |
Cookie Aut. | Cookie utilizado pelo sistema para autenticação na API do sistema parceiro. | Não editável, o sistema utiliza esse campo para controle interno ao realizar a comunicação. |
Tempo Expe. | Tempo de Expiração do Bearer e Cookie. | Não editável, o sistema utiliza esse campo para controle interno ao realizar a comunicação. |
Perg. Gerar | Pergunte (SX1) do sistema para gerar os pedidos | Opcional no cadastro, mas necessário no botão Gerar Pedidos, esse pergunte será para os filtros da geração, esse preenchimento será detalhado no próximo tópico. |
a. Integrações Disponíveis
As Integrações disponíveis para cadastrar são:
Cadastro de Empresas
Sistema Parceiro | Alias Prima. | Classe Stamp | Classe Comu. | Perg. Gerar |
---|---|---|---|---|
HealthMap | BG9 | PLMapStpEmpre | PLMapJsEmpre | PLR660 |
Cadastro de Beneficiários
Sistema Parceiro | Alias Prima. | Classe Stamp | Classe Comu. | Perg. Gerar |
---|---|---|---|---|
HealthMap | BA1 | PLMapStpBenef | PLMapJsBenef | PLR660 |
Essas são informações a serem preenchidas no cadastro da Integração para cada sistema parceiro.
Tela em MVC da tabela BZZ (Pedidos), que será acessada através do botão outras ações da tela de Integrações HealthMap. O Browser dos pedidos será filtrado de acordo com a integração posicionada, ou seja, se for acessado via Integração do cadastro de beneficiários, só será exibido os pedidos relacionados ao cadastro de beneficiários na tabela BZZ e assim também para o cadastro de Empresas.
Aberto o Browser dos pedidos, no menu terá a opção de Alterar, Visualizar, Excluir, Cancelar e Comunicar (Inclusão será feita somente via Classe de Coleta de Dados):
(Imagem ilustrativa, alterar para imagem do produto quando desenvolvido)
Detalhes dos Campos da tabela BZZ:
Campo | Descrição |
---|---|
Operadora | Operadora do Sistema |
Cod. Integração | Código de relacionamento com a tabela de Integrações |
Cod. Pedido | Código Incremental dos Pedidos |
Alias | Tabela chave do pedido para ser utilizado na busca de dados |
Chave | Chave de busca do Alias para posicionar nos registros |
Dt. Inclusão | Data de Inclusão do Pedido |
Dt. Comunicação | Data em que foi realizado a comunicação com a HealthMap |
Status | Status do Pedido: 0-Pendente de Envio; 1-Envio Realizado; 2-Erro de Envio; 3-Envio Cancelado |
Tent. Envio | Tentativas de Comunicação com o HealthMap |
Json Envio | JSON enviado para o HealthMap |
A classe PLMapGrvPed, irá verificar as integração da HealthMap (Tabela BXX) se os Alias relacionados ao Cadastro de Beneficiários ou Empresa tiveram alguma alteração de acordo com o campo S_T_A_M_P_ das tabelas. Se houver alteração, será feito uma busca na tabela de pedido (BZZ) pelos campos: Cod. Integração + Alias Primário + Chave (Corresponde os dados que identificam o Beneficiário ou Empresa), para saber se tem algum pedido daquele Beneficiário ou Empresa pendente para não haver duplicidade de envio de dados.
Essa Classe possuirá alguns métodos como:
Será criado um schedule, onde poderá ser configurado a quantidade de vezes em que a classe PLMapGrvPed, irá buscar e gravar os pedidos de acordo com as integrações.
Criado os pedidos, será feito a comunicação com a HealthMap pela Classe PLMapComPed, que herda métodos da classe PLSRest.
Mas antes de comunicar, será feito a montagem do json de cada pedido através da classe PLMapBenef para o Cadastro de Beneficiários e PLMapEmpre para o Cadastro de Empresas.
Essas classe de montagem do Json possuirá alguns métodos como:
Caso possua métodos em comum para montagem do Json, será criado a classe PLMapJson (se necessário)
Feito a montagem do Json, será instanciado a classe de comunicação para envio do Json para a HealthMap.
A Classe de comunicação PLMapComPed possuirá alguns métodos como:
Será criado um schedule, onde poderá ser configurado a quantidade de vezes em que a classe PLMapComPed, irá realizar o envio dos pedidos pendentes para a HealthMap.