Arquitetura do BIS

Missão

A nossa missão é fazer do BIS (ou BISERP) um sistema que atenda de forma ampla e integrada as necessidades das empresas.

Estrutura Física

Para alcançar a missão de forma prática, o BIS será construído como uma ferramenta on-line. Capaz de funcionar "na nuvem" pelo menos em sua grande maioria de módulos e funcionalidades.

Módulos que demandem alta disponibilidade ou que dependam de comunicação direta, terão os dados sincronizados na máquina local. Mas note que estes dados só estarão disponíveis no local. Todo o processamento e lógica de operação, bem como armazenamento e backup devem continuar nos servidores do BIS.

Também é necessário que a arquitetura do BIS precisa ter uma organização que permita escalabilidade a medida que sua abrangência se torna mais ampla, o desenvolvimento e organização do código não devem ser comprometidas.

Arquitetura

A arquitetura do BIS é toda montada de acordo com os patterns e estrutura oferecida pelo J2EE, logo, faz-se necessário um prévio conhecimento em J2EE para o entendimento e desenvolvimento do sistema.

Camadas

O BIS é montado em cima de três camadas 'básicas' de arquitetura:

• Camada de Persistência - é a responsável por 'guardar' os objetos no banco de dados. É a única parte do sistema que "conhece" o banco de dados. Sabe como guardar e recuperar os objetos solicitados pela camada de lógica.
• Camada de Lógica - é a responsável por armazenar a lógica do sistema. Aqui encontram-se as rotinas que validam e processam os dados do sistema.
• Camada de Apresentação - é a camada onde estão configuradas as interfaces entre o sistema e o usuário. Nesta camada temos apenas a programação da própria interface (botões, listas, combos, cores, etc.) Embora seja possível ter alguma validação para agilizar e impedir o usuário de entrar dados inválidos, TODAS AS VALIDAÇÕES devem constar na camada de lógica.

Modularidade

O BIS apresenta uma organização interna de módulos. O Módulo nada mais é do que uma parte do sistema responsável por cuidar de algum assunto específico da necessidade da empresa. Por exemplo:

• Módulo de Items - Módulo responsável por cadastrar e gerencias os itens do sistema. Itens são os produtos vendidos ou comprados, serviços prestados ou recebidos, material comprado para consumo ou ativo da empresa, e assim por diante.
• Módulo de Fluxo de Caixa - Módulo responsável por gerenciar a parte financeira da empresa. Contas a pagar e de receber, caixas e orçamentos locais ou bancários, etc.
• Módulo de Vendas/PDV - Módulo que permite a venda em checkouts, emissão de cupons SAT/NFCe, etc..

Apesar dessa divisão em módulos, o sistema não permite o destacamento dos seus módulos (como plugins). A separação de módulos é feita em relação aos 'packages' do java, mas todo o código, ou seja, todos os módulos são empacotados juntos e estão presentes.

Habilitação do Módulo Apesar de todo o código estar presente (o que evita chegar a presença das classes durante a programação), casa módulo pode ser 'vendido' separadamente para a empresa. O que significa dizer que o usuário pode não ter acesso à algum módulo. Assim ao se implementar código em que um módulo gere, manipule ou dependa de dados de outro módulo é necessário considerar se o outro módulo está ou não presente para determinada empresa.

Serviços do BIS

Serviços do BIS são como pequenos módulos (as vezes não tão pequenos) mas que muitas vezes não tem uma funcionalidade própria além de prover agilidade ou de centralizar as informações para outros módulos. Por exemplo:

• Cadastro de Pessoas - O BIS oferece o cadastro de pessoas, que podem ser utilizadas como clientes, fornecedores, funcionários, contatos, etc. por qualquer outro módulo.
• Localização - Há uma base de dados com País, Estado, Cidade e Endereços que permite que qualquer módulo obtenha localidades de forma organizada sem ter de implementar todos esses dados de forma autônoma.
• Mail Boxes - O serviço de e-mail permite que caixas de e-mail sejam configuradas, e posteriormente os módulos as utilizem tanto para enviar quanto para receber e-mails.

Empacotamento

Empacotamento da aplicação é o arquivo para distribuição e execução da aplicação. Por ser uma aplicação J2EE o BIS é distribuido em um arquivo EAR. Atualmente dentro dele, de forma simplificada, encontramos os seguintes conteúdos:

• BISEJB - Pacote da camada de lógica do BIS e camada de Persistência. Por conta da camada de persistência simplificada do BIS, ela acabou sendo unificada dentro do próprio pacote da camada de lógica. Mas embora empacotada de forma diferente, a camada continua existindo de forma lógica e organizacional no código.
• BISVaadin - Pacote contendo a camada de apresentação do BIS destinada a WEB para Desktops.
• Bibliotecas - Bibliotecas de terceiros necessárias para execução do BIS. Como conectores de banco de dados, ferramentas de Logs, manipulação de equipamentos, etc.

Estrutura Organizacional da Informação

Escopo da Informação

Para compreender um pouco mais facilmente as informações existentes no sistema precisamos separar elas em dois escopos:

• Informações do Domínio - Entenderemos daqui para frente que domínio quer dizer toda a aplicação. Informações de configuração do sistema, ou informações que são utilizadas por todas as empresas. São informações que estão "visíveis/acessíveis" para todo o sistema independente da empresa.
• Informações da Empresa - As informações da empresa são informações particulares da empresa. Informações/dados que são peculiares à uma determinada empresa no sistema. Em outras palavras, não visíveis nem acessíveis para nenhuma outra empresa.

Banco de Dados

O BIS utiliza uma única instância do Banco de Dados, no entanto criará vários Schemas para comportar todas a sua estrutura.

Inicialmente o BIS contem dois Schemas:

• bis_kernel - Schema central e padrão do BIS. Neste schema serão guardadas as informações de Escopo de Domínio. Nele teremos as configurações do "domínio", todo da aplicação. Além de tabelas e informações que são compartilhadas para todas as empresas. Como por exemplo: Cadastro de endereços (CEPs), Cadastro de NCM de Itens, Cadastro de Tabelas Fiscais e assim por diante.
• bis_bis - Schema da empresa inicial. Sendo esta empresa a própria empresa "BIS Company", que também utilizará o sistema para gerenciar suas necessidades. Como controle dos clientes, fluxo financeiro, etc.. Neste schema são guardadas as informações relacionados a empresa "BIS Company", ou seja, é um schema com escopo de Informações da Empresa.

Uma instância do BIS permite o gerenciamento de várias empresas. Cada uma delas de forma individual. Assim, cada empresa tem o seu próprio Schema no banco de dados. Por exemplo, duas empresas A e B, terão cada uma um schema separado bis_a e bis_b. Cada schema terá o mesmo conjunto de tabelas e serão estruturalmente idênticos, diferenciando apenas no conjunto de dados já que cada um conterá os dados relacionados a própria empresa. Todos esses Schemas de empresas são o mesmo utilizado no schema bis_bis.

Schema da Empresa BIS é Utilizada pelo Domínio Algumas informações com o escopo de informação do domínio estão presentes no schema da empresa "BIS Company". Essa foi uma opção para evitar que as mesmas tabelas utilizadas no schema de empresas fossem replicadas no schema do kernel. Por exemplo, a tabela de propriedades e de caixas de e-mail. Assim, quando o Kernel do BIS precisa salvar uma propriedade ou uma caixa de e-mail, esses dados são salvos no schema da empresa de "ID 1", a "BIS Company". Dito isso, torna-se obrigatório que a empresa de ID 1 seja a "BIS Copmany". Esta não pode ser excluída ou ter seu ID alterado. Dentro das tabelas ou dos objetos salvos, como as propriedades ou as caixas de e-mail, há diferentes maneiras adotadas para saber quais objetos são do domínio, e quais são da empresa. Verifique a documentação de cada serviço para verificar tecnicamente o que os diferencia e são utilizados. Detalhando um pouco mais tecnicamente, optamos por não ter as tabelas replicadas no schema do Kernel para evitar um monte de objetos diferentes. Pois a maneira como o acesso é feito entre os schemas das empresas é diferente da do acesso feito ao schema do Kernel. O que exigiria replicar também os VOs, métodos de fachada, etc..