Olvídate de los envoltorios del lado del servidor; utiliza 4D Sessions desde el cliente

abril 30, 2026 4 tiempo de lectura

Mejora la experiencia de tus usuarios finales en aplicaciones cliente-servidor aprovechando las sesiones 4D. Las sesiones 4D, que se crean de forma nativa y automática en cuanto un usuario abre su aplicación de escritorio, ofrecen numerosas ventajas.

¿Cuál es la principal? El acceso a los datos se puede restringir fácilmente en función del usuario actual.

No hay que configurar nada para empezar a trabajar con sesiones 4D y no hay ningún coste adicional de licencia. Con 4D 21 R3, se ha mejorado aún más el uso de las sesiones 4D en modo cliente-servidor.

¡Sigue leyendo para descubrir estas mejoras!

HDI_Session_4DClient

Sesiones de usuario remoto

Cuando un cliente 4D se conecta a una aplicación desplegada en un servidor 4D, se crea una sesión de usuario remoto en el servidor. Las sesiones son ideales para almacenar en memoria información contextual o específica del usuario, como nombres, empresas o el progreso actual de un usuario en un flujo de trabajo.

En el servidor coexisten múltiples sesiones: cada usuario tiene su propia sesión dedicada.

Además, 4D 21 introduce un conjunto completo de eventos ORDA. Estos eventos siempre se activan en el servidor. Cuando un evento necesita acceder al contexto del usuario, la sesión 4D es la solución perfecta, especialmente para restringir el acceso a los datos en función del usuario actual.

Novedades del comando Session

En su código, al llamar al comando ` Session ` se devuelve la información de la sesión del usuario remoto como un objeto.

Antes de 4D 21 R3, esto tenía que hacerse en el lado del servidor (dentro de un método de proyecto dedicado o una función de clase ORDA) porque llamar al comando Session en el cliente 4D devolvía Null.

Con 4D 21 R3, el comando Session ahora también se puede llamar directamente desde el cliente 4D.

Esto mejora tanto la organización como la legibilidad del código. Durante el desarrollo, ya no tendrá que preocuparse por cuestiones como «¿Dónde se ejecutará mi código?».

Ejemplo

Código que se ejecuta en el cliente 4D:

var $session : 4D.Session

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

$session:=Session

Este es el 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"
	}
}

La info propiedad es específica del equipo del usuario.

el objeto compartido de almacenamiento

Dado que no es necesario prever que el comando Session devuelva un valor nulo, esto simplifica la programación en la mayoría de los casos, ya que ya no es necesario escribir una rutina específica del lado del servidor.

La única excepción esel objeto de almacenamiento compartido.

Al llamar al comando Session desde el cliente 4D se proporciona un storage que es local para el cliente 4D. No es la misma referencia que el objeto de almacenamiento compartido de la sesión del usuario remoto en el servidor 4D.

Si necesita almacenar información de sesión que solo es relevante para rutinas del lado del servidor (como restringir el acceso a los datos en función del usuario actual ), seguirá necesitando ejecutar este código en el servidor para dirigirse al objeto compartido Session.storage adecuado.

Empiece a utilizar las sesiones de 4D hoy mismo para centralizar fácilmente en memoria la información contextual o específica del usuario y aprovechar al máximo las ventajas descritas anteriormente.

Discuss