Histórico da Página

...

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
8. Modo Operacional do AppServer
9. Broker por Empresa para Alta Performance

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.

...

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.

...

1. .

...

Para o produto Datasul JBOSS as conexões com o banco, quando originadas pelas telas html ou portais, são processadas no AppServer da progress. Esse componente é crucial para o funcionamento do produto e possui características relevantes para o correto funcionamento do produto. Uma das principais configurações desse componente é o modo operacional, ou seja, como o componente vai orquestrar as requisições e controlar os dados.

Sendo assim, o primeiro item a ser avaliado nos clientes é se existe várias empresas, pois, o produto Datasul através do programa btb962aa permite configurar banco de dados por empresa e desta forma o sistema conecta as bases necessárias no momento em que as requisições são realizadas dentro dos agentes do Appserver.

Dito isso, para atender a esse cenário a TOTVS recomenda a utilização do modelo abaixo:

1 - State-Reset: Modelo operacional que dedica o agente do AppServer a uma solicitação. Nesse modelo o mesmo agente é utilizado até o final da execução persistente que teve origem no JBOSS. Ao final da requisição todos os dados são limpos do agente do appserver para ficar pronto para uma próxima requisição.

Cenário - Várias empresas cadastradas e cada registro com conexões de bases diferentes ou similares.

Nesse cenário a TOTVS recomenda o uso de Modo Operacional State-Reset, pois, vai acontecer conexões e desconexões de bases por cada requisição em que a empresa muda.

...

Para ter uma maior performance nesse cenário recomenda-se o uso do Pool de conexões no JBOSS. Esse pool é configurado através do datasul-framework.properties como abaixo

...

09. BROKER POR EMPRESA PARA ALTA PERFORMANCE

Para uma vazão maior das requisições com o Appserver progress o modelo operacional Stateless é o mais indicado, no entanto, somente pode ser usado quando não há o cenário de troca de empresa nas conexões, o qual, ocasiona a desconexão e conexão das bases de dados.

Para conseguir ter esse benefício de performance no modelo Stateless o cliente precisa fazer a configuração dos broker do appserver por empresa. Nessa configuração o arquivo.pf, alias.p e .ini do produto são configurados para cada broker definido no Appserver progress e o JBOSS conecta-se ao broker correto de acordo com a sessions e parâmetros do usuário fazendo com que o sistema performe de maneira mais rápida.

...

<!-- esconder o menu --> 


<style>
div.theme-default .ia-splitter #main {
    margin-left: 0px;
}
.ia-fixed-sidebar, .ia-splitter-left {
    display: none;
}
#main {
    padding-left: 10px;
    padding-right: 10px;
    overflow-x: hidden;
}

.aui-header-primary .aui-nav,  .aui-page-panel {
    margin-left: 0px !important;
}
.aui-header-primary .aui-nav {
    margin-left: 0px !important;
}
</style>