Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

...

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:

...

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

  ...
  <Service name="Catalina">
    ...
    <Connector port="8180" 
               protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8170"
               maxThreads="1600"
               acceptCount="800"
               enableLookups="false"
               URIEncoding="ISO-8859-1"
               maxParameterCount="1000"/>
    ...
    <Engine name="Catalina" defaultHost="localhost">
      ...
      <Host name="localhost"  appBase="webapps" startStopThreads="20"
            unpackWARs="true" autoDeploy="true">
        ...
      </Host>
    </Engine>
  </Service>
  ...

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:

  <!-- Novo Service isolado: apenas wars do PTU ON-LINE na porta 8190 -->
  <Service name="Catalina-PTU">
        <Connector port="8190" 
            maxHttpHeaderSize="8192" 
            maxThreads="100"
            minSpareThreads="25" 
            enableLookups="false" 
            disableUploadTimeout="true"
            acceptCount="100" 
            scheme="https" 
            secure="true"
            SSLEnabled="true" 
            clientAuth="false"
            sslProtocol="TLS" 
            keyAlias="server"
            keystoreFile="/opt/totvs/sqa_120/apache-tomcat/conf/chave.jks"
          keystorePass="changeit" />
               
    <Engine name="Catalina-PTU" defaultHost="localhost">
      <Host name="localhost" unpackWARs="true" autoDeploy="false">
        <Context path="/totvs-hgp-ptuonline" docBase="/opt/totvs/sqa_120/apache-tomcat/webapps/totvs-hgp-ptuonline.war" />
        <Context path="/totvs-hgp-ptu-online-9200" docBase="/opt/totvs/sqa_120/apache-tomcat/webapps/totvs-hgp-ptu-online-9200.war" />
      </Host>
    </Engine>
  </Service>  
  ...

...