01. Objetivo

Essa documentação visa explanar de forma visual e descritiva  as camadas do produto DTS4THF. Essa documentação foi escrita durante o desenvolvimento da 12.1.2305 e a última release entregue ao mercado foi a versão 12.1.2301. Essa documentação não detalha funcionalidades apenas, e em alguns casos, mencionará outras documentações de apoio.

02. Visão Geral

O gráfico abaixo mostra as camadas do produto bem como as versões de tecnologias utilizadas em cada uma delas. Vale lembrar que a camada de infraestrutura foi minimizada no gráfico para facilitar o entendimento do produto.

No produto temos a divisão das camadas de FrontEnd, Middleware, Backend e Persistência. Cada camada possui tecnologias semelhantes e também específicas para garantir a integridade do sistema e seus componentes.

1. FrontEnd: Camada responsável pela apresentação dos dados tanto em tecnologia web, client/server e apps mobile (dentre outros que ainda estão por vir).
2. Middleware: Camada responsável pela orquestração das requisições bem como a segurança de alguns tipos de acesso, principalmente a parte web e enpoints de suporte ao desenvolvimento. Essa camada é chamada de web server no Datasul
3. Backend: Camada responsável pelas regras e normas de negócios sobre o qual o sistema deve operar. Essa camada é o motor do sistema para tratamento dos dados com objetivo de negócio e toda essa camada é desenvolvimento na linguagem progress e o runtime feito pelo app server opendge tendo suporte ao Classic e ao novo PASOE.
4. Persistent: Camada de persistência de dados, ou seja, o banco de dados. Temos suporte ao Oracle e SQLServer através do componente DataServer da Progress

O Produto Datasul possui um alto acoplamento, devido ao middleware ter sido planejado como uma aplicação monolítica, ou seja, qualquer alteração no middleware é necessário bloquear o acesso pelos usuários à todas as funcionalidades. Além disso, como o sistema monolítico o appserver, responsável pela execução de negócio (BO) concorre diretamente com a execução de outros tipos de acesso como LOGIN, SOAP, REST CUSTOMIZAÇÕES dentre outras.

Com o objetivo de minimizar o problema de concorrência no appserver e atender outras demandas de ofertas de APPs, surgiu o Broker Escalável para dividir a demanda no appserver e impedir que cenários do ERP concorram com as integrações e outras requisições REST e SOAP. 

Com o broker escalável é possível dividir a demanda e inclusive escalar brokers para determinado cenário para uma maior vazão, vale lembrar que a funcionalidade do broker escalável prevê brokers iguais para uma mesma funcionalidade e nesse caso é realizado o balanceamento das requisições. No entanto, o middleware ainda estabelece uma estratégia monolítica como o anterior.

03. Assunto X

Insira o conteúdo. 

Subtítulo 1.1

Insira o conteúdo

Subtítulo 1.2

Insira o conteúdo