Miglioramento dell’utilizzo delle licenze client 4D con Qodly Studio for 4D

Tradotto automaticamente da Deepl

Chi ha iniziato a usare Qodly Studio for 4D sa già quanto sia potente questo nuovo strumento per sviluppare applicazioni web aziendali. Se non l’avete ancora fatto, trovate qui maggiori informazioni su come iniziare.

Le applicazioni realizzate con Qodly Studio for 4D si basano sulle API REST. 4D 20 R5 viene fornito con una nuova grande funzionalità: La modalità “Force Login”.

Con la modalità Force Login, la licenza del client 4D viene consumata solo quando gli utenti effettuano il login e iniziano a lavorare con i dati e la logica dell’applicazione.

Continuate a leggere per saperne di più! E non dimenticate di scaricare la nostra demo per vederla in azione!

Demo Uscita dalla sessione

Che cos’è la modalità di accesso forzato?

I moduli web di Qodly non sono HTML. In effetti, Qodly Studio for 4D descrive il vostro modulo come un file JSON, successivamente reso nel browser web dell’utente finale come HTML.

Affinché un modulo Qodly venga reso nel browser web dell’utente finale, viene attivata una richiesta REST dal browser per scaricare il JSON del modulo dal server.

Ulteriori azioni dell’utente finale sul modulo attiveranno anche richieste REST per gestire i dati e richiamare le funzioni delle classi del modello di dati ORDA sul server.

Prima di 4D 20 R5, come per qualsiasi altra richiesta REST, il server crea e mantiene una sessione web per ospitare la memorizzazione della sessione e i privilegi della sessione, e contemporaneamente viene consumata una licenza del client 4D.

Di conseguenza, se si implementa un semplice modulo di autenticazione (login + password) con Qodly Studio for 4D, non appena l’utente finale raggiunge questo modulo, viene consumata una licenza 4D Client prima ancora che il processo di autenticazione sia iniziato.

La licenza client 4D consumata viene rilasciata solo quando la sessione web viene chiusa dopo un timeout di inattività di almeno un’ora (o un riavvio del server). Questo può portare a una mancanza di licenze client 4D disponibili per consentire agli utenti di lavorare con la vostra applicazione.

Siamo consapevoli che questo comportamento potrebbe essere migliorato, ecco perché:

Con 4D 20 R5, è possibile utilizzare la nuova modalità “Force login” quando si lavora con le API REST.

Questa modalità è molto utile a Qodly Studio per le applicazioni 4D perché migliora questo processo. Aiuta a controllare il consumo delle licenze client 4D e ora è possibile liberare una licenza client 4D quando l’utente ha finito di usare l’applicazione.

Per riassumere

Con la modalità Force Login, le licenze vengono consumate solo quando gli utenti iniziano a lavorare con i dati e la logica del server REST. Questo significa:

  • Riduzione del consumo di licenze: I moduli di accesso non consumano più licenze.
  • Miglioramento dell’esperienza utente: Gli utenti possono tentare di effettuare il login senza che ciò influisca sulle licenze disponibili.
  • Migliore gestione delle risorse: La licenza viene liberata una volta che l’utente esce dall’applicazione.

Liberare una licenza di 4D Client in qualsiasi momento

La sessione può essere chiusa semplicemente attivando l’azione standard Logout e la licenza di 4D Client può essere liberata.

Si tratta di un miglioramento significativo, quindi cerchiamo di approfondire i dettagli per capire come si può beneficiare di questa funzione.

Come attivare la modalità di accesso forzato

L’attivazione della modalità di accesso forzato è semplice. Basta andare nella sezione Ruoli e privilegi e attivarla.

blank

Questo aggiorna il file roles.json del progetto di conseguenza.

{
"permessi": {
"allowed": [
]
},
"privilegi": [
],
"ruoli": [
],
"forceLogin": true
}

Comportamento dettagliato

Una volta attivata questa modalità:

  1. Le richieste REST descrittive( cioè richieste come rest/$catalog o rest/$getWebForm per rendere un modulo web) non consumano alcuna licenza.
  2. Le altre richieste REST(ad esempio, le richieste che gestiscono i dati o che richiamano le funzioni delle classi del modello ORDA Data) vengono rifiutate finché non viene completata l’autenticazione.
  3. È necessario implementare una funzione il cui nome deve essere authentify() nella classe del datastore. Questa funzione gestisce l’autenticazione. Questa è l’unica richiesta REST descrittiva accettata senza un’autenticazione riuscita.

Una volta che l’autenticazione è riuscita, tutte le richieste REST vengono accettate e viene consumata una licenza client 4D.

Un’autenticazione riuscita significa chiamare la funzione Session.setPrivileges().

Ecco la cronologia di questo processo:

blank

Esempio: Applicazione per venditori

Questo esempio presenta un’applicazione che gli addetti alle vendite utilizzano per lavorare con i file dei loro clienti.

L’utente finale rende un modulo Web con una fonte di dati di tipo selezione entità (classe di dati Clienti) con il valore iniziale Tutti.

L’errore viene ricevuto perché non è ancora stata eseguita l’autenticazione:

blank

blank

Tuttavia, l’utente finale può eseguire il rendering di questo semplice modulo Web che non gestisce dati né chiama alcuna funzione quando viene caricato. In questo momento non viene consumata alcuna licenza di 4D Client.

blank

Quando l’utente finale fa clic sul pulsante Vai, viene richiamata la funzione authentify(). È stata implementata nella 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 

Questa chiamata viene accettata.

Se l’autenticazione fallisce, la funzione Session.setPrivileges() non viene chiamata. Pertanto, non viene consumata alcuna licenza e non vengono rifiutate richieste REST descrittive.

Se l’autenticazione ha successo, viene chiamata la funzione Session.setPrivileges(). In questo modo, viene consumata una licenza client 4D e qualsiasi richiesta REST viene accettata. È quindi possibile iniziare a lavorare in modo efficiente con i dati.

Nota: in questo esempio, alla funzione Session. Use the setPrivileges() viene passata una stringa vuota per autenticarsi come ospite. Naturalmente, è possibile impostare i privilegi corrispondenti all’autenticazione degli utenti.

Inoltre, è possibile offrire agli utenti finali una funzione di disconnessione grazie all’azione standard di logout menzionata in precedenza. La sessione verrà svuotata dei suoi privilegi e l’utente finale tornerà nello “stato non autenticato”: verranno accettate solo richieste REST descrittive e l’utente dovrà autenticarsi di nuovo per lavorare con i dati.

Conclusione

Con la modalità Force Login in 4D 20 R5, è possibile ottimizzare il consumo di licenze client 4D nelle applicazioni web di Qodly Studio for 4D. Questo migliora l’esperienza dell’utente e la gestione delle risorse del server. Fateci sapere cosa ne pensate di questa funzione sui forum 4D!

Avatar
- Product Owner - Marie-Sophie Landrieu-Yvert è entrata a far parte del team 4D Product come Product Owner nel 2017. In qualità di Product Owner, è incaricata di scrivere le storie degli utenti e di tradurle in specifiche funzionali. Il suo ruolo è anche quello di assicurarsi che l'implementazione della funzionalità fornita soddisfi le esigenze del cliente.Marie-Sophie si è laureata presso la scuola di ingegneria ESIGELEC e ha iniziato la sua carriera come ingegnere presso IBM nel 1995. Ha partecipato a vari progetti (di manutenzione o di costruzione) e ha lavorato come sviluppatrice Cobol. In seguito ha lavorato come progettista UML e sviluppatore Java. Ultimamente i suoi ruoli principali erano l'analisi e la scrittura dei requisiti funzionali, il coordinamento dei team di business e di sviluppo.