diferenciais da camada tecnológica

1. Arquitetura em 4 camadas

1.1 Banco de dados (no DataCenter)

1.1.1 Suporte aos bancos de dados: Oracle, MS SQL Server, PostgreSQL (open source), sobre o sistema operacional de preferência: Linux ou Windows | Isto permite a migração para qualquer banco de dados relacional que atenda ao padrão SQL com mínimo esforço | Outros sistemas no mercado que dependam de um único banco de dados, não permitem que o cliente mude para outro fornecedor. O ideal é que a empresa tenha liberdade para utilizar o banco de dados que melhor suporte suas necessidades de crescimento

1.1.2 Tratado como repositório de dados, sem criar dependências com "stored procedures" ou estruturas específicas de um determinado fornecedor, permitindo a migração de um banco de dados para outro sem maiores esforços de desenvolvimento (preparado inclusive para migração para novos produtos inovadores com alta escalabilidade como www.nuodb.com) | Não utilizar "stored procedures" libera capacidade de processamento do servidor de banco de dados para a execução de consultas e gravações de dados, aumentando a escalabilidade geral do sistema. As lógicas de programação utilizadas nas "stored procedures" podem ser distribuídas entre vários servidores de aplicativos conectados via gigabit ethernet e rodando códigos em JavaScript

1.1.3 Armazena além dos dados normais do sistema, todos os códigos do ERP, com suas regras de negócios e possíveis customizações | Isto permite a fácil atualização de todo o sistema de forma centralizada, e que será replicada automaticamente, sem intervenção humana, através da tecnologia de caches locais | Outros sistemas no mercado podem necessitar de grande esforço de gerenciamento de múltiplas versões do sistema rodando em localidades físicas distintas (grande risco), ou compartilhar diretórios através de redes de dados distintas com exigência de abundante largura de banda, ou ainda necessitar o uso de tecnologias de emulação de terminal

1.1.4 Alto desempenho para consulta de informações já agregadas de forma automatica através da tecnologia própria de "Tabelas de Soma". Informações de uma tabela de origem são selecionadas para participar de uma tabela destino que possui campos de agregação e outros com totais somados a partir da tabela origem. A manutenção destas tabelas destino ocorre de forma transparente e sem travar transações de escrita na tabela origem | Esta tecnologia funciona em qualquer banco de dados suportado, e traz vantagens de escalabilidade mesmo para bancos de dados que implementam funcionalidade similar, porém com grande comprometimento de performance durante as transações de escrita nas tabelas de origem

1.2 Servidor de Aplicativos (no DataCenter)

1.2.1 Acesso aos bancos de dados realizados diretamente através dos drivers nativos escritos em C, que oferecem o melhor desempenho por não trabalhar com camadas de abstração como: ODBC, JDBC, BDE, IDAPI, etc. | Estas camadas de abstração de bancos de dados implementam muitas vezes um subset das funcionalidades disponíveis no driver nativo escrito em C e podem comprometer performance para atender ao padrão de abstração

1.2.2 Permite balanceamento de carga entre múltiplos servidores de aplicativos rodando paralelamente, trazendo alta escalabilidade para o Sistema | Outros sistemas no mercado podem utilizar a tecnologia ultrapassada de duas camadas: Banco de Dados e Cliente executável em Windows/Linux, não existindo maleabilidade de balanceamento de carga sem dependência do banco de dados

1.2.3 Permite execução de códigos do ERP próximos ao banco de dados, sem necessitar usar "stored procedures", aumentando a escalabilidade da solução por aliviar a capacidade de processamento do servidor de banco de dados

1.3 Servidor de Web (no DataCenter e em Filiais ou locais com baixa largura de banda)

1.3.1 Implementação nativa (não é Apache ou IIS) sobre TCP/IP, otimizado para atender a chamadas HTTP/S específicas para Sistema de Arquivos Virtual dos softwares, e que se instala de forma simples; uma vez instalado, realiza auto-upgrade de forma transparente sem intervenção humana | O servidor Web dos softwares é simples de ser instalado/atualizado pois não depende de outro processo que precise ser instalado ou administrado gerando dependências para área de TI do cliente | Outros sistemas no mercado podem depender de executável na estação cliente para rodar a interface com o usuário (não usa navegador de internet), as vezes possuem uma ou outra funcionalidade Web com algumas interações implementadas (isso é ruim pois existem dois padrões distintos de interação com o sistema). Quando possuem alguma solução realmente Web, normalmente seguem modelo tradicional com servidor Apache ou IIS centralizado com todo seu esforço de instalação e configuração, sem prever replicação entre servidores Web espalhados por localidades físicas distintas (filias) de forma simples e automatizada, sem sobrecarregar largura de banda

1.3.2 Pode ser executado em qualquer computador Windows, inclusive em filiais ou escritórios remotos; ou ainda num notebook de um profissional remoto; trazendo excelente desempenho aos usuários de navegadores de Internet que apontem para este servidor local, pois estará utilizando infraestrutura de rede local com alta largura de banda e baixa latência, eliminando a necessidade de funcionar através de tecnologias de emulação de terminal (Terminal Services / Remote Desktop / Citrix Metaframe) | Esta tecnologia é excelente, pois, sob demanda, o Servidor Web pode ser instalado de forma simples, aumentando a escalabilidade do Sistema e oferecendo excelente desempenho de servidor dedicado a um conjunto de usuários | Outros sistemas de mercado normalmente trabalham com executável Windows como interface para o usuário final. Isso cria dependência de link com alta largura de banda para funcionar com boa performance. Localidades remotas são atendidas por emuladores de terminal (que exigem estrutura de servidores para suportar a execução de cada sessão com usuários) ou possuir bancos de dados replicados em suas estruturas. Isso também é ruim, pois eleva os investimentos e custos com suporte e manutenção. Se o cliente opta por trabalhar com bancos de dados replicados em filiais, ele depende de uma instalação complexa que exige grande esforço da equipe de TI para instalar e manter atualizado, além de ter que configurar, manter e monitorar rotinas de integração entre o banco da filial e o da matriz, inserindo enormes riscos às rotinas de integração que são necessárias para quem opta por este modelo

1.3.3 Se comunica com Servidor de Aplicativos sobre TCP/IP em protocolo compactado e encriptado que exige baixa largura de banda (128kbps, exemplo: modem 3G, ADSL) e pode ter latência alta (até 800 ms, exemplo: links via satélite). Isto simplifica e barateia os investimentos em links de acesso a Internet | Outras soluções de mercado normalmente dependem de links com alta largura de banda e baixa latência, isso aumenta significativamente os custos com comunicação. Ambientes remotos, podem exigir instalações de bancos de dados ou o uso de emuladores de terminais

1.3.4 Possui tecnologia de cache local, que replica e mantém sincronizada as informações cadastrais do sistema, regras de negócios, códigos do ERP..., permitindo executar rotinas sem necessidade de consultar o banco de dados, além de aumentar a escalabilidade, pois diminui a exigência de processamento no banco de dados, já que não é necessário realizar "joins" para trazer informações já existentes no cache local, bem como não é necessário realizar "selects" sob demanda para trazer informações cadastrais também já presentes no cache local | Toda esta tecnologia funciona sem necessidade de instalação de banco de dados local independente

1.3.5 Utiliza a linguagem de programação: JavaScript, linguagem de script mais utilizada no mundo, padrão utilizada para o desenvolvimento de aplicativos para Web. Todo o código do ERP está implementado em JavaScript, e está disponível para visualização e extensão por desenvolvedores que possuam a devida permissão de acesso

2.2 No navegador de Internet, basta apontar para o endereço de um dos servidores Web do Sistema, automaticamente estará rodando a última versão disponível

2.3 Como os programas do Sistema estão armazenados no banco de dados, toda vez que sofrem alguma atualização, automaticamente são atualizados para os caches locais de todos os servidores de aplicativos e Web | Isto permite a execução agressiva de liberações de novas funcionalidades em novas versões do Sistema com simplicidade de liberação para todos os usuários | Outros sistemas de mercado normalmente usam padrão de atualização tradicional que depende muito da área de TI, e portanto gera grande esforço de acompanhamento nos processos de atualização. Quanto mais componentes usam, mais burocrático é o processo. Quanto mais localidades, pior

voltar ao topo

3. Modelo de Dados

3.1 Modelagem relacional, porém com recursos de orientação a objetos | Esta tecnologia é excelente, pois elimina desenvolvimentos redundantes de regras que precisam ser replicadas para cada tabela

3.2 A tabela CLASSE implementa uma hierarquia de classificação para todos os registros do Sistema. Uma árvore ilimitada, que permite que propriedades definidas para uma classe mãe sejam herdadas para classes filhas, otimizando a configuração de todo o modelo

3.3 Esta estrutura permite a existência de classes como a "Pessoas", que se subdivide em "Clientes", "Fornecedores" e "Funcionários". Todas as propriedades definidas para "Pessoas" são herdadas para as demais, não existindo necessidade de um "Cliente" estar cadastrado também como "Fornecedor" para permitir registro de operações com "Pessoas"

3.4 Em uma tabela como a PEDIDO, onde registramos todas as compras e vendas do sistema, nos é suficiente informar que o campo PESSOA é uma referência a classe "Pessoas". Automaticamente podemos vincular qualquer registro cujo campo CLASSE esteja na hierarquia "Pessoas", seja ele da própria classe "Pessoas" ou de algum filho

3.5 Esta árvore de classes também é tratada como um diretório de um sistema de arquivos virtual (iVFS virtual file system) onde estão todos os códigos do sistema, inclusive os processos e relatórios; e que é mantida dentro do banco de dados

3.6 Todas as tabelas do Sistema possuem os campos: CHAVE, CLASSE e VERSAO

3.6.1 O Campo CHAVE possui um número inteiro que identifica o registro em todo o modelo de dados (não é exclusivo da tabela). De posse de uma chave, um usuário consegue descobrir a operação original sem precisar associar a nenhuma outra propriedade

3.6.2 O campo CLASSE vincula o registro à árvore de CLASSEs

3.6.3 O campo VERSAO determina o número da última transação no banco de dados que tocou este registro. Também é através deste campo que é realizado o controle de travamento de registros de forma otimista: o registro só é travado no momento em que toda a transação está no momento final de gravação (não mantendo a trava enquanto não estivermos próximos de finalizar). Se dois usuários estiverem mexendo num mesmo registro, a transação que conseguir finalizar primeiro tem o sucesso, e a outra falha forçando intervenção do usuário

3.7 Tabelas de parametrização do Sistema permitem o cadastramento de regras de negócios partindo da forma mais abrangente, e inserindo exceções para as necessidades mais específicas. Exemplo: regras para comissão podem estar definidas para toda empresa, porém para uma determinada loja experimentalmente estar definida uma regra específica. Ou para uma classe de produtos (e todas as suas filhas), estar definida uma exceção. Isto vale também para parâmetros tributários, não sendo necessário replicar regras para cada produto, de contextos válidos para uma classe inteira de produtos. Isto facilita o cadastramento e entendimento das regras, pois elas são representadas no sistema da maneira com que normalmente expressamos as regras (por classes). Outro exemplo: Condições de pagamento, podem ser configuradas para toda empresa, ou definidas exceções por filial, classe de filial, ou classe de cliente

3.8 Movimentações no sistema seguem um modelo simplificado onde o estorno das mesmas é representado pela mesma operação original registrada com sinal invertido. Ao somar estes registros, teremos o saldo líquido das operações. Exemplo: Ao somar as operações de vendas, as devolução são registradas também como vendas, mas com sinal invertido na quantidade e em todos os valores, fazendo com que o resultado desta soma apresente a venda líquida. "Pessoas" possuem "Títulos" a pagar e receber; ao somar estes títulos pendentes temos o saldo financeiro líquido a pagar ou receber de uma determinada "Pessoa", não importando se esta é "Cliente", "Fornecedor" ou "Funcionário"

voltar ao topo

4. Segurança e Auditoria

4.1 Todo acesso ao sistema pode ser forçado sobre o protocolo HTTPS, mesmo padrão utilizado para acessar instituições financeiras pela Internet, como Bancos

4.2 Os acessos dos usuários são determinados por perfil/função ou grupos e podem definir limites para determinados processos, relatórios ou mesmo restrição de acesso a determinados registros de uma tabela (permissão de acordo com a CLASSE do registro: visão, execução, inclusão, edição e deleção)

4.3 A política de senhas segue o padrão ISO 27001, e a validação de login pode ser integrada ao padrão Active Directory

4.4 Todas as edições de registros são registradas em logs no próprio banco de dados, que permitem a auditoria e rastreabilidade completa das alterações: Quem, Quando, Onde, O quê, Como estava antes e como ficou

voltar ao topo

5. Desenvolvimento e customizações

5.1 A linguagem de programação é JavaScript, a linguagem de script mais utilizada no mundo por estar presente em todos os navegadores de Internet. Possui farta documentação na Internet, bem como uma comunidade efervecente de desenvolvedores e ferramental sendo incrementado cotidianamente | Isto simplifica a diluição do conhecimento existente nos códigos, permite reaproveitamento de bibliotecas já existente no mercado, facilita a contratação de novos profissionais | Outros sistema de mercado normalmente trabalham com linguagem de programação proprietária ou variação do ultrapassado padrão DBase. Isso diminui a oferta de literatura/ferramental e cria ambiente onde códigos não podem ser compartilhados com outras plataformas

5.2 Por usufruir do modelo hierárquico de CLASSEs de dados, a quantidade de tabelas existente é extremamente reduzida, simplificando o modelo para os desenvolvedores, trazendo maior agilidade ao desenvolvimento

5.3 O desenvolvedor não manipula diretamente as transações no banco de dados. Todo o controle é feito pelo servidor de aplicativos, que garante segurança e performance para transações de escrita, mantendo o mínimo de tempo possível para travamento de registros sendo alterados, e também alimentando os logs | Isso elimina a responsabilidade do desenvolvedor controlar com muita cautela o contexto das transações nos bancos de dados, protegendo-o de equívocos além de trazer segurança para empresa, pois força o registro das transações nos logs de auditoria | Outros sistemas de mercado normalmente permitem que o desenvolvedor manipule transações diretamente no banco de dados. Isso abre brechas para travamentos de registros por longo período de tempo, principalmente quando uma transação está sendo controlada por código rodando em uma estação cliente (pode ocorrer de uma transação ser iniciada em um cliente remoto, alguns registros serem travados, e a conexão com o banco de dados ou servidor de aplicativos ficar inativa antes de se finalizar a transação), diminuindo a escalabilidade da solução

5.4 O desenvolvedor trabalha com enorme produtividade em uma alta camada de abstração. Ele foca seu trabalho na definição de regras de negócios, fórmulas de cálculo, validações; quando necessita interagir com o usuário, cria processos que possuem grades de interação com dados. O framework (bibliotecas de interface) é o responsável por montar os procesos e grades definidos pelo desenvolvedor em uma interface HTML a ser renderizada no navegador de Internet. Para o desenvolvedor é tudo transparente. Ele não define nem a posição exata da tela onde uma informação será escrita; apenas define que uma grade usará as definições de dados (metadados) de uma determinada CLASSE para interagir com o usuário. Exemplo: No processo de "Cadastro de Clientes" ele define que haverá uma interação com o usuário, e que esta interação apresentará uma grade com as definições de campos existentes na CLASSE "Clientes"; automaticamente o framework instancia a CLASSE "Clientes" sabendo todas as informações sobre os campos que estarão disponíveis, checa as permissões do usuário para esta classe, e renderiza a grade, permitindo interação com o usuário e validando todas as regras definidas | Esta tecnologia da é excepcional pois o desenvolvedor não perde tempo com configurações da camada de apresentação dos dados. Bibliotecas de interface do sistema mantém o padrão visual de todo o sistema trazendo consistência às interações dos usuários finais. Por se concentrar apenas nas regras de negócios, o desenvolvedor entrega melhorias ao Sistema de forma muito mais ágil e segura. A implementação de novas funcionalidades ao Sistema já existente é muito mais fácil e rápida por usufruir de toda esta plataforma de base

5.5 As customizações interagem com o Sistema de forma sinérgica. Novas CLASSEs podem ser inseridas. CLASSEs já existentes podem ter seu comportamento extendido: novos eventos, novos campos disponíveis, novos labels/helps para campos pré-existentes. Novos processos e relatórios podem ser habilitados em qualquer local da árvore de acesso dos módulos

5.6 Objetos de gestão centralizam regras de negócios utilizadas em múltiplas interfaces do sistema. Exemplo: Múltiplas interfaces de venda compartilham validações de descontos, condições de pagamento, comissões e metas, tabelas de preços, cálculo tributário ou lançamentos contábeis, que são realizados exatamente pelo mesmo código. Não existem rotinas de integração, as operações são registradas em conjunto, em uma mesma transação no banco de dados; ou toda operação é gravada com sucesso, ou o usuário tem que resolver algum empecilho antes de finalizar a operação | Esta tecnologia da é excepcional pois garante segurança dos dados armazenados no banco. É a principal responsável pela robustez do Sistema. Não existem rotinas internas de integração entre os vários módulos, dispensando a necessidade de rotinas de conciliação internas ao sistema

5.7 O Gerador de Relatórios permite que o desenvolvedor se concentre em fornecer uma "Fonte de Dados" (DataSource) com as informações fundamentais de uma determinada consulta ao banco de dados, e deixa livre ao usuário final a configuração dos múltiplos layouts e agregações de resultado que possa realizar com base nestes dados originais. Exemplo: Com base em uma fonte de dados de "Pedidos" é possível filtrar vendas por período ou por filial, etc. extraindo dados agregados por cliente, com cada produto vendido, e seus totais de valores

voltar ao topo