Dimenticate i wrapper lato server, utilizzate le sessioni 4D dal lato client

Aprile 30, 2026 3 Tempo di lettura

Migliorate l’esperienza dei vostri utenti finali nelle applicazioni client-server sfruttando le sessioni 4D. Native e create automaticamente non appena un utente apre la propria applicazione client desktop, le sessioni 4D offrono numerosi vantaggi.

Il principale? L’accesso ai dati può essere facilmente limitato in base all’utente corrente.

Non c’è nulla da configurare per iniziare a lavorare con le sessioni 4D e non ci sono costi di licenza aggiuntivi. Con 4D 21 R3, l’uso delle sessioni 4D in modalità client-server è stato ulteriormente migliorato.

Continua a leggere per scoprire questi miglioramenti!

HDI_Session_4DClient

Sessioni utente remote

Quando un client 4D si connette a un’applicazione distribuita su un 4D Server, sul server viene creata una sessione utente remota . Le sessioni sono ideali per memorizzare in memoria informazioni contestuali o specifiche dell’utente, come nomi, aziende o lo stato di avanzamento corrente di un utente in un flusso di lavoro.

Sul server coesistono più sessioni: ogni utente ha la propria sessione dedicata.

Inoltre, 4D 21 introduce una serie completa di eventi ORDA. Questi eventi vengono sempre attivati sul server. Quando un evento necessita di accedere al contesto dell’utente, la sessione 4D è la soluzione perfetta, specialmente per limitare l’accesso ai dati in base all’utente corrente.

Novità del comando Session

Nel codice, la chiamata al comando Session restituisce le informazioni sulla sessione utente remota come oggetto.

Prima di 4D 21 R3, questa operazione doveva essere eseguita sul lato server (all’interno di un metodo di progetto dedicato o di una funzione di classe ORDA) poiché la chiamata al comando Session sul client 4D restituiva Null.

Con 4D 21 R3, il comando Session può ora essere chiamato direttamente anche dal client 4D.

Ciò migliora sia l’organizzazione del codice che la leggibilità. Durante lo sviluppo, non dovrete più preoccuparvi di domande del tipo “Dove verrà eseguito il mio codice?”.

Esempio

Codice in esecuzione sul client 4D:

var $session : 4D.Session

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

$session:=Session

Questo è l’oggetto $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"
	}
}

La info è specifica del computer dell’utente.

L’oggetto condiviso di archiviazione

Poiché non è necessario prevedere un valore Null restituito dal comando Session, ciò semplifica la codifica nella maggior parte dei casi, in quanto non è più necessario scrivere una routine specifica lato server.

L’unica eccezione èl’oggetto di memoria condivisa.

La chiamata al comando Session dal client 4D fornisce un storage locale al client 4D. Non si tratta dello stesso riferimento dell’oggetto di memoria condivisa della sessione utente remota sul server 4D.

Se è necessario memorizzare informazioni di sessione rilevanti solo per le routine lato server (come la limitazione dell’accesso ai dati in base all’utente corrente ), è comunque necessario eseguire questo codice sul server per indirizzare l’Session appropriato .storage oggetto condiviso.

Iniziate oggi stesso a utilizzare le sessioni 4D per centralizzare facilmente in memoria le informazioni contestuali o specifiche dell’utente e sfruttare appieno i vantaggi sopra descritti.

Discuss