Com a evolução tecnológica dos produtos da linha Datasul, os serviços do antigo Foundation Saúde estão sendo gradativamente migrados do Jboss 4 para o Tomcat 9.

Neste ponto é comum surgirem algumas dúvidas:

Posso disponibilizar todos os serviços em uma única instância do Tomcat, ou precisarei separar em instâncias diferentes?

Sim. O cliente é livre para utilizar mais instâncias se tiver alguma necessidade em particular, mas tecnicamente é viável utilizar todos os serviços em uma única instância.

Este é um exemplo de como pode ser tratada a conexão da TISS (http com autenticação Basic) e PTU ON-LINE/Intercâmbio Eletrônico (https com certificado) sem precisar duplicar a instância:

Arquivo .../apache-tomcat/conf/server.xml:

Normalmente o arquivo terá um connector padrão, utilizado pelo menu Datasul e serviços da TISS:
Image Added

Para viabilizar a conexão ao PTU ON-LINE/Intercâmbio Eletrônico com autenticação https e certificado, vamos adicionar um novo Service e Connector, com uma nova porta.

No seu Engine, ao invés de permitir acesso a todos os .war do ambiente, vamos:

• manter a propriedade autoDeploy como false e mencionar explicitamente apenas os .war permitidos;
• informar um appBase próprio (no exemplo: webappsPtuOnline), pois se utilizarmos o mesmo do Connector aberto (webapps), todos os .war ficarão expostos;
• perceba que mesmo criando o webappsPtuOnline, não precisamos copiar o .war para ele. Vamos apontar o docBase do Context para buscar o mesmo .war da instalação padrão;

Image Added

Observe que com a configuração acima, será criada a pasta ".../apache-tomcat/webappsPtuOnline", apenas com o deploy da aplicação explicitamente especificada no Context, sem liberar os demais .war.

Seguindo o mesmo raciocínio acima, podemos criar connectors exclusivos para outras aplicações, como por exemplo para o Portal Empresa:

• veja que no caso do Portal Empresa, não basta liberar apenas o portalempresa.war. Visto que se trata de uma aplicação com tela e login, é necessário liberar também outros .war que possuem dependência técnica.

Image Added

Como posso garantir que uma requisição do serviço A não tente acessar a conexão do serviço B?

Para controlar o fluxo das requisições recebidas do mundo exterior, recomendamos que os clientes utilizem proxy reverso, que é uma prática comum em serviços publicados (não faz parte do produto Datasul).

Nas configurações das ferramentas de proxy reverso mais populares do mercado (Nginx e Apache), é possível criar regras utilizando a URL como critério de redirecionamento da requisição para o Tomcat do seu Datasul.

Seguindo a ideia dos exemplos anteriores, vamos usar partes da URL recebida como palavra-chave para o redirecionamento interno de cada requisição:

• Exemplo 1: requisição TISS recebida de um Prestador → precisa ser redirecionada para o Webservice do Connector 8380, que utiliza autenticação Basic:
  • https://meu-servidor-na-internet.com.br/totvs-hgp-tiss-webservices-40200 → redirecionar internamente para → http://meu-servidor-dentro-da-empresa:8380/totvs-hgp-tiss-webservices-40200
    
    • Palavra-chave: totvs-hgp-tiss-webservices*
      
      
      
      
• Exemplo 2: requisição PTU recebida de outra Operadora → precisa ser redirecionada para o Webservice do Connector 8390, que utiliza HTTPS e Certificado:
  • https://meu-servidor-na-internet.com.br/totvs-hgp-ptuonline-9200 → redirecionar internamente para → https://meu-servidor-dentro-da-empresa:8390/totvs-hgp-ptuonline-9200
    • Palavra-chave: totvs-hgp-ptuonline*
      
      
      
      
• Exemplo 3: requisição para o Portal Empresa recebida do serviço publicado → precisa ser redirecionada para o Webservice do Connector 8382:
  • https://meu-servidor-na-internet.com.br/portalempresa → redirecionar internamente para → https://meu-servidor-dentro-da-empresa:8382/portalempresa
    • Palavra-chave: portalempresa