Le sessioni al tempo di FileMaker 2023

Il nostro amato FileMaker sta diventando grande, è un pò come un figlio che ormai è più alto e più robusto di noi, ed è ora di iniziare a considerarlo adulto.

Ma dato che parliamo di un sistema informativo, la crescita si misura parametri come scalabilità, interscambio con altre tecnologie, consistenza dei dati e tracciabilità delle operazioni effettuate. Vediamo quindi come siamo messi:

• la scalabilità è garantita dalle implementazioni presenti nelle ultime versioni
• l'interscambio viene garantito dai continui miglioramenti dell'istruzione InserisciDaURL, dalle ESS, dalla compatibilità con Claris Connect e Claris Studio
• La consistenza dei dati viene gestita dal nuovo sistema delle transazioni e dai trigger attivati dal motore di calcolo
• La tracciabilità delle operazioni effettuate viene garantita anche grazie all’utilizzo delle sessioni e dei file di log

Sessioni e log

L'utilizzo di un approccio a sessioni non è particolarmente nuovo, dato che era già possibile con una serie di accorgimenti (anzi in alcuni casi, come l'utilizzo di WebDirect era l'unico modo di effettuare alcune operazioni). Tuttavia, stiamo migrando dal workaround di vecchia memoria, fantasioso ed arguto ma legato all’estro dello sviluppatore, ad una caratteristica strutturale, parte integrante del sistema (per chi volesse approfondire i vari lati utili dell’utilizzo delle sessioni, Giulio Villani ha creato un laboratorio specifico).

Questo tipo di approccio non ha molto senso se si utilizza FileMaker Pro in singola utenza, ma diventa fondamentale nell'ottica della centralità di FileMaker Server come fulcro di tutta la piattaforma.

Vediamo in dettaglio

Dalla nuova versione è possibile utilizzare uno step Set Session Identifier col quale si assegna un codice all’utente che si collega a FileMaker Server.

In questo codice possiamo mettere ciò che vogliamo, dal nome del cagnolino a quello di “mio cuggino che fa bene la carbonara”, ma in linea di massima ci conviene inserire un qualcosa che identifica l’evento, la connessione dell’utente al server FileMaker, quindi potremo usare la funzione Get(UUID) se vogliamo identificare l’evento in  maniera univoca oppure qualcosa che identifichi l’utente se ci interessa maggiormente tracciare le mosse dei nostri utenti.

In assenza di una scelta da parte nostra l’ID sessione viene impostato con lo stesso valore ricavato dalla funzione Get(Nome Utente), più esplicito ma molto (troppo) esposto ad essere ambiguo in quanto il nome utente è modificabile nelle preferenze di FileMaker client, e non è il nome dell'account con cui si entra nel file.

Questa possibilità cambia dal'essere carina a molto utile in 3 modi.

1. l’ID Sessione viene mostrato nella console di FileMaker Server, per cui possiamo seguire live cosa fanno i nostri utenti.
2. A partire dalla versione 19.4, Filemaker ha una funzione Get(SessionIdentifier) che ritorna quanto impostato dallo step Set Session Identifier, e qui le cose si fanno interessanti: possiamo lavorare a sessioni ma toglierci di mezzo la variabile globale $$Sessione che usavamo con i precedenti metodi per identificare la sessione, anche se la funzione ritorna il valore impostato solo nel file in cui è stata eseguita, mentre nella console di FileMaker Server l’ID sessione vale per tutti i file aperti dall’utente.
3. l’IDSessione finisce nei file di log, segnatamente nell’Access log e nelle Top calls, che possiamo scaricare, vedere live sul server, importare in Excel per farne statistiche, importare in FileMaker per farne di tutto.

Per quanto riguarda i file di Log abbiamo un nuovo arrivo, il file ScriptEvent.log, visibile nella console di FMS e scaricabile insieme agli altri file di Log.

Il file riporta gli errori incontrati nel corso dell’esecuzione degli script, e si applica anche agli script eseguiti lato server (al momento non è disponibile per WebDirect e DataAPI)!

Infatti ogni voce del log riporta il TimeStamp dell’evento, il codice dell’errore, il “Programma” che sarebbe lo script eseguito su server, il nome del file ed il nome dell’eventuale subscript in cui si è verificato l’errore.

Nell’elenco sottostante è riportato un esempio:

La procedura chiamata dal client sul server non evita l’esecuzione dello script di apertura del file per cui tutti gli step dei subscript (Inizio procedura login/start e Inizio procedura login/Go) vanno in errore, e poi lo script principale contiene un altro errore, correttamente documentato.

La cosa importante è ovviamente la tracciatura degli errori negli script eseguiti lato server, un primo passo, piccolo ma importante, verso un debugging degli script lato server simile a quello che abbiamo sul client.

Se ti serve aiuto per ottimizzare le prestazioni del tuo FileMaker Server o per mettere in sicurezza i tuoi dati, ci trovi sul FileMaker Guru Corner, il nostro forum e nella nostra meravigliosa community Facebook FileMaker Developer Italia dove facciamo assistenza gratuitamente. Se invece hai bisogno di un preventivo per una consulenza, mandaci una email (team@fmguru.it)!