Geral

O TOTVS | HTML Framework foi concebido para tratar apenas a camada de interface das aplicações; confiando que os produtos por trás da interface irão conceder a infraestrutura e a implementação mínima dos serviços para utilização do framework. Desta forma cada produto deverá prover os seguintes itens quanto a:

• Infraestrutura: Um container web independente de plataforma. Neste caso podemos considerar:
  
  
  • IIS
  • Apache
  • Tomcat
  • JBOSS
  • Glassfish
    
    
  Observação: Os servidores web citados são exemplos dos containers, sendo possível utilizar outros servidores web.
  
  Em relação a segurança de contexto da aplicação, cada aplicação deverá ser responsável pela sua implementação devido a diversidade de plataformas e diferença entre os padrões de cada produto.
  
  

• Serviços:  Cada produto deverá prover os serviços para IDE e para a aplicação a ser construida; Para correto funcionamento da IDE cada produto deverá prover o seguinte serviço:

   

  • getAvailableServices: Este serviço deverá estar disposto como REST utilizando o protocolo GET e retornar um JSON contendo um lista de serviços disponiveis. O path para acesso ao serviço deverá ser: <url do serviço rest>/getAvailableServices
    
    

    • Parâmetros:

       

      • Entrada - name: nome do serviço para ser utilizado como filtro, default é uma String em branco.

      • Entrada - start: indica quando registros já estão disponíveis em tela, default é 0.

      • Entrada - limit: indica a quantidade de registros a serem retornados a partir do indicado de inicio (start), default é 100.

      • Saida - uma lista de serviços disponíveis, está lista deve ser composta por:

         

        • id: identificador do serviço;

        • name: nome do serviço, por convenção deve ser utilizado o nome do contexto em qual o serviço se encontra;

        • description: descrição do serviço;

        • descriptor: URL contendo o descritos WADL ou WSDL do serviço em questão;

        • type: tipo de serviço: REST ou SOAP 

           
          

    Bloco de código
    firstline language java firstline 1 title Exemplo 1 linenumbers true collapse true
    // URL do Serviço: http://localhost:8380/html-service/rest/framework/getAvailableServices // Assinatura do método getAvailableServices: @GET @Path("/getAvailableServices") @Produces(MediaType.APPLICATION_JSON) public List<AvailableServices> getAvailableServices( @QueryParam("name") @DefaultValue("") String name, @QueryParam("start") @DefaultValue("0") int start, @QueryParam("limit") @DefaultValue("100") int limit) throws Exception; // Assinatura do AvailableServices: @XmlRootElement(name = "AvailableServices") @XmlAccessorType(XmlAccessType.FIELD) public class AvailableServices implements Serializable { @XmlElement(name = "id") private Long id; @XmlElement(name = "name") private String name; @XmlElement(name = "description") private String description; @XmlElement(name = "descriptor") private String descriptor; @XmlElement(name = "type") private String type = "REST"; // ou SOAP } // JSON gerado como retorno do método getAvailableServices: [{ "id":1, "name":"html-app", "description":"Serviços de gerenciamento da aplicação de referência html-app.", "descriptor":"/html-app/rest/application.wadl", "type":"REST" }, { "id":2, "name":"html-sample", "description":"Serviços da aplicação de referência html-sample.", "descriptor":"/html-sample/rest/application.wadl", "type":"REST" }]

    
    O WADL é a documentação padrão para os serviços REST assim como o WSDL está para os serviços SOAP. A especificação do WADL está disponível em: http://www.w3.org/Submission/wadl/

Compatibilidade  com Browsers

O TOTVS | HTML Framework suporta as ultimas versões de cada browser, mas especificamente a ultima e penúltima versão.

...

• Chrome
• Firefox
• Safari
• Opera (Somente para Windows e Mac OS)
• Internet Explorer
  
  

  • Para o caso do IE 8 e 9, deve ser adicionada duas bibliotecas (RespondJS e HTML5Shiv) externas para permitir o funcionamento correto dos componentes. Conforme exemplo:

    Bloco de código
    language xml firstline 1 title Exemplo firstline 1 linenumbers true collapse true
    <!DOCTYPE html> <html lang="pt-br" class="no-js"> <head> ... <!-- HTML5 shim and Respond.js IE8 support of HTML5 elements and media queries --> <!--[if lt IE 9]> <script src="js/libs/html5shiv.min.js"></script> <script src="js/libs/respond.min.js"></script> <![endif]--> </head> <body></body> </html>

Restrições 

1. A tecnologia ou plataforma escolhida para prover os serviços do produto não são tratadas pelo TOTVS | HTML Framework. Desta forma o framework se encarrega apenas dos quesitos de interface;
2. A forma como os produtos irão prover os serviços também são de responsabilidade dos produtos. Desde que o retorno dos serviços utilize a especificação REST e a estrutura de retorno seja JSON;

Aplicação

Cada produto deverá seguir um padrão especifico para utilização do framework, para cada nova aplicação deverá possuir ao menos uma aplicação centralizadora a qual irá conter os arquivos de core para utilização do TOTVS | HTML Framework.

Esta aplicação centralizadora por sua vez deverá prover as dependências padrões do TOTVS | HTML Framework (bibliotecas, componentes, estrutura, etc...) além de alguns artefatos opcionais de acordo com o padrão de arquitetura desenhado para o projeto/produto.

Aplicação Centralizadora

Este tipo de aplicação podemos considerar como sendo uma aplicação raiz, pode até ser feito uma analogia com uma aplicação de menu a qual irá direcionar para as demais aplicações e estas por sua vez irão consumir recursos do menu (aplicação centralizadora).

...

• assets: contem os arquivos de acessórios como css imagens e outros desde que seja comum a todas as aplicações e/ou necessário para aplicação centralizadora;
  
  
  • css: destinado a arquivos de css;
    
    
  • fonts: destinado a arquivos de fontes para labels;
    
    
  • img: deve conter as imagens e outros apetrechos visuais para as aplicações;
    
    
• fluig:  deve conter uma página inicial customizada para abertura das views a partir do Fluig;
  
  
• html: contem as páginas para a aplicação centralizadora;
  
  
  • templates: deverá conter os arquivos de template para os componentes do framework;
    
    
    • fields: diretório para armazenamento específicos dos templates para os componentes de formulário;
      
      
• i18n: deverá conter um arquivo único de tradução para a aplicação centralizadora.
  
  
• js: contem os arquivos JavaScript para aplicação;
  
  
  • libs: diretório para armazenamento das bibliotecas JavaScript utilizadas pelo framework e demais aplicações;
    
    
  • setup: deve conter os arquivos de customização e estruturação da arquitetura das aplicações.
    
    
  Observação: A estrutura aqui definida serve como base para os direcionamentos de URL e abertura dos telas. A alteração desta estrutura pode originar alterações dentro das funcionalidades de roteamento, internacionalização e configuração de estados da aplicação.

Aplicação Convencional

As aplicações convencionais possuem um estrutura reduzida e focada apenas nas views que devem fornecer. Para exemplificar vamos partir do principio que estamos no diretório raiz da aplicação dentro do container web, sendo assim temos a seguinte estrutura:

...

Neste caso os diretórios e subdiretórios: assets, libs, css e outros; irão existir somente caso seja necessário utilizar algum recurso que não seja provido pela aplicação centralizadora.

Arquitetura

A arquitetura pode ser resumida de acordo com a imagem a baixo:

...

• Tela.*.html: são os arquivos HTML da tela que serão mostrados no browser para representar cada state configurado anteriormente, quando a tela é mostrada para o usuario, o controller configurado no state é associado com essa tela automaticamente.

Deploy dos ERPs com o FLUIG

Image Added

A figura acima ilustra o cenário de um cliente com vários produtos e com acesso externo.

O PROXY nos ERPs permite o Cross-Domain entre as páginas HTML e os serviços REST providos pelos servidores de aplicação dos ERPs.

O PROXY REVERSO na LAN permite o Cross-Domain de páginas vindas entre os servidores HTML, do FLUIG e dos ERPs.

O PROXY REVERSO na DMZ é um requisito de segurança de infra-estrutura, quando é necessário expor o FLUIG e/ou os ERPs à Internet.

O FLUIG passa a acessar os serviços SOAP e/ou REST via o serviço de PROXY dos servidores HTML dos ERPs.

Equipes de Desenvolvimento

O TOTVS HTML Framework tem como objetivo único fornecer componentes e ferramentas de desenvolvimento de interface WEB (e Mobile), e limita-se exclusivamente à esta camada, que deve ser comum à todos os produtos da empresa.

...