Protheus e AdvPL ASP – Parte 03

Introdução

No post anterior, Protheus e AdvPL ASP – Parte 02, vimos dois alias virtuais, usados para receber parâmetros do Browse, a partir de requisições GET e POST — são eles o alias virtual HTTPGET e HTTPPOST, respectivamente. Agora vamos os demais alias virtuais disponíveis no AdvPL, começando pelo HTTPSESSION.

Alias virtual HTTPSESSION

É possível criar dinamicamente variáveis em um container global do AdvPL ASP, cujo escopo seja a instância do navegador ou Web Browse utilizado — ou em outras palavras,  “sessions de usuário”. Para isso, usamos o alias virtual HTTPSESSION.

O armazenamento no alias virtual HTTPSESSION é feito dinamicamente, na forma de tuplas chave=valor, onde damos o nome a um campo virtual, e atribuímos a ele uma informação. Por exemplo:

HTTPSESSION->USERNAME := "José"

Para consultarmos se um determinado campo virtual existe e/ou têm conteúdo, fazemos referência a ele usando da mesma forma o alias virtual HTTPSESSION, vide exemplo:

IF Empty(HTTPSESSION->USERNAME)
  conout("Session USERNAME vazia ou inexistente")
Else
  conout("Session USERNAME = " + cValToChaR(HTTPSESSION->USERNAME) )
Endif

Como o AdvPL ASP identifica o usuário?

Uma vez que um usuário abra um navegador, e solicite ao Protheus Server uma página qualquer com link .apw, que fará um processamento de AdvPL ASP, um Cookie de Memória (recurso do Web Browse para armazenar uma tupla chave=valor durante a navegação) é usado para identificar a seção (usuário) atual.

Quando você acabou de abrir o Browse, e fez a primeira requisição de link .apw para o AdvPL ASP, o Protheus Server não vai receber este identificador, então ele cria um identificador novo para a seção atual — aquela instância de Web Browse acessando o site — e retorna este identificador ao Web Browse como um “Cookie de Memória”. O Web Browse, por sua vez, a partir deste momento, e enquanto ele estiver aberto, envia de volta esse identificador como uma informação no cabeçalho HTTP de cada requisição GET ou POST que ele fizer para o Protheus Server.

Escopo e Tempo de Vida das Sessions

Uma vez que você atribua um conteúdo para uma variável de session, este conteúdo é gravado na memória da instância atual do Protheus Server, e somente será possível recuperá-lo através de um código AdvPL executado dentro de uma Working Thread do AdvPL ASP, que foi feita a partir da mesma instância de Web Browser, que fez a gravação da informação e respectivo identificador.

Todas as informações (identificadores e conteúdos) gravados para um determinado e distinto usuário, permanecerão na memória do servidor por tempo indeterminado, desde que este usuário não deixe de fazer uma requisição ao Protheus Server em até 10 minutos. Após 10 minutos sem atividade em um conjunto de dados de HTTPSESSION atrelado a um usuário, os identificadores e conteúdos serão descartados — apagados da memória. Isto não muda o identificador interno da seção daquele usuário.

Este tempo de 10 minutos — ou 600 segundos — é o valor DEFAULT da configuração SESSIONTIMEOUT, que permite definir o tempo de permanência máximo por inatividade do conjunto de variáveis de session por usuário — vide links de referência no final do post.

Onde eu uso variáveis de SESSION?

O uso mais comum são propriedades e parâmetros exclusivos que a aplicação permite definir para um ou mais usuários distintos que estão navegando no Web Site ou Aplicação WEB em questão. Por exemplo, um uso muito comum é a identificação de acesso de usuário, ou Login”.

Imagine que várias páginas dinâmicas da aplicação escrita em AdvPL ASP pode ser acessada por qualquer pessoa — acesso público e irrestrito. Porém, determinadas operações feitas através de determinados programas deste Web Site possuem acesso restrito, onde o usuário que estiver navegando deve fornecer algum tipo de informação para identificar-se na aplicação, e tentar garantir que ele “é quem diz ser”.

Nas páginas ou funções onde esta autenticação ou Login é necessária, podemos verificar se uma determinada SESSION — por exemplo HTTPSESSION->LOGIN possui conteúdo. Esta SESSION somente será criada se o usuário passar pelo processo de Login da Aplicação Web, normalmente usando uma página exclusiva na aplicação para esta finalidade. E, em cada função ou página que requer identificação ou é de acesso restrito, caso a SESSION de LOGIN não esteja definida, podemos lhe informar uma mensagem de “Acesso restrito a usuários inscritos”, e direcioná-lo a uma tela de cadastro ou a uma tela de Login.

O Que eu posso guardar em SESSION ?

Nobre desenvolvedor, você armazenar em campos do alias virtual HTTPSESSION qualquer valor básico do AdvPL, EXCETO “B” (Blocos de Código ou Code-Blocks) e “O” (Objetos ou Instâncias de Classe). O resto, inclusive Array, pode.

Agora, preste a atenção no seguinte: Um usuário ou internauta navegando no seu Web Site em AdvPL ASP, pode simplesmente parar de navegar por qualquer razão. E, durante a navegação, cada requisição de URL vinda do Web Browse é atendida por uma conexão estabelecida entre o Web Browse e o Protheus Server, que é encerrada após o processamento e envio dos dados ao Browse. Trata-se de uma conexão não-persistente.

Logo, se você coloca um botão ou link de “LOGOFF” no seu site, e o usuário realmente clica neste botão, você pode disparar uma função dentro do AdvPL para limpar manualmente todas as variáveis de SESSION deste usuário (HTTPFreeSession). Porém, se o usuário não clicar neste botão e simplesmente fechar o Web Browse, toda a memória consumida por aquele usuário, atrelada a um identificador exclusivo da seção que ele estava navegando, ficarão na memória do Protheus Server até que passe os dez minutos de INACTIVETIMEOUT, ou o tempo de inatividade configurado.

Se você, para um determinado usuário, usou 1 MB de memória para armazenar informações de SESSION, esta memória será ocupada por até 10 minutos a mais do que o usuário está realmente usando no Web Site. Ao aumentar o INACTIVETIMEOUT para valores maiores, aumentamos o tempo de retenção dessa memória. Aproveitando este exemplo, de 1 MB de consumo por usuário, e INACTIVETIMEOUT de 30 minutos. Das 12:00 às 12:10, 500 usuários navegaram no site, dos quais 100 entraram na área restrita e usaram SESSIONs. Em 10 minutos, 100 MB de uso de memória. Entre 12:10 e 12:20, entraram mais 50 usuários na área restrita, e 50 usuários que entraram às 12:00 fecharam o browse e foram almoçar. Logo, eu tenho agora (12:20) 100 usuários acessando a área restrita, mas estou mantendo na memória um total de 150 sessions, de todos os usuários que entraram desde às 12:00. Das 12:20 até 12:30 saíram e entraram mais 50 usuários, às 12:30 eu tenho o mesmo volume de 100 usuários online acessando páginas restritas, mas estou usando 200 MB para armazenar 200 variáveis de SESSION, 100 dos usuários ativos no momento, e as outras 100 que foram criadas desde o meio dia por usuários que já saíram do site.

Boas práticas de Sessions

Só existe uma boa prática de sessions: Evite usar sessions para guardar valores para qualquer pessoa navegando na aplicação WEB ou Web Site. Procure usar somente para guardar o que realmente é imprescindível, apenas para os usuários que precisam disso, como por exemplo uma informação de login ou alguma preferência diferenciada entre usuários.

Se você pretende criar uma aplicação WEB em AdvPL ASP, algo cujo tamanho e quantidade de acessos simultâneos não seja suportado por apenas uma instância única do Protheus como servidor WEB, então monte sua aplicação para não usar variáveis de SESSION, ou na verdade até pode usar, mas prefira utilizar uma abordagem que possibilite por exemplo a execução de requisições não exija “afinidade” — aplicações STATELESS por exemplo. Dessa forma, não importa em qual servidor a sua requisição seja processada, você consegue verificar a sua validade sem depender de um contexto. Se você usa variáveis de SESSION e resolve subir mais de uma instância de Protheus Server, usando um proxy reverso ou NLB (Network Load Balance), e uma requisição cria uma variável de SESSION quando foi processada no Servidor 1, caso a próxima requisição vá consultar a existência dessa variável seja direcionada para o Servidor 2, este servidor não conhece as sessions do Servidor 1, e vai tratar a requisição como se a Session realmente não existisse.

Conclusão

Embora este tópico não tenha visualmente um exemplo palpável, ele é necessário para a implementação em AdvPL ASP de outro tópico em desenvolvimento, sobre o CRUD em ADVPL ASP, onde vamos criar e usar uma SESSION para controle de login de usuário.

Por hora, apenas agradeço a todos(as) pela audiência e desejo a todos(as) TERABYTES DE SUCESSO 😀

Referências

3 comentários sobre “Protheus e AdvPL ASP – Parte 03

  1. […] Aqui fazemos uso de uma variável de SESSION que o programa mesmo vai criar, para exigir que apenas um usuário autenticado — que passou primeiro pela página de LOGIN — tenha acesso à agenda. Para maiores detalhes sobre o funcionamento das SESSIONS no AdvPL ASP, consulte o post Protheus e AdvPL ASP – Parte 03. […]

    Curtir

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s