Mejora del uso de licencias 4D Client con Qodly Studio for 4D

Aquellos que han comenzado a utilizar Qodly Studio for 4D ya saben lo poderosa que es esta nueva herramienta para el desarrollo de aplicaciones web profesionales. Si aún no lo ha hecho, encuentre aquí más información sobre cómo empezar.

Las aplicaciones hechas con Qodly Studio for 4D se basan en las APIs REST. 4D 20 R5 se entrega con una gran nueva funcionalidad: el modo «Force Login «.

Con el modo «Force Login», una licencia 4D Client sólo se consume cuando los usuarios se loguean exitosamente y comienzan a trabajar con los datos y la lógica de su aplicación.

Siga leyendo para saber más. ¡Y no olvide descargar nuestra demo para verlo en acción!

Demo Salir de la sesión

¿Qué es el modo de inicio de sesión forzado?

Los formularios web de Qodly no son HTML. De hecho, Qodly Studio for 4D describe su formulario como un archivo JSON, renderizado posteriormente en el navegador web del usuario final como HTML.

Para que un formulario Qodly se muestre en el navegador web del usuario final, se lanza una petición REST desde el navegador para descargar el JSON del formulario desde el servidor.

Otras acciones del usuario final en el formulario también desencadenarán peticiones REST para manejar datos y llamar funciones de las clases del modelo de datos ORDA en el servidor.

Antes de 4D 20 R5, como para cualquier otra petición REST, el servidor crea y mantiene una sesión web para alojar el almacenamiento de la sesión y los privilegios de sesión, y simultáneamente se consume una licencia 4D Client.

En consecuencia, si implementa un simple formulario de autenticación (login + password inputs) con Qodly Studio for 4D, tan pronto como su usuario final llega a este formulario, una licencia 4D Client es consumida incluso antes de que el proceso de autenticación haya comenzado.

La licencia cliente 4D consumida sólo se libera cuando la sesión web se cierra después de un tiempo de inactividad de al menos una hora (o un reinicio del servidor). Esto puede llevar a una falta de licencias cliente 4D disponibles para permitir a los usuarios trabajar con su aplicación.

Somos conscientes de que este comportamiento podría mejorarse, por eso:

Con 4D 20 R5, puede utilizar el nuevo modo «Forzar login» mientras trabaja con las APIs REST.

Este modo beneficia enormemente a Qodly Studio para aplicaciones 4D ya que mejora este proceso. Le ayuda a controlar el consumo de licencias cliente 4D, y ahora puede liberar una licencia cliente 4D cuando el usuario ha terminado de utilizar la aplicación.

En resumen

Con el modo Force Login, las licencias se consumen sólo cuando los usuarios empiezan a trabajar con los datos y la lógica que sirve su servidor REST. Esto significa:

  • Reducción del consumo de licencias: los formularios de inicio de sesión ya no consumen licencias.
  • Experiencia de usuario mejorada: los usuarios pueden intentar iniciar sesión sin que ello afecte a las licencias disponibles.
  • Mejor gestión de recursos: la licencia se libera una vez que el usuario sale de la aplicación.

 

Liberar una licencia 4D Client en cualquier momento

La sesión puede ser abandonada simplemente activando la acción estándar Logout, y una licencia 4D Client puede ser liberada.

 

Esta es una mejora significativa, así que vamos a entrar en más detalles para aprender cómo puede beneficiarse de esta característica.

Cómo activar el modo Forzar inicio de sesión

Activar el modo Forzar inicio de sesión es sencillo. Simplemente vaya a la sección Roles y Privilegios y actívelo.

blank

Esto actualiza el archivo roles.json de su proyecto en consecuencia.

{
"permisos": {
"allowed": [
]
},
"privilegios": [
],
"roles": [
],
"forceLogin": true
}

Desglose detallado del comportamiento

Una vez activado este modo

  1. Las peticiones REST descriptivas (es decir, peticiones como rest/$catalog o rest/$getWebForm para renderizar un formulario web) no consumen ninguna licencia.
  2. Otras peticiones REST( por ejemplo, peticiones que manejan datos o llaman a funciones de clases del modelo de datos ORDA) se rechazan hasta que se completa la autenticación con éxito.
  3. Debes implementar una función cuyo nombre debe ser authentify() en la clase datastore. Esta función maneja la autenticación. Esta es la única solicitud REST descriptiva aceptada sin una autenticación exitosa.

 

Una vez que la autenticación tiene éxito, todas las peticiones REST son aceptadas, y se consume una licencia de cliente 4D.

Una autenticación exitosa significa llamar a la función Session.setPrivileges().

He aquí la cronología de esto:

blank

 

Ejemplo: Aplicación vendedor

Este ejemplo presenta una aplicación que los vendedores utilizan para trabajar con los archivos de sus clientes.

El usuario final muestra un formulario web con una fuente de datos de tipo selección de entidad (clase de datos Clientes) con el valor inicial Todos.

Se recibe este error porque todavía no se ha realizado correctamente la autenticación:

blank

blank

Sin embargo, el usuario final puede renderizar este sencillo formulario web que no maneja datos ni llama a ninguna función cuando se carga. No se consume ninguna licencia de 4D Client en este momento.

 

blank

Cuando el usuario final hace clic en el botón Go, se llama a la función authentify(). Se ha implementado en la clase 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 llamada es aceptada.

Si la autenticación falla, no se llama a la función Session.setPrivileges(). Por lo tanto, no se consume ninguna licencia ni se rechaza ninguna solicitud REST descriptiva.

Si la autenticación tiene éxito, se llama a la función Session.setPrivileges(). Por lo tanto, se consume una licencia de cliente 4D, y ahora se acepta cualquier solicitud REST. Puede entonces empezar a trabajar eficientemente con sus datos.

Nota: en este ejemplo, se pasa una cadena vacía a la función Session. Use the setPrivileges() para autenticarse como invitado. Por supuesto, se pueden definir los privilegios correspondientes a la autenticación de los usuarios.

Además, puede ofrecer a sus usuarios finales una función de desconexión gracias a la acción estándar de cierre de sesión mencionada anteriormente. Se borrarán los privilegios de la sesión, y el usuario final volverá al «estado no autenticado»: sólo se aceptarán solicitudes REST descriptivas, y deberá autenticarse de nuevo para trabajar con los datos.

Conclusión

Con el modo Force Login en 4D 20 R5, puede optimizar el consumo de licencias cliente 4D en sus aplicaciones web Qodly Studio for 4D. Esto mejora la experiencia del usuario y la gestión de los recursos del servidor. ¡Háganos saber lo que piensa de esta funcionalidad en los Foros 4D!

 

Avatar
• Propietario de producto - Marie-Sophie Landrieu-Yvert ingresó al equipo de 4D Product como Propietario de producto en 2017. Como tal, está a cargo de escribir las historias de los usuarios y luego traducirlas en especificaciones funcionales. Su papel es también asegurarse de que la implementación de la funcionalidad entregada cumpla con las necesidades del cliente. Marie-Sophie se graduó en la Escuela de Ingeniería de ESIGELEC y comenzó su carrera como ingeniera en IBM en 1995. Participó en varios proyectos (de mantenimiento y creación) y trabajó como desarrolladora de Cobol. Luego trabajó como diseñadora de UML y desarrolladora de Java. Sus principales funciones fueron analizar y redactar requisitos funcionales, coordinar los equipos de negocio y de desarrollo.