Introdução
Nos posts anteriores sobre O Protheus como servidor HTTP – Parte 01 e O Protheus como servidor HTTP – Parte 02 , vimos como configurar o Protheus Application Server como servidor HTTP de páginas estáticas. Agora, vamos ver como fazer ele processar páginas dinâmicas — o AdvPL ASP. É importante ler os posts anteriores para partir para o AdvPL ASP.
AdvPL ASP
ASP, acrônimo para Active Server Pages, foi o primeiro tipo de script criado pela Microsoft para gerar conteúdo dinâmico de páginas para Internet, onde o script é processado no servidor mediante a requisição do Browser, e a página HTML é gerada no servidor ao executar o script, e retornada ao Browser. O arquivo que contém o Script é composto por conteúdo HTML, e dentro dele separadores especiais delimitam as partes de código / programa que são executadas.
O AdvPL ASP é uma forma similar ao ASP de criação de páginas dinâmicas proprietária do Protheus Server. As duas diferenças básicas são: O código delimitado para execução dentro da página é AdvPL, e uma página (ou arquivo) AdvPL ASP é compilado no repositório de objetos, sendo executado internamente como uma função AdvPL, ao invés de ser interpretado no momento em que for solicitado. Isso inclusive não “expõe”o arquivo original na pasta de publicações do HTTP. Isso mesmo, o arquivo contendo AdvPL ASP pode ficar em uma pasta não publicada na WEB, como uma pasta de fontes do Projeto.
Arquivo APH
Um arquivo contendo AdvPL ASP deve possuir a extensão “.aph“, para ele ser compilado diferenciadamente pelo IDE/TDS e pelo Application Server Protheus. Dentro dele, usamos as tags <% e %> para delimitar código AdvPL que deve ser executado, e <%= <expressão %> para qualquer expressão AdvPL que deve ser acrescentada na página final a ser retornada ao Browser.
Um arquivo chamado teste.aph, ao ser acrescentado em um projeto do AdvPL e compilado, vai virar dentro do repositório uma nova função, chamada H_TESTE() — Prefixo H_ seguido do nome do arquivo. Portanto, atenção ao dar nomes para os arquivos APH, por hora eles não devem ter mais que 8 letras no nome, devem sempre começar com uma letra alfabética, e pode conter a partir de então apenas letras e números — a mesma regra usada para nomear funções do AdvPL.
A função criada a partir da compilação do arquivo APH basicamente cria um retorno em uma variável string, declarada internamente na função, e concatena dentro tela todo o conteúdo estático e dinâmico gerado durante a chamada da função. Isto também significa que, eu posso usar um arquivo APH não apenas para HTML, mas para qualquer outra geração de string dinâmica, mas isso veremos mais para a frente. Por hora, apenas crie um arquivo index.aph no seu ambiente, com o seguinte conteúdo:
<html><body> <p>Olá Mundo AdvPL ASP</p> <p>Agora são <%=Time()%></p> </body></html>
Configuração do Protheus Server para AdvPL ASP
Legal, vamos lembrar como configuramos o nosso site estático no Protheus Server como HTTP:
[http] enable=1 port=80 path=c:\Protheus12LG\Http defaultpage=index.html
Com esta configuração — sem configurar hosts ou pastas virtuais — qualquer requisição que chegar na porta HTTP (80) do Protheus Server será atendida considerando o path raid de publicação WEB a partir da pasta C:\Protheus12LG\Http
Agora, vamos acrescentar uma chave a mais na seção http, e uma nova seção no appserver.ini, para ele ficar assim:
[http] enable=1 port=80 path=c:\Protheus12LG\Http defaultpage=index.html responsejob=webaspthreads [webaspthreads] type=webex environment=envlight instances=1,2 onstart=U_ASPInit onconnect=U_ASPConn
Muito bem, vamos por partes: webaspthreads foi o nome que eu dei para a seção de configuração de um POOL de processos AdvPL — também chamado de Working Threads — do tipo WEBEX — para processamento de AdvPL ASP — que vai atender a todas as requisições de AdvPL ASP que o HTTP Server receber. Eu poderia chamar ela de outros nomes, como poolwebjob01 ou o que lhe for conveniente, apenas não pode ser usado nenhum nome de configuração reservada ou outro que conflite com outra seção já existente no arquivo de configuração.
No meu servidor, meu environment de compilação e execução de código AdvPL chama-se “envlight“. Ao usar esta configuração no seu Protheus Server, use o nome do seu environment.
A configuração de instances indica qual é o número de processos AdvPL mínimo e máximo que serão gerenciados internamente pelo POOL de atendimento de requisições de páginas dinâmicas do AdvPL ASP. Por hora, minimo de 1 e máximo de 2 processos está ótimo.
As configurações onstart e onconnect especificadas estão apontando para duas funções que nós vamos criar, pois elas serão chamadas internamente pelo Protheus em momentos distintos, para compor o pool de processos AdvPL para atender a requisições de páginas AdvPL ASP. Pra não deixar pra depois, crie um arquivo no seu projeto de testes, chamado por exemplo AspThreads.prw, e dentro dele as seguintes funções:
#include 'protheus.ch'
User Function ASPInit()
conout("ASPINIT - Iniciando Thread Advpl ASP ["+cValToChar(ThreadID())+"]")
SET DATE BRITISH
SET CENTURY ON
Return .T.
USER Function ASPConn()
Local cReturn := ''
Local cAspPage
Local nTimer
cAspPage := HTTPHEADIN->MAIN
If !empty(cAspPage)
nTimer := seconds()
cAspPage := LOWER(cAspPage)
conout("ASPCONN - Thread Advpl ASP ["+cValToChar(ThreadID())+"] "+;
"Processando ["+cAspPage+"]")
do case
case cAspPage == 'index'
// Execura a página INDEX.APH compilada no RPO
// A String retornada deve retornar ao Browser
cReturn := H_INDEX()
otherwise
// retorna HTML para informar
// a condição de página desconhecida
cReturn := "<html><body><center><b>"+;
"Página AdvPL ASP não encontrada."+;
"</b></body></html>"
Endcase
nTimer := seconds() - nTimer
conout("ASPCONN - Thread Advpl ASP ["+cValToChar(ThreadID())+"] "+;
"Processamento realizado em "+ alltrim(str(nTimer,8,3))+ "s.")
Endif
Return cReturn
Fazendo a requisição AdvPL ASP
Uma vez tudo configurado corretamente, e os fontes index.aph e o aspthreads.prw compilados no repositório do ambiente configurado, vamos à ultima informação: Como chamar a página AdvPL ASP pelo Browser.
A extensão “.apw” foi reservada para indicar ao servidor HTTP do Protheus, que ele está recebendo uma requisição de processamento de AdvPL ASP. Logo, abra o browse no seu equipamento, e informe a URL http://localhost/index.apw — se tudo deu certo, você deve ver esta mensagem no seu Browser.
E, no log de console do Protheus Server, você deve ver as seguintes mensagens:
ASPINIT - Iniciando Thread Advpl ASP [1560] ASPCONN - Thread Advpl ASP [1560] Processando [index] ASPCONN - Thread Advpl ASP [1560] Processamento realizado em 0.002s.
Resumo para fixação
APH = Extensão de arquivo AdvPL ASP, que ao ser compilado e acrescentado ao projeto, gera no repositório de objetos do ambiente uma função, chamada H_<nomedoarquivo>, para ser usada para compor páginas de HTML dinâmico. O arquivo APH não deve ser colocado dentro da pasta raiz de publicações WEB — como ele é compilado, ele é um arquivo que faz parte de um Projeto AdvPL. Seu conteúdo será gerado mediante requisição de processamento de página dinâmica.
APW = Extensão de LINK para ser usado no Browser, para pedir ao servidor Protheus HTTP uma solicitação de uma página dinâmica. Uma solicitação através desse link será redirecionada a um POOL de threads pré-configurado dentro do Protheus Server, chamando a função configurada no parâmetro ONCONNECT do POOL.
Working Threads do tipo WEBEX = Pool de threads de trabalho, criado para atender a requisições de links de páginas dinâmicas AdvPL ASP (url com terminação .apw) , onde uma ou mais threads AdvPL são colocados em execução, inicializados com a função especificada na configuração ONSTART, que ficam em modo de espera para atender uma requisição. Quando um processo é alocado para atender uma requisição, a função ONCONNECT é chamada, usando o contexto do processo já existente, que permanece alocado (ocupado) até o final do processamento, quando o HTTP Server retorna a string gerada ao Browser, e o processo usado torna-se disponivel novamente para atender outra requisição de extensão APW, que pode vir do mesmo ou de qualquer outro Web Browser.
Inteligência do Pool de Threads
Lembra-se do parâmetro INSTANCES, configurado no Pool de Threads? Então, no nosso exemplo usamos 1,2. Isto significa que, este pool de processos inicia com somente um processo para atender as requisições de links APW. Se, em um determinado momento, todos os processos estiverem ocupados em atendimento, e chegar uma nova requisição de AdvPL ASP, o Protheus Server vai colocar essa requisição em uma fila com timeout de alguns segundos, e caso o número de processos total do pool ainda não tenha atingido o máximo, ele sobe mais um processo.
Isso garante por exemplo, que somente quando o site começar a receber forte concorrência de requisições, e os processos em execução estiverem todos ocupados, mais processos serão colocados no ar, visando economia de recursos. Isso também permite definir um limite máximo de processos, para evitar que uma avalanche de requisições ou algum processo muito demorado faça com que o Protheus Server suba mais processos do que ele aguentaria dar conta — normalmente por causa de excesso de memória consumida ou mesmo de CPU.
Detalhes adicionais
Quer ver algumas coisas interessantes? Crie uma user function — vide modelo abaixo — e vamos ver o que ela vai fazer.
User Function TstAPH() Local cRet := '' cRet := H_IndeX() conout(cRet) return
Agora execute ela diretamente pelo SmartClient, e veja o resultado no log de console do Application Server. Deve ser mostrado algo assim:
[INFO ][SERVER] [11/11/2018 23:55:19] Starting Program U_TSTAPH Thread 5516 (siga0,NOTE-JULIOW-SSD) <html><body> <p>Olß Mundo AdvPL ASP</p> <p>Agora sπo 23:55:20</p> </body></html> [INFO ][SERVER] [Thread 5516] [11/11/2018 23:55:20] Thread finished (siga0, NOTE-JULIOW-SSD, 2.63 MB.)
Na prática, eu obtive a string da página de retorno, executando meu código pelo SmartClient. Isso somente foi possível pois dentro do arquivo index.aph eu não usei nada específico do ADVPL ASP. A infraestrutura de processo oferecida pelo Protheus Server para a execução de links APW usando Working Threads oferece o uso de alias virtuais especiais para recuperar informações vindas como parâmetro de GET e POST do Browser, além de um controle nativo de variáveis de SESSION (por usuário) e COOKIES do Browser. Estes recursos estão detalhados na TDN, vide links nas referências no final deste post.
O diferencial da documentação do TDN é que as configurações das funções que fazem o ONSTART e o ONCONNECT do Pool de Threads indica que você deve usar as funções de LIB e Framework WEB compiladas no repositório do ERP, para usar alguns pseudo-comandos, como WEB EXTENDED INIT … WEB EXTENDED END e outros recursos de encapsulamento. No caso do nosso exemplo, estamos usando funções específicas e customizadas para atender uma necessidade didática. De qualquer modo, os recursos de ALIAS VIRTUAIS documentados nesta seção são oferecidos pelo Protheus Server, não dependem da LIB.
Conclusão
Com isso, começamos uma jornada no mundo do AdvPL ASP, e abrimos portas para criar muitas coisas legais. A titulo de informação, os Web Services Server do ERP Microsiga foram todos implementados em AdvPL, usando como base o POOL de Working Threads do AdvPL ASP, apenas implementando tratamentos específicos para receber um XML SOAP via POST, e retornar um XML de retorno ao invés de retornar um HTML. Os portais do ERP Microsiga foram implementados em duas camadas, uma sobre o AdvPL ASP e outra sobre Web Services. O portal em si é uma aplicação AdvPL ASP responsável por montar a interface dinâmica em HTML, consumindo um grupo de serviços publicados em um Web Services Server. Desse modo as Working Threads do portal são muito leves, pois não tem conexão persistente com Banco de Dados e não mantém tabelas abertas. Ela apenas consome um Web Service hospedado em outro serviço, e usa os retornos para montar os HTMLs dinâmicos para os usuários interagirem com as funcionalidades.
Agradeço novamente as curtidas, compartilhamentos, comentários, dúvidas e afins, e desejo novamente a todos TERABYTES de sucesso !!!
Referências
