Engine
Introdução
O Engine é um aplicativo executável desenvolvido essencialmente em Delphi e C++ e feito para funcionar no sistema operacional Windows. Ele é a base da Plataforma Bematech ERP. Possui uma arquitetura híbrida de servidor e cliente. Seus principais componentes são:
Servidor Web (HTTP);
Cache de diversas tabelas do banco de dados;
Interpretador JavaScript;
Sistema de arquivos virtual e embarcado;
Editor e depurador de códigos;
Protocolo de comunicação Engine (UAP);
Ferramentas para instrumentação e análise de desempenho;
Interface para análise de concorrência e consumo de memória;
Objetos facilitadores de acesso e manipulação do banco de dados;
O Engine possui ainda uma integração com a Java J2SE, comumente usado para a criação e consumo de WebServices. O acesso aos SGBDs é feito através de drivers criados especificamente para cada banco. Hoje o Engine suporta os bancos Oracle, MSSQL Server e PostgreSQL.
A arquitetura do Engine
O infográfico abaixo representa a arquitetura do Engine.
Note que o servidor HTTP é acessível tanto via browser quanto via outra instância do Engine. Quando a conexão for de Engine para Engine, o protocolo usado na comunicação é o UAP, protocolo de propriedade da Bematech. Se a conexão for feita de Browser para Engine, o protocolo obviamente será o HTTP.
O Scheduller é o agendador de tarefas. Uma tarefa nada mais é do que a programação de execução de um script da Virtual File System.
Local Cache é um banco de dados disponível em cada instância do Engine que guarda dados de tabelas cadastrais do banco de dados, tabelas de movimentação não estão no cache local. O Local Cache é sincronizado com o banco de dados a cada 30 segundos.
A caixa Native Objects, no infográfico acima, representa os objetos nativos publicados no ambiente iJavaScript do servidor. São exemplos de objetos nativos: DataSet, Connection, Request, Response, etc.
Cliente e Servidor de Aplicativo
O Engine pode ser configurado como um servidor de aplicativo, assumindo a função de se conectar com o banco de dados para responder às requisições de outros Engines (clientes), seja para consulta e gravação de dados, agendar e realizar a execução de scripts, enviar emails, entre outros.
A conexão com o banco de dados ocorre através de drivers próprios, ou seja, a própria DLL cliente de cada SGBD é utilizada para um acesso mais otimizado.
Servidor HTTP
O Engine é um servidor web e, assim, responde às requisições feitas através de um navegador, seja ele qual for: Microsoft Internet Explorer, Mozilla Firefox, Google Chrome, Apple Safari, Lynx (browser somente texto), Wap (telefones celulares antigos), iPhone, iPad, Android, Palm, Game Consoles, Set Top Boxes etc.
O Engine implementa os protocolos HTTP 1.0 e 1.1 diretamente sobre TCP/IP, sem nenhuma outra camada de pacote de software entre eles.
A comunicação com browsers é realizada em blocos de 10Kb, permitindo ao Engine controlar diversos canais de comunicação simultâneos.
O mecanismo automático de controle de sessão sempre mantém o código da aplicação empresarial protegido de outras sessões.
Configurações, estatísticas e informações de desempenho estão disponíveis no Servidor HTTP através de qualquer browser.
Quando o Engine está atuando como um servidor HTTP e perde a conexão com seu Servidor de Aplicação, ainda se pode atender requisições dos browsers.
Caso o desenvolvedor tenha produzido códigos especiais para situações em que se esteja off-line, algumas operações podem ser concluídas de forma transparente. Exemplo: um usuário, fornecendo informações transacionais que não necessitem ser checadas em um servidor de banco de dados central, pode inserir todas as edições no Scheduller do Sistema, que irá salvá-las localmente até que a conexão seja reestabelecida. Neste momento, as edições salvas são submetidas ao servidor central para gravação no banco de dados.
A integração do servidor HTTP e de aplicação, juntamente com suas características de funcionamento distribuído, permite que algumas aplicações possam operar ininterruptamente durante uma queda na conexão com o SGBD.
Topologia Cliente X Servidor
Conforme vimos, a comunicação com o Engine se dá através de um navegador web (servidor HTTP) ou de um outro Engine (servidor de aplicativo). A comunicação com um navegador web é feita através do protocolo HTTP. Já a comunicação com um Engine é feita através de um protocolo proprietário chamado IAP.
Como podemos ver, o Engine possui a estrutura de um servidor central e clientes que podem também ter um servidor ou podem simplesmente acessar o servidor central através do browser.
No servidor central, deve estar configurado o domínio a ser acessado e o banco de dados. Apenas o servidor central fará conexão direta com o banco de dados.
Um cliente com um Engine funcionando de servidor local, comunicando-se com o servidor central, visa maior desempenho na utilização da ferramenta. Isso ocorre pois haverá um cache nesse servidor local, agilizando o acesso ao dado. Esta configuração serve também para "isolar" o funcionamento da rede em um determinado ambiente. Exemplo: um cliente com duas lojas, tem um servidor central. Em cada uma dessas lojas há um Engine cliente, então o funcionamento desses Engine's está independente em cada loja, sendo sempre sincronizado com o servidor central para que sincronize com a outra loja.
Cache de Dados - BematechLocalCache
O BematechLocalCache é um banco de dados local embutido no Engine. Este banco contêm a estrutura e os dados de tabelas previamente selecionadas pelo desenvolvedor da aplicação. Geralmente, estas tabelas são muito acessadas para leitura e recebem um número pequeno de atualizações (inserções, atualizações e deleções). Em nosso Sistema, este tipo de tabela é entendida, de uma forma geral, como uma tabela cadastral. Exemplos de dados desta natureza são: Clientes, Produtos, Fornecedores, Empregados, Máquinas, outras tabelas pequenas, etc.
Para manter o BematechLocalCache sempre sincronizado com o banco de dados, há uma execução independente que é ativada depois que uma requisição é feita ao Engine servidor. Isto ocorre em períodos de 30 segundos e este intervalo pode ser configurado.
A sincronização do cache pode ocorrer implícita ou explicitamente. A sincronização implícita ocorre quando um programa referencia um conteúdo (chave) que não está em cache. Explicitamente, a sincronização ocorre quando o programa executa um método específico para atualização do cache.
A disponibilidade destes dados para o Engine permite a composição de conteúdo HTML dinâmico sem precisar acessar o servidor de banco de dados. Isto se reverte em excelente desempenho na entrega de códigos HTML que estejam com dados em cache.
O desenvolvedor pode ainda criar queries ao servidor de banco de dados, sem realizar joins à estas tabelas do cache. Isto minimiza o uso de largura de banda, visto que nenhuma das informações de cache precisam ser transferidas.
O BematechLocalCache também permite que o desenvolvedor crie índices cruzados. Com isso, ele poderá criar índices em uma tabela que, de forma transparente, referenciem dados de uma outra tabela.
Interpretador JavaScript - iJavascript
A linguagem iJavascript é uma rápida e poderosa implementação do JavaScript.
A linguagem Javascript é de fácil aprendizagem e está disponível em qualquer browser moderno, por isso é possível compartilhar alguns códigos e bibliotecas de forma transparente entre browsers e o Engine.
Seguem alguns pontos que merecem destaque quanto à iJavascript:
O acesso ao BematechLocalCache é feito de forma fácil e transparente;
São usados métodos especiais para controlar a conversão de strings HTML e strings SQL: toHtmlString() e toSqlString();
Possuem suporte a “include” e “includeOnce”, que inserem códigos de um script no corpo de outro script;
Com o suporte ao RMI (Remote Method Invocation), do browser para o Servidor HTTP do Engine, o navegador não precisará recarregar as páginas que contenham atualizações dinâmicas (AJAX).
Licenças
No Engine, há o conceito de licença que está associada a cada script, cada registro ou a cada classe inserida. Ao se inserir um registro no banco de dados, ele recebe automaticamente uma chave única dentro do Sistema. Cada tabela do Sistema tem uma coluna chamada CHAVE ou iKey. Esta chave é, para todo o nosso ERP, o identificador único do registro que a contém.
Para a Bematech, uma licença é o que o cliente irá adquirir a fim de utilizar o Sistema, pois ao ter uma licença de um produto, ele tem todas as funcionalidades existente naquela licença. Observe que o conceito de licença está diretamente relacionado com o conceito de produto.
Uma licença pode ser entendida como uma das faixas de chaves especificadas em nosso cadastro de licenças, ou seja, em nossa tabela iLicense. Para cada licença neste cadastro, as chaves pertencentes a ela são definidas em dois grupos. O primeiro grupo de chaves é lido a partir de uma chave inicial e uma quantidade de chaves a partir dessa chave inicial. O segundo grupo associado a esta faixa, é uma lista de diversas chaves que não estão no primeiro grupo.
Assim, dentre todas as tabelas do Sistema, um produto é entendido como o grupo de registros cujas chaves únicas estejam dentro da lista de chaves de uma determinada licença.
Chave Negativa
Chaves negativas são as chaves que pertencem às licenças existentes em nosso ERP, ou seja, licenças definidas pela própria Bematech. Em sendo um registro de chave negativa, é potencialmente eleito para participar de um processo de atualização entre duas bases de dados. Em outras palavras, apenas registros de chave negativa podem ser enviados a outras bases de dados.
Chave Custom
Existe uma faixa especial de chaves negativas. Esta faixa é de uma licença que leva o nome CUSTOM, cujo mantenedor é o próprio cliente. A base geradora da licença CUSTOM deve ser a base de desenvolvimento do cliente e deve ser única. Como é também um grupo de chaves negativas, a licença CUSTOM é portável entre as demais bases do cliente. A propósito, a portabilidade dos registros é a motivação primária da criação de chaves negativas.
Chave Positiva
Registros com chave positiva são considerados sem licença. Esses registros não podem ser exportados entre as bases, uma vez que, sendo positiva, essa chave já pode ter sido utilizada na outra base, causando uma referência múltipla àquela chave. Registros de chave positiva são comumente registros relativos aos dados propriamente ditos, ou seja, cadastros, vendas, movimentações financeiras, movimentações do estoque, etc. Dessa forma, podemos entender facilmente que tais dados não são migráveis.
Virtual File System - VFS
Na Plataforma Bematech ERP, podemos criar arquivos e diretórios em uma estrutura chamada Virtual File System (Sistema de Arquivos Virtual) ou simplesmente VFS. Na VFS, armazenamos todos os diretórios e arquivos necessários para a execução das aplicações executadas no Web Framework. A utilização de um Virtual File System faz com que a aplicação cliente não precise saber detalhes sobre a implementação real do sistema de arquivos. Dessa forma, em nosso Sistema, o desenvolvedor terá uma maneira única e centralizada de acessar os arquivos desejados.
A VFS foi criada com o objetivo de abstrair o desenvolvedor do local onde de fato estão armazenados os arquivos. Isto simplifica o desenvolvimento ao garantir que todos os caminhos dos arquivos são iguais em todas as instalações do Bematech ERP e que todos os diretórios e arquivos necessários serão automaticamente distribuídos e atualizados em cada servidor instalado.
O modelo de segurança também se torna mais simples e robusto com o conceito da VFS. Isso ocorre pois, ao conceder permissões aos arquivos e diretórios da VFS, evitamos o uso do sistema de permissões nativo do sistema operacional. Dessa forma, também evitamos as diferenças e incompatibilidades existentes entre os sistemas operacionais suportados pelo Engine.
A VFS encontra-se no banco de dados e é representada por uma tabela de nome iVfs. Apesar de estar no banco de dados, toda a tabela iVfs também se encontra no sistema de arquivo local de cada máquina onde há um Engine instalado. Cada registro desta tabela tem, a exemplo de todas as demais tabelas do sistema, um identificador único para todo o sistema. O identificador único fica no campo CHAVE de cada tabela e, nas tabelas de infraestrutura do sistema, este campo leva o nome iKey.
Os arquivos e diretórios da VFS podem ser editados diretamente no IDE do Engine, principal ferramenta do desenvolvedor na Plataforma Bematech ERP. A exemplo de um sistema de arquivos tradicional, nós também controlamos os arquivos através de seu tipo, ou seja, sua extensão. Para tanto, temos uma tabela com os tipos e subtipos válidos para os arquivos de nossa VFS.
Mime-Types
Um mime-type é um método utilizado pelos browser's para associar arquivos de um certo tipo com uma determinada aplicação auxiliar.
Mime-types comuns no Engine:
Atualização
Ao alterar um registro na tabela iVfs, é possível enviá-lo para diversas bases. Isso só é possível para os scripts que são de produto, ou seja, que são de chave negativa.
Integrated Development Environment - IDE
A criação e edição de scripts são realizadas no IDE do Engine.
O IDE do Engine permite ao desenvolvedor:
Visualizar, criar, alterar ou excluir diretórios/classes;
Visualizar, criar, alterar ou excluir arquivos;
Executar comandos SQLs no banco de dados;
Executar scripts JavaScript em um console;
Depurar códigos JavaScript.
Ao iniciar o IDE pela primeira vez, você poderá observar dois tipos de guia:
IDE: para criar, alterar e excluir os diretórios e arquivos;
iDBC SQL: para executar consultas no banco de dados e executar códigos JavaScript;
Para abrir novas guias, utilize a opção do menu "Exibir > Nova guia com base na ativa", ou pressione o atalho Ctrl + N. Esta opção irá criar uma nova guia do mesmo tipo da ativa, ou seja, se você estiver em uma guia IDE, será criada uma nova guia IDE, e se estiver na iDBC SQL, será criada uma do mesmo tipo.
Abaixo podemos observar a interface da guia IDE:
No lado esquerdo temos uma árvore com os diretórios do sistema. No lado direito, é exibida uma grade com os arquivos do diretório selecionado, no caso o diretório Raiz.
Na árvore de diretórios, podemos pressionar o botão direito sobre um diretório para abrir um menu com as opções:
Inserir uma novo diretório, filho do selecionado;
Excluir o diretório selecionado, caso o mesmo esteja vazio;
Renomear o diretório selecionado;
Mover o diretório selecionado;
Exibir os conteúdos dos diretórios filhos. Ao selecionar esta opção, a grade de arquivos irá exibir os arquivos do diretório selecionado e de todos os diretórios filhos do mesmo. Selecionar esta opção no diretório Raiz permite visualizar todos os arquivos do sistema;
Copiar a chave do diretório para a área de transferência.
Ao lado da árvore de diretórios, podemos observar a guia Contents exibindo os arquivos do diretório selecionado. São exibidos os seguintes campos:
Nome do arquivo;
Tipo do arquivo, determinado automaticamente pela extensão do nome do arquivo, seguindo a nomenclatura do MIME media type.
Ordem, conceito não mais utilizado pelo Bematech ERP.
Licença, indicando de qual produto do Bematech ERP este arquivo faz parte.
Conteúdo do arquivo;
URL, caminho completo do arquivo.
Os botões destacados na imagem como Navegação arquivos, permitem navegar nos registros da grade da guia Contents, inserir, excluir arquivos, confirmar ou cancelar as alterações realizadas.
Ao criar um script verificar em qual licença foi criada, pois pode interferir em um upgrade para uma base. A forma de definir a licença para criação de script e classe no IDE é: Tools > License to create keys > Escolher a licença.
"No license" a chave será positiva e não irá interferir em upgrade, será somente um registro da base em que foi criado.
Para editar o conteúdo de um arquivo, podemos utilizar a guia Edit. Ela irá exibir o conteúdo do arquivo posicionado em um editor com destaque de sintaxe e facilidades para o desenvolvedor. Após a edição, podemos confirmar a alterando pressionando no botão Confirmar da barra de navegação de arquivos ou utilizando o atalho Ctrl + S.
A guia History permite visualizar as alterações realizadas no arquivo posicionado, indicando a data, hora e o usuário que alterou o arquivo. Nesta grade podemos selecionar os registros com as alterações e pressionar o botão direito do mouse para abrir as opções:
Exibir diferenças: será aberto o WinMerge, caso esteja instalado, exibindo as alterações realizadas nos registros selecionados;
Refazer a alteração
Desfazer a alteração
Por último podemos observar a barra de estados no final da janela. Ela exibe as seguintes informações:
Nome da base de dados e a porta em o Engine está servindo. Por exemplo, "PAULO:9090", significa que estamos utilizando a base de dados PAULO e que o Engine está servindo na porta 9090. Se abrirmos um navegador Web e digitarmos o endereço http://127.0.0.1:9090, observaremos que será exibida a página inicial desta base.
Nome do usuário que realizou o login no IDE.
Posição e total de registros apresentados na grade de arquivos.
Chave do diretório selecionado e o produto de qual faz parte. No exemplo, está sendo informada que a chave do diretório Raiz e informando que ele faz parte do produto INTEQengine. A chave é um identificador único do registro em todo o sistema.
iDBC
Ao acessar o menu "Exibir > iDBC SQL", é aberta uma nova aba onde é possível realizar testes e já verificar o resultado. Uma espécie de console para utilizar o iJavaScript.
No iDBC é possível fazer queries, testar funções a serem inseridas em um objeto, enfim, qualquer execução iJavaScript que se deseje fazer.
Abaixo podemos observar a interface da guia iDBC SQL:
Esta interface é composta de um editor de scripts JavaScript e uma grade que exibe o último resultado do script. Na imagem acima, a grade está exibindo o resultado do query contido na variável "ds", no caso um registro da tabela iGroupUser com os dados do usuário logado no IDE.
Podemos observar que ao lado do botão Browser, temos os seguintes botões:
Abrir um script gravado no disco local;
Gravar um script no disco local;
Executar o script;
Abortar execução do script;
Gravar no banco de dados as alterações realizadas no DataSet resultado do script.
Ao criar uma nova guia iDBC sql é sugerido um script para realizar uma query no banco de dados e um loop para manipulação do resultado da query. Por último, o resultado é deixado na pilha do script para que seja exibido na grade. Apesar desta sugestão ser o uso mais frequente da guia iDBC SQL, ela pode ser utilizada para executar qualquer script JavaScript. Este é um recurso muito útil para testar pequenos trechos de códigos.
Por último podemos observar a barra de estados no final da janela. Ela exibe as seguintes informações:
Nome da base de dados e a porta em o Engine está servindo.
Nome do usuário que realizou o login no IDE.
Posição e total de registros apresentados na grade resultado.
Informações do registro identificado pela chave do campo com foco. Na imagem acima, o foco está no campo "ilanguage" cujo valor é a chave -1898187416. Os detalhes informam que esta é uma chave de um registro da tabela iAuxiliaryTable, com código "Portuguese - Brazil", da classe Linguagens. Este recurso funciona apenas para tabelas armazenadas no cache do Engine. Os conceitos de chave, classes e tabelas em cache ainda serão explicados.
Debugger
O debugger tem seu funcionamento semelhante ao debugger do Firefox(Firebug), ou seja, é executado remotamente.
Por padrão o debug fica desativado por deixar a execução dos script's mais lenta, sendo necessário o seguinte procedimento para ativá-lo:
Com o Engine em funcionamento, no browser digitar o endereço do manage do Engine que se deseja ativar o debug (com o funcionamento local, seria por exemplo: http://127.0.0.1/manage);
Informar usuário e senha;
Ir em "Configuration";
Clicar em "General";
Marcar a opção JavaScript Debugger Enabled;
Clicar em "Save";
Reiniciar o Engine;
A forma de inserção de breakpoint nos script's é diferente dos demais IDE's. É necessário inserir a palavra reservada "debugger", que funcionará como breakpoint. É importante colocar essa palavra reservada dentro de uma condição para o usuário que estará executando o processo, pois se não o debugger irá ser iniciado para quem estiver executando o processo e estiver com o debugger ativo. Exemplo:
function Exemplo(){
if( session.userKey == /* Usuário que iniciará o modo debug */ ){
debugger;
// some code...
}
}
É importante que em testes de performance o debugger seja desativado pois além da execução dos script's ser mais lenta, há um aumento no consumo de memória.
Hierarquia de diretórios
No diretório raiz da VFS temos 3 diretórios que merecem ser destacados:
Produtos: diretório onde são armazenados os códigos fontes dos processos, relatórios e bibliotecas utilizadas pelos módulos do Bematech ERP.
Dados: diretório onde são declaradas as tabelas do Bematech ERP.
Configuração: diretório onde são armazenados configurações globais a todos os módulos do Bematech ERP. Configurações específicas são armazenadas em diretórios específicos do módulo ou do produto.
Produtos
Por padronização, criamos um diretório filho de Produtos para cada produto (licença) do Bematech ERP e um diretório especial chamado custom para os processos e relatórios desenvolvidos pelos desenvolvedores usuários do Bematech ERP. A árvore de produtos possui uma divisão forte de paternidade de códigos, segmentada em produtos e módulos do sistema.
Filho de cada subdiretório de Produtos, recomendamos a seguinte árvore de subdiretórios:
modules: onde serão definidos os módulos do produto, com os processos e relatórios;
library: bibliotecas utilizadas pelos processos e relatórios dos módulos do produto;
tests: onde serão armazenados os testes unitários do produto;
dataSources: onde são definidas as fontes de dados para os relatórios do produto;
configuration: configurações dos módulos do produto realizadas através de scripts JavaScript.
Dados
Alguns diretórios da VFS possuem uma finalidade complementar de definir uma tabela no banco de dados e uma hierarquia de classe de dados. Por este motivo, também chamamos os diretórios de classes de dados. Na Plataforma Bematech ERP o termo diretório e classe são sinônimos.
O modelo de dados é compartilhado entre todos os produtos e módulos do sistema, portanto nos subdiretórios de Dados não deve haver divisão por módulos ou produtos. Os nomes dos diretórios/classes não devem fazer menção ao módulo em que são utilizados e sim a finalidade daquela informação. A árvore de classes de Dados busca a integração e reuso de conceitos, ao contrário da árvore de Produtos que busca definir fortemente uma paternidade.
Na seção Modelo de Dados explicaremos em detalhes como um diretório pode definir uma tabela e o conceito das classes de dados.
Configurações
Algumas configurações do sistema são realizadas através de scripts JavaScript e o diretório Configurações armazena as configurações globais à todo o Bematech ERP. As configurações específicas de um produto ou módulo devem ser criadas no subdiretório configuration do produto.
No diretório Configurações, existem 2 diretórios importantes que são:
Inicialização da Sessão: contém scripts que serão executados quando um usuário inicia uma nova sessão no Web Framework;
Inicialização do iEngine: contém scripts que serão executados na inicialização do iEngine.
Módulos do Bematech ERP
Ao comparar a hierarquia de diretórios apresentada no IDE com o menu "bematech", definido na interface web, podemos perceber que nem todos os diretórios são exibidos. Um diretório para ser exibido no menu "bematech" deve ser navegável, uma propriedade do diretório definida através de um script especial que chamamos de x-class.
Se observamos os arquivos do diretório /products/Admin/modules/Admin, poderemos observar que existe um arquivo chamado 0100 WebFramework do tipo application/x-class. O conteúdo deste arquivo pode ser observado abaixo:
this.canNavigate = true;
Esta propriedade determina que o diretório é navegável, sendo exibido no menu "bematech". O primeiro nível de diretórios navegáveis exibidos no menu "bematech" são chamados de módulos do Bematech ERP. É recomendado que os módulos sejam definidos dentro dos subdiretórios "modules" da árvore de produtos.
Processos e relatórios devem ser criados dentro dos diretórios que são módulos do Bematech ERP, caso contrário eles nunca serão exibidos no menu "bematech".
É recomendado que processos e relatórios de testes sejam criados dentro de um módulo "Testes" criado em /products/custom/modules. Caso esteja módulo não exista na sua base de dados, realize os seguintes passos:
Clique com o botão direito no diretório "modules" em /products/custom e selecione a opção "Insert";
Informe o nome "Testes";
Selecione o diretório recém criado e pressione o botão de inserir um novo registro no controle de navegação de arquivos. Também pode ser pressionada a tecla "Insert" quando o foco se encontra na grade de arquivos;
Informe o nome de arquivo "9900 <<NOMEBASE>>.ic", onde NOMEBASE é o nome da base de dados utilizada. Por exemplo, em uma base de dados chamada "DESENVOLVE" o arquivo seria nomeado "9900 DESENVOLVE.ic";
Altere para a guia Edit e atribua a propriedade "canNavigate" para true, conforme código acima;
Confirme a alteração;
Observe no ambiente do Web Framework que agora será exibido um novo módulo chamado "Testes".
Se a base de dados for utilizada por mais de um desenvolvedor, é recomendado que cada desenvolvedor crie um subdiretório dentro de "Testes" com o nome do seu usuário. Desta forma, os seus testes não irão interferir com os testes dos demais desenvolvedores.
Protocolo de Comunicação - InteqapplicationProtocol
O InteqapplicationProtocol (IAP) é um protocolo de comunicação especial usado para controlar as comunicações entre aplicativos Engine.
O Engine implementa o IAP diretamente sobre o TCP/IP, não utilizando qualquer outro protocolo ou pacote de softwares entre eles.
Toda a comunicação é realizada em blocos de 64Kb, permitindo ao Engine, que atua no modo de Servidor de Aplicações, controlar diversos canais de comunicação simultâneos.
Estes blocos de dados são compactados utilizando-se o algoritmo BitStreamer e depois o algoritmo de compressão Zlib (usado no WinZip e PkZip). Com isto, garante-se a melhor utilização da largura de banda atual.
Após a compressão, os dados são então criptografados e enviados.
O UAP tem um tratamento especial para conexões TCP/IP inativas e pode, automaticamente, tentar um servidor redundante. Se todos os servidores redundantes estiverem indisponíveis, então ele falha. Se algum dos servidores voltar a ficar disponível novamente, o protocolo restaura a conexão, sem precisar que toda a aplicação seja reiniciada. Isto permite que usuários remotos, que utilizam conexões lentas ou problemáticas, não percam todo o seu trabalho quando a conexão falha.
O algoritmo BitStreamer é uma rotina de compressão especial que analisa informações de datasets, eliminando redundâncias que passariam despercebidamente pelo algoritmo de compressão Zlib:
Sequências de registros com campos inalterados;
Incrementos entre campos de registros;
Salto pelo número de campos inalterados;
Transformações em sequências (streams) de bits;
Conector Engine X Engine
A comunicação entre um Engine cliente e seu Engine servidor (servidor de aplicação) é feita através do objeto connection. Este objeto é uma instância nativa da classe Connection.
Objetos da classe Connection representam conexões UAP (protocolo acima descrito) entre aplicativos Engine.
Algumas das utilidades de um objeto da classe Connection:
Solicitar uma execução de script ao Engine servidor. Isso geralmente é feito quando o processamento precisa ser centralizado, quer seja para um melhor aproveitamento dos recursos envolvidos, quer seja para processamento em background, liberando a aplicação cliente para continuar no fluxo de um atendimento mais prioritário;
Verificar se a conexão com o servidor está online;
Verificar a versão do aplicativo iEngine.exe em uso;
Obter data e hora do servidor;
Agendar o envio de um email pelo servidor;
Conectar um engine a outro que não seja o seu Engine servidor;
Conector Engine X Banco de Dados
Para o acesso ao banco de dados, o Engine disponibiliza um objeto nativo chamado database. Este objeto é uma instância da classe DataBaseProxy e está conectado ao Engine servidor, que por sua vez cede o acesso ao banco de dados.
O database objeto oferece dois métodos principais de comunicação com o banco de dados:
database.query()
Utilizado para enviar uma ou mais queries de SELECT ao banco de dados. Este método retorna um ou mais DataSets com o resultado da consulta.
database.executeSQL()
Através deste método, podemos enviar comandos DML e DDL que nada retornam. Este método é útil quando se deseja enviar comandos do tipo INSERT, DELETE, CREATE, DROP, etc.
Caso o SGBD a ser consultado não seja o que está associado ao Engine, podemos utilizar a classe DataBaseProxy e criar uma conexão a outro banco de dados. Estas conexões são feitas sempre através de um Engine servidor conectado ao banco de dados que se deseja acessar.
Manage
O Manage é uma interface de gerência e configuração do aplicativo iengine.exe. No Manage, são definidas configurações que só serão usadas pelo engine onde foi configurado, como por exemplo, qual o nome dos arquivos de logs a serem gravados, se o debugger é habilitado ou não, dentre outras. É também através dele que temos páginas voltadas para análises como: listagem das requisições UAP e HTTP, detalhes sobre o consumo de memória, informações sobre sessões abertas, leitura de logs por categoria, etc.
Abaixo, segue uma breve descrição conceitual sobre cada item disponível no menu desta interface. Para saber mais detalhes sobre a configuração destes itens, favor acessar a página Configuração do Engine.
Configuration
Esta é a principal seção de configuração. Aqui definimos diversos parâmetros como senha de acesso ao Manage, porta em que a aplicação será disponibilizada, dados para a conexão com o SGBD, etc. A seguir, listamos cada opção disponível nesta seção, bem como uma breve explicação sobre o item.
General - Definem parâmetros básicos como: mudança da senha e nome do usuário para acessar o manage, habilitar o uso do debbuger, habilitar o log do profiler, etc.
Domains - É onde se configura qual servidor o engine está acessando. Já é preenchido automaticamente se você definiu isso nos parâmetros do executável.
Databases - Aqui é onde se configura o acesso ao banco de dados associado ao engine. A configuração dependerá de qual SGBD está em uso. Nesta área, definimos dados como tipo do banco de dados (ORACLE, MSSQL, POSTGRESQL), usuário e senha para acesso ao banco, número máximo de conexões simultâneas ao banco de dados, etc.
Others - Definição de algumas configurações mais técnicas. Para mais informações, acesse essa opção e observe um texto explicativo para cada configuração em uso.
Ports - Local onde configuramos as portas do engine, em qual porta ele vai ocupar quando for iniciado. Se a mesma estiver ocupada ele tentará ocupar a próxima porta. Nessa configuração só é necessário indicar o número da porta, o protocolo de comunicação e se a porta será habilitada ou não.
Requests
Controle de todas as conexões/requisições do engine. Através do requests, você pode abortar algumas queries, analisar o profiler associado a cada requisição, ver o tempo das requisições e, em alguns casos, quem as disparou, etc.
Sessions
Esta opção é útil no monitoramento das sessões criadas no engine. É uma importante ferramenta que pode ser usada nos diagnósticos de erros e consumo excessivo de memória.
Memory
Mostra gráficos que representam o consumo de memória do engine em determinados períodos acumulados: ultima hora, ultimas 24 horas, últimos 7 dias e últimos 60 dias.
Profiler
Exibe o log do profiler se o mesmo tiver sido habilitado através do menu Configuration/General. O log do profiler é um detalhamento quantitativo sobre informações relativas ao desempenho da execução de algumas rotinas. Tais rotinas foram previamente preparadas para ter o detalhamento do profiler.
Log
Aqui você pode visualizar os logs do engine e fazer novas configurações de logs. São várias as categorias de log e cada uma traz informações a ela relacionada. Como exemplo de categorias, temos log do: scheduler, dbCache, application, network, etc.
Agendador de Scripts (Scheduler)
Através do Scheduler é possível agendar uma execução de um script JavaScript em um determinado momento ou numa determina frequência. É um recurso interessante para automatizar a execução de processos demorados e ou frequentes e que precisam ser disparados em horários específicos.
Usando o Scheduler é possível criar aplicação com execução de scripts assincronos, este recurso permite construir interfaces mais rápidas deixando alguns processos que não precisarão mais de interação com o usuário executando em background.
Tabelas de Agregação de Dados
O Engine possui uma estrutura que mantem dados agregados (apenas de soma) de uma determinada tabela. Essa estrutura proporciona ganhos de performance no desenvolvimento de relatórios bem como em validações de saldos em operações (ex.: validação de estoque).
Segurança dos Dados
O Engine fornece uma estrutura de usuários e grupos de usuários que permite definições de permissões aos dados. Os tipos de permissões padrões são: ver, inserir, alterar e excluir pelo tipo do dado. Essa estrutura permite ser estendida podendo incluir outros tipos de permissões como: aprovação, criar pedido, cancelar nota fiscal, etc.