Esqueça os wrappers do lado do servidor, utilize as 4D Sessions a partir do cliente

Abril 30, 2026 4 Tempo de leitura

Melhore a experiência dos seus utilizadores finais em aplicações cliente-servidor tirando partido das sessões 4D. Criadas de forma nativa e automática assim que um utilizador abre a sua aplicação cliente para ambiente de trabalho, as sessões 4D oferecem inúmeras vantagens.

O principal? O acesso aos dados pode ser facilmente restringido com base no utilizador atual.

Não é necessário configurar nada para começar a trabalhar com as sessões 4D e não há custos adicionais de licenciamento. Com o 4D 21 R3, a utilização das sessões 4D no modo cliente-servidor foi ainda mais melhorada.

Continue a ler para descobrir estas melhorias!

HDI_Session_4DClient

Sessões de utilizador remoto

Quando um cliente 4D se liga a uma aplicação implementada num 4D Server, é criada uma sessão de utilizador remoto no servidor. As sessões são ideais para armazenar na memória informações contextuais ou específicas do utilizador, tais como nomes, empresas ou o progresso atual de um utilizador num fluxo de trabalho.

Várias sessões coexistem no servidor: cada utilizador tem a sua própria sessão dedicada.

Além disso, o 4D 21 introduz um conjunto completo de eventos ORDA. Estes eventos são sempre acionados no servidor. Quando um evento necessita de acesso ao contexto do utilizador, a sessão 4D é a solução perfeita, especialmente para restringir o acesso aos dados com base no utilizador atual.

Novidades do comando Session

No seu código, chamar o comando ` Session ` devolve as informações da sessão do utilizador remoto como um objeto.

Antes do 4D 21 R3, isto tinha de ser feito no lado do servidor (dentro de um método de projeto dedicado ou de uma função de classe ORDA), porque a chamada do comando Session no cliente 4D devolvia Null.

Com o 4D 21 R3, o comando Session pode agora também ser chamado diretamente a partir do cliente 4D.

Isto melhora tanto a organização como a legibilidade do código. Durante o desenvolvimento, já não precisa de se preocupar com questões como «Onde é que o meu código vai ser executado?».

Exemplo

Código a ser executado no cliente 4D:

var $session : 4D.Session

ASSERT(Application type()=4D Remote mode)

$session:=Session

Este é o objeto ` $session `:

{
	"storage": {},
	"userName": "Designer",
	"id": "607BC064662C4563B3521E162E8DFB5A",
	"info": {
		"ID": "607BC064662C4563B3521E162E8DFB5A",
		"creationDateTime": "2026-03-12T09:50:45Z",
		"userName": "Designer",
		"state": "active",
		"type": "remote",
		"IPAddress": "localhost",
		"systemUserName": "Marie-Sophie",
		"hostType": "mac",
		"machineName": "Mac mini 1743",
		"persistentID": "97212B60A6294A24AC3BF829E2040888"
	}
}

A info propriedade é específica da máquina do utilizador.

o objeto partilhado de armazenamento

Como não é necessário antecipar um valor nulo devolvido pelo comando Session, isto simplifica a codificação na maioria dos casos, uma vez que já não é necessário escrever uma rotina específica do lado do servidor.

A única exceção éo objeto de armazenamento partilhado.

A chamada do comando Session a partir do cliente 4D fornece um storage que é local ao cliente 4D. Não é a mesma referência que o objeto de armazenamento partilhado da sessão do utilizador remoto no servidor 4D.

Se precisar de armazenar informações de sessão que sejam relevantes apenas para rotinas do lado do servidor (como restringir o acesso aos dados com base no utilizador atual ), ainda precisa de executar este código no servidor para direcionar o objeto partilhado Session.storage.

Comece a utilizar as sessões 4D hoje mesmo para centralizar facilmente informações contextuais ou específicas do utilizador na memória e tirar o máximo partido das vantagens descritas acima.

Discuss