Melhoria da utilização de licenças de cliente 4D com o Qodly Studio for 4D

Aqueles que começaram a usar Qodly Studio for 4D já sabem o quão poderosa é esta nova ferramenta para desenvolver aplicações web de negócios. Se ainda não o fez, encontre aqui mais informações sobre como começar.

As aplicações feitas com Qodly Studio for 4D dependem das APIs REST. 4D 20 R5 é lançado com uma nova e ótima funcionalidade: Modo “Force Login”.

Com o modo Force Login, uma licença de Cliente 4D só é consumida quando os usuários fizerem login com sucesso e começarem a trabalhar com os dados e a lógica de sua aplicação.

Continue lendo para saber mais! E não se esqueça de baixar nosso demo para ver isso em ação!

Demo Sair da sessão

O que é o Modo Forçar Login?

Os formulários web da Qodly não são HTML. De facto, Qodly Studio for 4D descreve o seu formulário como um arquivo JSON, mais tarde renderizado no navegador web do utilizador final como HTML.

Para que um formulário Qodly seja apresentado no navegador web do utilizador final, é desencadeado um pedido REST a partir do navegador para descarregar o JSON do formulário a partir do servidor.

Outras ações do usuário final no formulário também acionam pedidos REST para lidar com dados e chamar funções das classes do modelo de dados ORDA no servidor.

Antes do 4D 20 R5, como para qualquer outro pedido REST, o servidor cria e mantém uma sessão web para hospedar o armazenamento e privilégios da sessão, e uma licença 4D Client é consumida simultaneamente.

Consequentemente, se implementar um formulário de autenticação simples (entradas de login + senha) com Qodly Studio para 4D, assim que seu usuário final chegar a esse formulário, uma licença 4D Client é consumida antes mesmo do processo de autenticação começar.

A licença de cliente 4D consumida só é liberada quando a sessão web for fechada depois de um tempo de inatividade de pelo menos uma hora (ou uma reinicialização do servidor). Isso pode levar a uma falta de licenças de cliente 4D disponíveis para permitir que os usuários trabalhem com sua aplicação.

Estamos cientes de que esse comportamento pode ser melhorado, por isso:

Com 4D 20 R5, pode usar o novo modo “Force login” enquanto trabalha com as APIs REST.

Esse modo beneficia muito Qodly Studio para aplicações 4D já que melhora esse processo. Ajuda a controlar o consumo de licenças de cliente 4D, e agora pode libertar uma licença de cliente 4D quando o usuário termina de usar a aplicação.

Para resumir

Com o modo Force Login, as licenças são consumidas apenas quando os usuários começam a trabalhar com os dados e lógica que seu servidor REST serve. Isso significa:

• Redução do consumo de licenças: Os formulários de logon não consomem mais licenças.
• Experiência do usuário aprimorada: Os usuários podem tentar fazer logon sem afetar as licenças disponíveis.
• Melhor gerenciamento de recursos: A licença é libertada assim que um utilizador sai da aplicação.

 

Libere uma licença 4D Client a qualquer momento

A sessão pode ser encerrada simplesmente ativando a ação padrão Logout, e uma licença 4D Client pode ser liberada.

 

Essa é uma melhoria significativa, então vamos mergulhar em mais detalhes para aprender como pode se beneficiar dessa funcionalidade.

Como ativar o modo Force Login

Ativar o modo Force Login é simples. Basta navegar até a seção Roles and Privileges e ativá-lo.

Isso atualiza o arquivo roles.json do seu projeto de acordo.

{
"permissões": {
"allowed": [
]
},
"privileges": [
],
"roles": [
],
"forceLogin": true
}

Análise detalhada do comportamento

Quando este modo é ativado:

1. Solicitações REST descritivas(ou seja, solicitações como rest/$catalog ou rest/$getWebForm para renderizar um formulário da Web) não consomem nenhuma licença.
2. Outros pedidos REST(por exemplo, pedidos que tratam dados ou chamam funções de classes do modelo de dados ORDA) são rejeitados até que a autenticação seja concluída com êxito.
3. É necessário implementar uma função cujo nome deve ser authentify() na classe do armazenamento de dados. Esta função trata da autenticação. Este é o único pedido REST descritivo aceite sem uma autenticação bem sucedida.

 

Uma vez que a autenticação é bem sucedida, todos os pedidos REST são aceitos, e uma licença de cliente 4D é consumida.

Uma autenticação bem sucedida significa chamar a função Session.setPrivileges().

Aqui está a linha do tempo disso:

 

Exemplo: Aplicação de vendedor

Este exemplo apresenta uma aplicação que os vendedores utilizam para trabalhar com os ficheiros dos seus clientes.

O utilizador final processa um formulário Web com um datasource do tipo seleção de entidade (classe de dados Customers) com o valor inicial All.

Este erro é recebido porque ainda não foi efetuada uma autenticação bem sucedida:

No entanto, o utilizador final pode renderizar este formulário web simples que não manipula dados ou chama qualquer função quando carregado. Nenhuma licença 4D Client é consumida neste momento.

 

Quando o usuário final clica no botão Go, a função authentify() é chamada. Ela foi implementada na classe datastore.

exposed Function authentify($credentials : Object) : Text
	
var $salesPersons : cs.SalesPersonsSelection
var $sp : cs.SalesPersonsEntity
	
$salesPersons:=ds.SalesPersons.query("identifier = :1"; $credentials.identifier)
$sp:=$salesPersons.first()
	
If ($sp#Null)
	If (Verify password hash($credentials.password; $sp.password))
		Session.clearPrivileges()
		Session.setPrivileges("")
		return "Authentication successful"
	Else 
		return "Wrong password"
	End if 
Else 
	return "Wrong user"
End if 

Esta chamada é aceita.

Se a autenticação falhar, a função Session.setPrivileges() não é chamada. Assim, nenhuma licença é consumida + nenhum pedido REST descritivo permanece rejeitado.

Se a autenticação for bem sucedida, a função Session.setPrivileges() é chamada. Assim, uma licença de cliente 4D é consumida, e qualquer pedido REST é agora aceite. Pode então começar a trabalhar eficientemente com seus dados.

Nota: Nesse exemplo, uma string vazia é passada para a função Session. Use the setPrivileges() para autenticar como um convidado. Naturalmente, os privilégios correspondentes à autenticação dos utilizadores podem ser definidos.

Além disso, pode oferecer aos seus utilizadores finais uma funcionalidade de desconexão graças à ação padrão de terminar sessão mencionada acima. A sessão será destituída dos seus privilégios e o utilizador final voltará ao “estado não autenticado”: só são aceites pedidos REST descritivos e o utilizador tem de se autenticar novamente para trabalhar com os dados.

Conclusão

Com o modo Force Login em 4D 20 R5, pode otimizar o consumo de licenças de cliente 4D em seu Qodly Studio para aplicações web 4D. Isso melhora a experiência do usuário e a gestão de recursos do servidor. Deixe-nos saber o que pensa sobre essa caraterística nos Fóruns 4D!