O SmartClient Desktop é uma aplicação C++ monolítica (independente), enquanto o WebApp é executado a partir dos navegadores.

Os navegadores possuem características e medidas de segurança que podem trazer mudanças de comportamento ao WebApp durante o uso do ERP, este documento descreve essas características, para apoia-los durante a transição.

Um bom exemplo é o TWebEngine, no SmartClient Desktop este componente é um Chromium embutido na aplicação, enquanto no WebApp, ele é um iframe.

Onde encontro as informações consolidadas sobre o WebApp?

Neste link você terá acesso às informações de download, configuração e notas de release do WebApp:

1. Versão WebApp

Configurando o App_Environment via Porta Multiprotocolo

A configuração do App_Environment via Porta Multiprotocolo é um facilitador, criando rotas para ferramentas como o WebApp, WebMonitor, Rest e outras.

A documentação abaixo é importante para sua correta configuração:

• Seção [General] - Chave App_Environment
• Application Server - Porta Multiprotocolo
• Porta Multiprotocolo - Geração de Certificado
• Porta Multiprotocolo - Instalação de Certificado

Configurando o Broker HTTP

Em ambientes com multiplos Servidores é aconselhavel o uso do Broker HTTP, para balanceamento via WebApp.

A importância do WebAgent para a integração com a estação de trabalho

O navegador não permite que você acesse arquivos locais, ou aplicações instaladas em sua estação de trabalho, mais uma vez, por questões de segurança.

Isso implica no bloqueio de funções importantes ao ERP, como por exemplo, a FCREATE(), para criar um arquivo, ou mesmo a integração com o Excel.

O WebAgent é um serviço websocket, seguro, que permite esses acessos bloqueados pelos navegadores, mais informações no link: 2. WebApp - WebAgent

Limitações impostas pelos navegadores relativas à segurança e usabilidade

Nesta seção listaremos algumas limitações impostas pelos navegadores, e os contornos, quando possível.

Ao utilizar o TWebEngine (iframe):
Não é possível executar o método navigate para a página https://www.google.com/

A grande maioria dos sites, incluíndo o google e a TOTVS, impedem seu uso através de um iframe por questões de segurança, não existe contorno para essa questão, sendo apresentado o seguinte erro no console de seu navegador:

chromewebdata/:1  Refused to display 'https://www.google.com/' in a frame because it set 'X-Frame-Options' to 'sameorigin'.

Caso seja imprescindível para sua aplicação abrir um site com este bloqueio, pode utilizar a função ShellExecute, mais informações no link: TWebEngine:Navigate

Exemplo:

// Exemplo de uso para Windows
ShellExecute( "open", "http://www.google.com.br", "", "", 1 )
 
// Exemplo de uso para Linux
shellExecute("Browser", "/usr/bin/firefox", "http://www.google.com.br", "/", 1 ) 

Ao utilizar o TWebEngine (iframe):
Não é possível executar o método navigate para um arquivo local, exemplo: file:///dir/arquivo

Esta também é uma medida de segurança dos navegadores, como contorno, recomendamos copiar o arquivo em questão para uma pasta temporária no Servidor através da função CpyF2Web, acessando este arquivo na sequencia, mais informações no link: TWebEngine:Navigate

Exemplo:

DEFINE DIALOG oDlg TITLE "Contorno para file://" FROM 0,0 TO 800,1200 PIXEL

  // Copia o arquivo da Estacao para o Servidor, retornando seu caminho
  // Este exemplo foi escrito para Linux, ao utilizar em Windows,
  //   basta mudar o caminho para o arquivo, ex: "c:/dir/arquivo" 
  cFilePath := CpyF2Web("l:/home/mansano/totvs/file.txt", .T., .F., .F., .F.)
  
  oWebEngine := TWebEngine():New(oDlg, 0, 0, 100, 100,,)
  oWebEngine:Align := CONTROL_ALIGN_ALLCLIENT

  // Executa o Navigate para o arquivo temporario no Servidor
  oWebEngine:navigate(cFilePath)

ACTIVATE DIALOG oDlg CENTERED 

Ao utilizar o TWebEngine (iframe):
Comportamento do InactiveTimeout ao digitar/navegar em uma aplicação HTML(POUI)

O tempo de inatividade (inactive timeout) é definido pelo administrador do ERP para garantir, que caso uma conexão fique inativa por N minutos, ela seja automáticamente encerrada.

Para o WebApp avaliar se uma rotina está realmente em uso, enquanto o usuário digita/navega em uma aplicação HTML carregada em um iframe, é necessário executar um conjunto de scripts.

Porém, por questões de segurança, um navegador só permite a execução desses scripts, quando a página carregada em um iframe possuir o mesmo protocolo+host-name+porta da página principal.

Exemplo:

Se a página principal for a http://www.totvs.com:8080/index.html

Seria possível usar um iframe apontando para http://www.totvs.com:8080/app1.php

Mas seria bloqueada a execução desses scripts, no caso de utilizar a página https://www.totvs.com:8080/pag1.html, pois o protocolo foi alterado de HTTP para HTTPS.

Neste caso, esgotado o prazo do inactive timeout, mesmo que o usuário estivesse atualizando dados no iframe, sua sessão seria interrompida.

Mais informações no link: WebEngine+InactiveTimeout

🚨 O mecanismo da Porta Multiprotocolo pode ajudar, garantindo que possam publicar sub-rotinas, respeitando o mesmo protocolo+host-name+porta, mudando apenas a rota para esta sub-rotina.

Exemplo:

Neste exemplo temos dois serviços (sub-rotinas) utilizando o mesmo caminho, cada um em sua respectiva rota, o primeiro o WebApp, o segundo o WebMonitor.

Limite de conexões por browser

Os navegadores atuais de mercado possuem um limite máximo de conexões paralelas por domínio, para evitar ataques como Denial of Service.

No caso do ERP, não serão possiveis novas conexões com o Servidor de Aplicação quando este limite for atingido.

Caso esteja utilizando no Chrome, por exemplo, o SIGAMDI, o Menu Principal irá consumir uma conexão com o domínio (Servidor), desta forma, você poderá executar (no mesmo navegador), mais 5 rotinas simultâneas do ERP,  chegando neste limite, não serão permitidas aberturas de novas rotinas.

🚨 Abrir uma sessão deste mesmo navegador em modo anônimo/privado não irá permitir novas conexões, porém, poderá utilizar um segundo navegador, respeitando seu novo limite de conexões.

Mais informações no link: Limite de conexões por browser

Teclas de atalho bloqueadas pelos navegadores

Os navegadores possuem um conjunto de teclas proprietárias, impedindo seu uso através da função SetKey no WebApp.

🚨 Caso possua alguma customização que utiliza esses conjuntos de teclas, será necessário ajustar sua rotina.

Mais informações no link: SetKey no Webapp

Bloqueio de Relatórios com mais de 1.000 páginas

Os navegadores possuem um limitador de até 1.000 páginas exibidas através de seu próprio spool, para controle de consumo de recursos.

Relatórios do tipo TReport

Os relatórios do tipo TReport podem ser salvos em PDF, imprimindo este PDF na sequência, evitando esta limitação.

Relatórios do tipo SetPrint (##R) 

Os relatórios do tipo SetPrint não possuem impressão via PDF, para evitar essa limitação recomendamos:

• Gerar normalmente seu relatório, mesmo que ele possua mais de 1.000 páginas
• Após a geração, ao fazer sua impressão, via impressora física ou virtual(PDF)
• Limite o numero de páginas a serem impressas, exemplo:
  • Caso o relatório tenha 1.500 páginas
    • Imprima da página 1 à 500
    • Em seguida, imprima da 501 à 1.000, e assim por diante...

No print abaixo, retirado da tela de Spool de Impressão, temos um exemplo desta operação:

VSCode - Depuração via WebApp

Na sequencia demonstramos os passos para depuração via WebApp utilizando o TDS-VSCode, mais informações sobre depuração aqui.

1. Acesse no painel lateral esquedo a opção "Depuração".
2. Clique na engrenagem superior para acessar o arquivo launch.json.
3. Clique no botão "Adicionar Configuração"

1. Selecione a opção "TOTVS Language Debug via Web App"

1. Na tag smartclientUrl informe o ip:porta para seu servidor
2. Atente para a tag "name", onde será definido o nome para o launcher, pois será utilizado na sequencia.

1. Selecione o launcher que foi criado.

1. Acesse "Configurações".
2. No campo de pesquisa preencha: navigator
3. Selecione a aba "Usuário"
4. Informe o caminho completo para o navegador de sua preferência, para verificar os navegadores homologados acesse aqui.

1. Inicie normalmente a depuração, da mesma forma que faria utilizando o SmartClient Desktop.

1. Ponto de parada

1. Programa sendo exibido no navegador, da mesma forma que seria exibido utilizando o SmartClient Desktop.

WebApp em dispositivos móveis

O WebApp é homologado para Tablets, sem qualquer configuração adicional.

🚨 É possível também acessar o ERP a partir de um celular, porém a experiência de navegação será muito prejudicada, motivo pelo qual não é homologado.

Mais informações no link: SmartClient HTML (WebApp) - Navegadores homologados

🚨 O WebAgent não é homologado para dispositivos móveis, devido à diversas limitações de segurança impostas pelo Android/IOS.

Cadastro de Clientes sendo executado em um Galaxy S a partir do Samsung Dex

WebApp em telas sensíveis ao toque

É possível utilizar o WebApp em telas sensíveis ao toque, seja um notebook ou um tablet, mas existem algumas diferenças de comportamento para facilitar seu uso.

Mais informações no link: Telas de Toque (Touchscreen) / Mobile - Mudança de Comportamento

Como identificar corretamente a versão do Client em uso

Ao utilizar o WebApp em conjunto com o WebAgent, o retorno da função GetRemoteType() será o mesmo do SmartClient Desktop, exemplo: 1=Windows / 2=Linux/MacOS.

Caso precise confirmar se esta executando o WebApp, utilize o trecho abaixo, capturando a informação adcional por referência:

function u_remoteType()
  Local cLib
  Local cRmtType := GetRemoteType(@cLib) 
  conout("Tipo do remote: " + cValToChar(cRmtType)) // -> Ex: 1=Windows | 2=Linux/MacOS
  conout("Info adicional: " + cLib)                 // -> Exemplo ao utilizar o WebApp: "HTML-9.1.6 LINUX"
return

// Retorno
// Tipo do remote: 2
// Info adicional: HTML-9.1.6 LINUX

Mais informações no link: GetRemoteType

Passagem de parâmetros na abertura do ERP através do Navegador

O SmartClient Desktop permite a passagem de parâmetros quando executado via linha de comando, o WebApp permite a mesma ação, passando os parâmetros diretamente na URL de seu navegador, abaixo um exemplo:

http://10.173.9.215:5011?E=ambiente&P=SIGAFAT&A=param1&A=param2&A=param3

Mais informações no link: Parâmetros de Linha

Passagem de parâmetros na abertura do ERP através do WebAgent (parâmetro launch)

É possível também executar o WebAgent passando parâmetros via linha de comando, uma característica importante caso queira automatizar algum processo customizado, por exemplo.

Ao utilizar o parâmetro launch, o navegador será iniciado sem abas, passando a sensação ao usuário de estar rodando uma aplicação convencional.

Exemplo:

C:\Users\Administrator\AppData\Local\Programs\web-agent\web-agent.exe launch "http://10.173.9.215:5011?E=ambiente&P=SIGAFAT&A=param1&A=param2&A=param3" --browser="C:\Program Files\Google\Chrome\Application\chrome.exe" 

Mais informações no link: 2. WebApp - WebAgent#2.WebAppWebAgent-Launch

Execução de rotinas sem interface através do WebAgent (parâmetro launch com --headless)

Existem algumas rotinas de processamento que não necessitam de interface (tela), é possivel executar essas rotinas utilizando em conjunto os parâmetros launch e --headless.

Exemplo:

C:\Users\Administrator\AppData\Local\Programs\web-agent\web-agent.exe launch "http://10.173.9.215:5011?E=ambiente&P=u_headless" --browser="C:\Program Files\Google\Chrome\Application\chrome.exe" --headless 

Mais informações no link: 2. WebApp - WebAgent#2.WebAppWebAgent-Headless

Diferenças na aplicação de CSS (SetCSS) entre o WebApp e o SmartClient Desktop

Dadas as diferenças de tecnologia entre os dois Clients, a renderiação de estilo (CSS) também pode apresentar diferenças de comportamento.

No ERP essas diferenças são tratadas pelas Squads responsaveis pelos produtos, e caso sua empresa possua customizações que utilizam CSS, podem ser necessários pequenos ajustes caso comece a utilizar o WebApp.

Mais informações nos links:

SetCSS no WebApp

SetCSS

Arquitetura do WebApp

Uma seção do WebApp consome cerca de 300Kb a mais que o SmartClient Desktop, relativos ao motor que traduz as telas AdvPL/TLPP em conteúdo HTML.

O processamento e a manipulação de dados (CRUD), continua sendo de responsabilidade do AppServer/DBAccess, não havendo diferença no consumo de recursos, independente do Client utilizado.