ER_LOGSARA01-381_AppServer_Foundation_Fase_01

Informações Gerais

 Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos). 

Objetivo

Definir a arquitetura básica de evolução do produto SARA para iniciar desenvolvimentos em conformidade com novo TOTVS Html Framework, utilizando tecnologia Delphi Datasnap para fornecimento de serviços REST..

Requisitos

1. O projeto deve permitir o desenvolvimento das telas Html em paralelo ao desenvolvimento do próprio foundation (framework) a fim de atender o prazo de entrega das telas Html para o Cliente APM.
2. Deve ser desenvolvido um Aplicativo servidor de serviços REST que aqui chamaremos de AppServer. Este serviço será o controller entre as aplicações clientes que poderão ser desenvolvidas em qualquer linguagem. 
3. O sistema deve admitir a troca de tecnologia de acesso ao banco de dados a qualquer momento e a baixo custo, caso seja necessário.. 
4. O novo módulo deve garantir  que todos  parâmetros estejam configurados e todos existam na base de dados.
5. O Appserver deve conter apenas uma única instância de conexão com o seu banco de dados principal e compartilhar com os demais módulos.
6. Precisa ter uma camada DAO, para facilitar a geração dos scripts de CRUD. 
7. Precisa permitir a tradução para diversos idiomas. 
8. O sistema deve facilitar a depuração para encontrar erros de processo ou de programação.
9. É necessário tornar a codificação reaproveitável e modular.
10. O foco do desenvolvimento Cliente é a arquitetura do Novo TOTVS Html Framework, sendo que o Appserver será a camada Backend e não deve modificar o funcionamento e nem refazer nenhuma das camadas do TOTVS Html Framework.  
11. O Appserver será um novo aplicativo, não terá nenhuma interação direta com o sistema legado atual efetuado em Delphi 5 , Delphi 7 e ADVPL, mas deve oferecer a possibilidade de reuso de storeprocedures, tabelas, triggers e funções de banco de dados atuais.

Definição da Regra de Negócio

1. Para atender o projeto do cliente APM, o projeto será dividido em 3 fases distintas. Assim, a primeira fase deste projeto atende apenas os requisitos ao início do desenvolvimento do projeto e os demais requisitos serão tratados em paralelo.
2. Será criado um novo aplicativo AppServer, utilizando tecnologia Delphi Xe8 ou superior, que será um servidor REST DataSnap. Este serviço fará a verificação de autenticação e autorização aos recursos solicitados, efetuando então o redirecionamento ao recurso solicitado.
3. Para que o sistema não esteja preso a uma única tecnologia de acesso a banco de dados será criada uma unit uDatabaseIntf, na qual serão criadas as interfaces para os objetos de acesso a banco de dados do sistema. Esta unit será base para a criação dos objetos de banco no Delphi.

4. Para parametrização do módulo será criada uma nova tabela no banco de dados, "param_app", com os seguintes campos:
   "Id" - campo chave varchar(50) que será o nome do parâmetro.
   "Value" - campo varchar(255) que conterá o valor do parâmetro.
   "type" -  campo int que manterá  o tipo de parâmetro que está sendo criado.
   "Llabel" - campo varchar(50) que mantém o nome do literal de tradução correspondente aos labels de pesquisa deste parâmetro.
   "LlistJson" - campo que mantém o nome do literal de tradução da lista de valores que o parâmetro pode ser configurado.
   "LNote" - campo que mantém o nome do literal de tradução da descrição deste parâmetro.
   Também será criado uma unit que conterá as classes.
   Funções e procedimentos referentes a esta nova tabela, "uTblParamApp", dentro desta unit será criada uma classe referente a esta tabela TTblParamApp, que deve conter os métodos de manipulação desta tabela.

5. Para evitar o acesso múltiplo, e também simplificar a transferência da conexão com o banco de dados será criado um novo módulo "data.bpl", que será responsável pela conexão e também criação dos objetos para as interfaces de banco de dados. 
6. CRUD automático para as classes de tabelas de banco de dados será criado uma unit GenericDao.
         # Criar um classe TGenericDAO com métodos estáticos que recebam objetos genéricos para geração do CRUD da tabela referenciada.
               1 - GetTableName - Busca o nome da tabela do objeto.
               2 - Insert       -  Salva um novo registro na tabela baseado no objeto passado por parâmetro.
               3 - GetAll       -  Busca todos os registros da tabela.
               4 - Delete       -  Procedimento que gera o SQL e executa a exclusão do registro do objeto na tabela referenciada na classe passada por parâmetro. 
               5 - Update      -  Procedimento que gera o SQL e executa update na tabela referenciada na classe do objeto passado por parâmetro 
               6 - Create       -  Procedimento que cria a tabela no banco de dados.
               7 - GetInsert   -  Método que retorna o SQL gerado pelo método Get sem executar.
               8 - GetUpdate -  Método que retorna o SQL gerado pelo método Update sem executar.
               9 -GetDelete  -  Método que retorna o SQL gerado pelo método Delete sem executar.
         # Criar uma  classe de entidade de banco de dados para que as novas classes herdem dela TGenericEntity que deve conter os métodos básicos de CRUD consumindo as funções da GenericDao.
               1 - Deve ser criado um método GetByFilter que retorna todos os registro de determinada tabela obedecendo as restrições do filtro passado.
               2 - Deve ser criado um método Delete que fará a exclusão do objeto referenciado pela sua chave primária.
               3 - Deve ser criado um método Update que fará a exclusão do registro referenciado pela sua chave primária.
               4 - Deve ser criado um método Insert que fará a inclusão de um novo registro na tabela pelas informações do objeto referenciado.
               5 - Deve ser criado um método ToJson que transformará as informações do objeto em um Json, para que possa ser retornado ao sistema o cliente que estiver consumindo.
               6 - Deve ser criado um método CreateTable que fará a criação da tabela pelas informações contidas na classe do objeto; caso a tabela já exista o método deve ignorar a criação.
               7 - Deve ser criada uma variável Msg para armazenar as mensagens de retorno ocorridas nesta camada.
               8 - Deve ser criado um procedimento AddMessage para adição das mesagens no formato exigido pelo TOTVS Html Framework.
               9 - Deve ser criado um método GetAll que retorna todos os registros para determinada tabela.
7. Para traduzir o sistema fica definido que cada unit terá sua unt correspondente de tradução, a qual deve conter o mesmo nome da unit principal acrescida de ponto + language.
          # Criar uma nova unit uTranslateUltil para agrupamento das classes de auxílio no processo de tradução.
                   1 Criar uma nova classeTListLiteralLanguage que deve ser um collection de informações para tradução contento o nome do literal de tradução, o idioma e o valor de tradução.
                           a - Criar um método  Add para efetuar a inclusão dos novos literais de tradução.
                           b - Criar um método Find que localize um literal a partir de seu valor e idioma.
                           c - Criar um método FilterLanguage que filtre o collection a partir do idioma desejado.
                           d - Criar um método LoadJson para carregar a lista de literais a partir de um arquivo fornecido pelo Equipe de Tradução, sem a necessidade de inclusão das traduções no código do sistema.
                           e -  O sistema fará o carregamento dos literais a partir do arquivo de literais que permanecerá em um diretório do próprio Appserver e, caso não seja encontrado, deve gravar um log informativo do literal faltante e carregar a lista de literais que está contida na unit de tradução.
8. Para simplificar a depuração de erros o sistema deve ser criado uma unit padrão de gravação dos logs do sistema uLogUtil.
        # Dividir a gravação dos logs em 3 arquivos distintos, "language.log", "error.log", "execution.log".
                 1 -  "language.log" =  Informará a ausência de arquivos de tradução para determinada unit. Seu objetivo é levantar os arquivos de tradução que ainda não foram expedidos ou precisam ser enviados à Equipe de Tradução.
                 2 -  "execution.log" = Gravará os erros ocorridos durante a execução do sistema.
                 3 -  "execution.log" = Será um marcador da execução do sistema e será ativado a partir do parâmetro RECORD_LOG_EXECUTION. O procedimento de gravação de log deverá permitir que seja definido um Level para gravação, sendo que todos os logs com level igual ou inferior ao mencionado devem ser gravados. Será criado o parâmetro RECORD_LOG_EXECUTION_LEVEL para permitir a parametrização deste recurso.
        # Permitir parametrizar o local e o nome dos arquivos de log, Na ausência desta parametrização, todos os logs serão gravados nos arquivos com o nome acima mencionado e no diretório log que deverá ser criado automaticamente na pasta anterior a pasta onde está instalado o AppServer.
        # O sistema deve ter um arquivo de configuração "config.ini", que deverá ser criado automaticamente no diretório "config", que deve estar localizado no diretório anterior a instalação do Appserver.
                1 - Este arquivo deve conter uma seção para informações de acesso ao banco de dados denominada "[CONNECTION]". Dentro desta seção deve conter o ID do driver de banco de dados "databaseID", o nome do banco de dados para acesso "databasename", usuário administrador de banco de dados "user" e a senha de acesso "password", local e instância de acesso ao banco de dados "servername".
                               a) Para segurança da informação de usuário e senha do banco de dados, esta informação será criptografada e descriptografada durante a execução do módulo. Este desenvolvimento ficará para a segunda fase do projeto, constando nesta especificação apenas para esclarecimento.
                                b) Para que seja possível a gravação das informações de usuário e senha criptografadas dentro do arquivo de configuração será criada uma tela que permitirá a gravação de forma segura. Este desenvolvimento poderá ficar para a segunda fase deste projeto, constando nesta especificação apenas para esclarecimento.
                 2 - O arquivo de configuração deve conter uma seção "[FILE]", sendo que nela serão definidas as parametrizações do local e nome dos arquivos de log de sistema "ErrorLog", "LanguageLog", "ExecutionLog".
                 3 - O arquivo de configuração deve conter uma seção "[CONFIG]", sendo que nela será definido o idioma padrão de gravação de logs "language".
                 4 - O arquivo de configuração deve conter uma seção "[DIRECTORY]", sendo que nela será definido um local para Backup dos arquivos de log.  
9. Para reaproveitamento das funcionalidades, o sistema será modularizado em Bpl. Cada bpl será responsável por parte do funcionamento do sistema e deve ser consumida pelos demais módulos.
         # Será criado um módulo parameters.bpl, que será responsável por fornecer os valores parametrizados para os parâmetros.
               1 - No módulo parameters serão desenvolvidos dois métodos: GetAllParams, resposável por ler todos os parâmetros configurados que estarão no banco de dados e carregar para si. O outro método será o GetParam, que fornece o valor do parâmetros para os módulos solicitantes; ao iniciar o sistema o método GetAllParams será iniciado pelo próprio AppServer, devendo ser reutilizado apenas quando for necessário modificar parâmetros em tempo de execução e modificar imediatamente o funcionamento do sistema. Não será criada, neste momento, a opção do carregamento unitário de apenas um parâmetro. Se existir a necessidade de recarregar, o método GetAllParams deve ser utilizado.
         # Para agilizar o consumo e reuso dos métodos desenvolvidos entre os diferentes módulos bpl será criada uma unit uBlplUtil. Esta unit deve agrupar as classes necessárias à simplificar o consumo de módulos bpl por parte do programador.
               1 - Criar uma classe TBpl que deve conter os fields e métodos para manipulação das bpls.
10. Para padronizar e simplificar a leitura e envio de mensagens com o TOTVS Html Framework será criada uma unit uTotvsHtmlUtil. 
          # Criar uma classe TResponseTotvsHtml com a estrutura e métodos necessários à criação do Json de retorno do TOTVS Html Framework, conforme o modelo.
                 {["data":[], "length": 0, "msg":[]}
                1 -  Criar um field para Data = Array de dados de retorno, destinado aos valores solicitados de retorno do objeto de dados.
                2 -  Criar um field para  length = Tamanho do array de dados.
                3 -  Criar um field para Msg =  Array de dados que obedece o formato de mensagem do TOTVS Html Framework.
                4 - Criar um procedimento Execute =  Procedimento que fará o desvio para o procedimento de acordo com o tipo de sua solicitação Get =  Busca, Post = Novo registro, Put = Alteração de registro, Delete = Exclusão de registro.
                5 - Criar procedimentos abstratos - Get, Pos, Delete, Put, para o desvio das funçõies REST.
                6 - Criar método ToString =  Método que transforma um objeto instanciado da classe TResponseTotvsHtml em Json no formato de retorno para o TOTVS Html Framework.
                7 - Criar método AddMsg =  Adiciona uma nova mensagem de retorno no modelo TOTVS Html Framework.
          # Desenvolvimento Html: a prática de desenvolvimento do TOTVS Html Framework, assim como a sua tradução e boas práticas segue o manual de utilização do próprio TOTVS Html Framework. Os modelos desenvolvidos neste projeto são meramente ilustrativos e visam o consumo dos serviços da camada backend que será desenvolvida em Delphi.
11. Para permitir o reuso das storedprocedures de CRUD de tabelas existentes atualmente no SARA deve ser criado, na Classe referente a tabela, o método ExecuteProcDiu, que fará execução dos métodos hoje contidos nas procedures de CRUD.
    Tabelas Utilizadas

Tabelas Utilizadas

• param_app -  Tabela de parâmetros de configuração do Appserver.
• rotas -  Tabela de desvio de rotas da aplicação.

Fluxo do Processo

Procedimentos

Interface - Será criado um componente de acesso aos dados em formato de interface, com a intenção de separar a camada de acesso aos dados dos módulos.

• IConection - Componente de conexão a banco de dados.
• IQuery - Componente consulta e execução de procedimentos no banco de dados.

Data.bpl - Será criado um módulo de acesso ao banco de dados, sendo que este será responsável por prover os objetos de acesso aos dados do sistema, tanto ao banco de dados padrão como ao banco de log..

• Conexão - Este módulo será responsável por conectar ao banco de dados.
• Factory para criação das queries a serem utilizadas por outros módulos.

Parameters.bpl -  Será criado um módulo de parâmetros que será consumido pelos demais módulos.

• GetParam() -  Método responsável por prover o valor atual do parâmetro configurado.
• GetAllParam() - Método responsável  por carregar a lista de parâmetros atual. 

uLoadParam - As funções de consumo de parâmetros efetuas pelos módulos serão consolidadas em uma unit que deve conter uma classe TConfig, com os métodos estáticos para consumo dos parâmetros.

• GetParam(aId) - Método que devolve o valor do parâmetro configurado.

• GetParamList(): - Método que recarrega a lista de valores dos parâmetros, em caso de alteração de valores de parâmetros em tempo de execução.

Rotas.bpl - Será criado um módulo que efetue o desvio para a rota adequada à solicitação do cliente.

• Autenticidade de autorização de consumo do módulo desejado - deverá ser desenvolvido neste módulo em projeto futuro (será definida apenas a chamada ao método nesta fase do projeto), efetuando então o desvio para a rota desejada ou a negação do acesso ao recurso.

• Consumo de licença - deverá ser construído neste módulo em projeto futuro (será definido apenas a chamada ao método nesta fase do projeto), consumindo então o servidor de licenças TOTVS.

Framework  - Serão criados métodos comuns de acesso aos recursos modularizados, a fim de definir um padrão de desenvolvimento a ser seguido.

• TData -  Será criada uma classe para o consumo dos recursos disponíveis no módulo de dados.
            CreateQuery -  Será criado um método que fará o consumo do módulo data.pbl, a devolução da interface IQuery, permitindo o consumo do banco de dados.
• GetParamOrCreate -  Método padrão para inserção de parâmetros novos ao sistema, o qual efetuará o carregamento do parâmetro  ou a criação. Este será de uso exclusivo do módulo principal e após a sua criação, os parâmetros deverão ser consumidos a partir do módulo parameters.bpl.
            Os novos parâmetros deverão ser criados definindo seu nome, valor, tipo de dados e seus literais de tradução para sua descrição de uso, lista de valores de pesquisa e lista de valores selecionáveis, para que no futuro seja possível a criação de uma tela de configuração dos parâmetros que auxilie o administrador do sistema na configuração adequada ao seu cenário.

• uGlobalParam -  Será criada uma unit para acesso aos valores necessários ao funcionamento da aplicação antes do acesso aos recursos de banco de dados.

Config.ini - Será criado um arquivo de parametrização das informações necessárias ao sistema antes do acesso aos recursos de banco de dados.

• Driver de banco de dados.
• Instância do banco de dados.
• Usuário e senha de acesso ao banco.
• Linguagem padrão de tradução do sistema.

• Local dos arquivos de log de erros.

• Local dos arquivos de log para falta de arquivos de tradução.

• Local dos arquivos de log de execução.

uCriptografia - Será criada uma unit que deverá conter a assinatura dos métodos de criptografia de descriptografia de dados, com objetivo de que a utilização de sua chamada possa ser incluída nos locais adequados e, no futuro, informações de usuário e senha contidos no arquivo de configuração ou registro sejam protegidas.