Árvore de páginas


CONTEÚDO

  1. Visão Geral
  2. Visão Geral das Camadas (Layers) Datasul
  3. Configurações do JOSSO
  4. Configurações das Propriedades do Datasul
  5. Configurações do Servidor Interno BTB946aa
  6. Configuração Connector jboss para controle de cookies
  7. Usuário EMS e acesso via AD

01. VISÃO GERAL

O produto Datasul possui as camadas de VIEW (Telas do produto, HTML, Progress), MODEL (Java e progress que executam o negócio) e por último a parte de Banco de dados. O Objetivo deste documento se restringe à configuração do produto para que essas camadas se comuniquem adequadamente, inclusive com o uso de loadbalance, para que as sessions sejam criadas e gerenciadas corretamente pela aplicação.

Versão do Java

Importante avaliar a versão do java, pois, é necessário que seja a versão 1.7.0_80 conforme Versão do java


02. VISÃO GERAL DAS CAMADAS (LAYERS) DATASUL

Abaixo segue o fluxo da arquitetura das camadas e essa será utilizada para as explicações dos demais itens deste documento.

VIEW(client, navegador, rpw)→CONTROLLER(JBOSS_PROD_1, JBOSS_PROD_2, APPSERVER_PROD_1)→MODEL(Base de dados)

Para o documento os dados de server serão os seguintes:

LOADBALANCE_PRODJBOSS_PROD_1JBOSS_PROD_2APPSERVER_PROD_1

NOME HOST=LOADBALANCE_PROD

PORTA HOST=8443

IP=10.80.192.171

NOME HOST=JBOSS_PROD_1

PORTA HOST=8180

IP=10.80.192.168

NOME HOST=JBOSS_PROD_2

PORTA HOST=8280

IP=10.80.192.169

NOME HOST=APPSERVER_PROD_1

PORTA HOST=5162

IP=10.80.192.170

ATENÇÃO IP OU NOME DE HOST

Para o correto funcionamento do josso, as configurações devem seguir sempre com IP ou sempre com NOME HOST. Caso sejam feitas configurações híbridas nas camadas as sessions ficam erradas e podem ocorrer travamentos. Portanto:

CASO A CONFIGURAÇÃO NO AGENT CONFIG DO JOSSO FOR POR IP TODAS AS DEMAIS DEVEM SER EM IP. O MESMO PARA O NOME HOST.


03. CONFIGURAÇÕES DO JOSSO

Seguindo as informações do item 02 devemos configurar os arquivos do josso nos servers JBOSS_PROD_1 e no JBOSS_PROD_2.

Para o server JBOSS_PROD_1, abrir o arquivo josso-agent-config.xml e localizar a tag <service-locator> e configurar conforme abaixo:

Alterar josso-agent_config.xml
...
  <service-locator>
    <class>org.josso.gateway.WebserviceGatewayServiceLocator</class>
    <endpoint>JBOSS_PROD_1:8180</endpoint>
  </service-locator>
...

Para o server JBOSS_PROD_2, abrir o arquivo josso-agent-config.xml e localizar a tag <service-locator> e configurar conforme abaixo

Alterar josso-agent_config.xml
...
  <service-locator>
    <class>org.josso.gateway.WebserviceGatewayServiceLocator</class>
    <endpoint>JBOSS_PROD_2:8280</endpoint>
  </service-locator>
...

04. CONFIGURAÇÕES DAS PROPRIEDADES DATASUL

Para que o produto funcione adequadamente existem alguns logins internos do datasul para validação dos usuários e integrações. Para esse tipo de validação é utilizada a propriedade portal.java.naming.security.datasulurl. Essa propriedade deve ser, obrigatoriamente, configurada com o mesmo valor do arquivo josso-agent-config.xml seguindo o padrão http://host:port

Para o server JBOSS_PROD_1, abrir o arquivo datasul-framework.properties e localizar a chave portal.java.naming.security.datasulurl e configurar conforme abaixo

Configuração do portal.java.naming.security.datasulurl
...
portal.java.naming.security.datasulurl=http://JBOSS_PROD_1:8180
...

Para o server JBOSS_PROD_2, abrir o arquivo datasul-framework.properties e localizar a chave portal.java.naming.security.datasulurl e configurar conforme abaixo

Configuração do portal.java.naming.security.datasulurl
...
portal.java.naming.security.datasulurl=http://JBOSS_PROD_2:8280
...

05. CONFIGURAÕES DO SERVIDOR INTERNO BTB946AA

Na camada do MODEL com o appserver é preciso informar para o progress qual será o servidor de comunicação para controlar as validações que tem origem no APPSERVER. Nessas validações o APPSERVER passa a funcionar como um client do servidor JBOSS e desta maneira precisa fazer o login antes de executar modificações no produto. 

Sendo assim, no datasul existe a tela btb946aa que possui o objetivo de configurar como o appserver irá se comunicar com o servidor JBOSS. Em nosso exemplo, geralmente a configuração é feita elegendo um dos servers do JBOSS para realizar essas validações e autenticações de origem do appserver, porém alguns clientes utilizam o componente de loadbalance para que as requisições sejam distribuídas entre os servidores JBOSS e assim ganhar em performance.

Configuração elegendo apenas um JBOSS como ponto central de requisições que possuem origem no APPSERVER_PROD_1

  1. Acessar o produto como usuário super e acessar a tela btb946aa.
  2. Acessar a aba Servidor
  3. Encontrar os campos abaixo e digitar os valores
  4. Servidor Interno: Informar JBOSS_PROD_1
  5. Porta: 8180 

Como a configuração é persistida na base dados ambos o APPSERVER_PROD_1 sempre irá gerar requisições para o JBOSS_PROD_1 mesmo que essa tenha origem no JBOSS_PROD_2. 

Configuração para uso de balance como ponto central de requisições que possuem origem no APPSERVER_PROD_1

A partir da versão 12.1.28.13, 12.1.29.7 e 12.1.31.2 expedidas no dia 19/02/2020 é possível configurar o produto para uso do balance através do btb946aa. 

Restrição de url e Nome Host

Para o correto funcionamento a configuração do btb946aa deve obrigatoriamente ser feita utilizando o endereço interno do servidor do loadbalance e nunca com o acesso externo EX: https://testelb.dominiobla.com.br

  1. Acessar o produto como usuário super e acessar a tela btb946aa.
  2. Acessar a aba Servidor
  3. Encontrar os campos abaixo e digitar os valores
  4. Servidor Interno: Informar LOADBALANCE_PROD
  5. Porta: 8443

Modelos de Persitência de LoadBalance

Para o produto Datasul JBOSS é exigido que o loadbalance funcione como sticky session. Para esse modelo existem duas configurações possíveis de persistência

  1. COOKIEINSERT (recomendado): nesse modelo o loadbalace insere um cookie informando para qual server as requisições de um determinado IP deve seguir.
  2. SOURCE IP: nesse modelo o loadbalance controla por tabelas internas o IP de origem e para qual server deve enviar as requisições.

Ambos funcionam, no entanto, o COOKIEINSERT utilizará o loadbalance de maneira mais otimizada, principalmente nas requisições que tem origem no APPSERVER, pois, com o modelo SOURCEIP as requisições de origem do APPSERVER sempre irão para o mesmo JBOSS devido ao fato de que todas as requisições possuem o mesmo IP.

Importante ressaltar sobre o timeout do produto e do balance, o timeout do balance nunca pode ser menor que o timeout do produto, pois isso acarretará em erros de http status 500 internal server error. Para saber qual o tempo de timeout do produto Datasul basta olhar a configuração no datasul-framework.properties como mencionado neste documento Timeout DATASUL

EX: caso o session.timeout=30 o balance precisa obrigatoriamente ser configurado com um valor acima de 30 EX: 35 ou 40 minutos. 

06. CONFIGURAÇÃO CONNECTOR JBOSS PARA CONTROLE DE COOKIES

Para correto funcionamento do controle de sessões do produto datasul via cookies é importante configurar o gerenciamento de path no connector do JBOSS. Para isso é preciso validar no arquivo server.xml (deploy/jboss-web.deployer/) na tag Connector se está definido o atributo: emptySessionPath="true".

07. USUÁRIOS EMS E ACESSO VIA AD

O controle de usuários na base EMS do Datasul é realizado pelo programa SEC000AA, nesse programa é possível cadastrar os usuários e suas configurações. Portanto, quando existe uma configuração do usuário do EMS com um extensão do AD o sistema tratará o usuário como externos e nesse cenário o login (Authentication) é feito vai configuração do AD do cliente e as funcionalidades do sistema são realizadas usando o usuário EMS do produto.

Sendo assim, é importante validar as configuração de validade de senha e validade do usuário. Para isso devemos:

  1. Validar no programa SEC000AA → Caso o usuário esteja com uma Validade Senha inválida alterar para uma data válida.
  2. Validar no programa SEC000AA → Caso o usuário seja autenticado via AD, o Tipo Acesso estará como Externo e a Data de Validade estará como 31/12/9999 (Indefinido). Caso a data esteja inválida será necessário alterar o usuário para Interno, alterar a data e alterar novamente para Externo.