Quando Esegui Script Su Server diventa una trappola mortale.

Esegui Script su Server è una delle istruzioni che hanno cambiato il modo in cui si sviluppa FileMaker. Non solo permette di velocizzare molto delle procedure pesanti in rete, ma a volte è proprio l’unico modo per eseguire una serie di task, come ad esempio la stampa da PDF in WebDirect.

Ma come funziona Esegui Script su Server? Abbiamo scritto articoli e fatto laboratori e corsi, dove spieghiamo in dettaglio come funzioni. Per lo scopo di questo articolo diciamo solo che l’istruzione “crea” all’interno di FileMaker Server una sorta di “FileMaker Pro virtuale” che esegue lo script richiesto.

Non stupisce quindi che sia diventata una delle opzioni più popolari per sviluppare, tanto che Claris recentemente ha anche implementato la compatibilità con FileMaker Server. A partire da FileMaker 21.1 Possiamo quindi eseguire uno script su server partendo da uno script su server.

Lo scenario

E qui inizia il pericolo. Per fare un esempio, diciamo che abbiamo una soluzione che esegue uno script ogni volta che un utente si disconnette. Per rendere le cose automatiche abbiamo impostato un trigger SuChiusuraUltimaFinestra che esegue uno script del tipo:

• Salva record/Richieste
• Esegui Script Su Server [“ilmioscript”; parametro; Attendi:Disattivata]

In se’ questa scelta ha senso: eseguendo lo script su server senza attendere la chiusura, il sistema funziona anche su WebDirect e non ha problemi di lentezza su client.

E infatti, ospitando la nostra soluzione su FileMaker Server 20 non abbiamo problemi e funziona in maniera soddisfacente. Anche aggiornando a FileMaker 21 non ci sono problemi.

Il problema sorge quando facciamo un aggiornamento “minore” e passiamo il nostro Server a FileMaker 21.1: abituati a non avere problemi di compatibilità fra una versione minore e l’altra di FileMaker Server andiamo tranquilli… e scopriamo che la nostra soluzione funziona, ma lascia su FileMaker Server una serie di connessioni aperte dello ScriptEngine per ogni script eseguito.

Peggio succede nel caso di uno script diverso solo per un parametro:

• Salva record/Richieste
• Esegui Script Su Server [“ilmioscript”; parametro; Attendi:Attivata]

In questo caso il risultato è sicuramente peggiore: Il client si pianta al primo script eseguito su server, a volte fino al punto di dover riavviare FileMaker Server (e in alcuni casi addirittura la macchina)!

Cosa è successo?

In se è (quasi) semplice: come abbiamo detto all’inizio dell’articolo, Esegui script su server crea di una sorta di “FileMaker Pro virtuale”. E quando lo script è finito, il FileMaker Pro virtuale si chiude… ed esegue il trigger SuChiusuraUltimaFinestra come se fosse un client reale!

Su FileMaker 20 questo non è un non problema: non potendo eseguire l’istruzione Esegui Script Su Server server-side, il motore di calcolo si limita ad ignorare l’istruzione non compatibile, chiude lo script e finisce li. FileMaker Server 21 invece supporta questa istruzione e quindi… esegue un altro script su server.
Che a sua volta apre un altro FileMaker Pro virtuale che quando si chiude, esegue un altro script… come in una infinita catena di Sant’Antonio.

E fin qui è “quasi” sotto controllo. in fondo uno script si chiude, un altro si apre, ma non è un problema immediatamente paralizzante.

Il problema diventa paralizzante nel momento in cui viene eseguito uno script server-side con l’opzione “Attendi” attivata. In questo caso cosa succede:

• lo script sul client esegue lo script lato server, aspettandone la fine (quindi – di fatto – il client è bloccato fino a che non finisce lo script lato server
• lato server lo script fa quello che deve e chiude… ma viene lanciato lato server lo script dal trigger SuChiusuraUltimaFinestra. Che finisce e si chiude a a sua volta lanciando un altro script…
• le sessioni contemporanee sul server salgono, i client sono bloccati e in sostanza l’unica soluzione è chiudere il file o – nei casi peggiori -riavviare il server

Analogamente, lo stesso comportamento avviene se il trigger che attiva lo script è SuAperturaPrimaFinestra, come spesso accade nella gestione delle sessioni:

• …fai qualcosa…
• Esegui Script Su Server [“Crea sessione”; parametro; Attendi:Attivata]
• Imposta campo [globali::SID; get(risultatoscript)]
• … fai altro

In questo caso sul client funziona… fino ad arrivare alla riga dove esegue lo script su server, che a sua volta esegue un altro script su server, e così via.

La soluzione? Controlli, controlli e ancora controlli.

I controlli su quello che potrebbe andare storto dovrebbero essere presenti in tutti gli script delle nostre soluzioni. in questo caso la soluzione è abbastanza semplice: è sufficiente modificare lo script aggiungendo un if:

• If[Contaricorrenze(Get(VersioneApplicazione); “Server”)=0]
  • Salva record/Richieste
  • Esegui Script Su Server [“ilmioscript”; parametro; Attendi:Disattivata]
• End if

oppure:

• If[Contaricorrenze(Get(VersioneApplicazione); “Server”)=0]
  • …fai qualcosa…
  • Esegui Script Su Server [“Crea sessione”; parametro; Attendi:Attivata]
  • Imposta campo [globali::SID; get(risultatoscript)]
  • … fai altro…
• End if

In questo caso se lo script viene eseguito su server non esegue nessuna istruzione, evitando la creazione della catena di sant’Antonio descritta in precedenza.

È colpa dell’aggiornamento!

Questo scenario è particolarmente interessante perchè:

• Parte da un uso legittimo e corretto di una serie di caratteristiche (il trigger SuChiusuraUltimaFinestra o SuAperturaPrimaFinestra, l’istruzione Esegui Script Su Server)
• Funziona in maniera corretta nella versione di FileMaker in cui è stato creato
• Aggiornando versione si blocca tutto, non per un “bug” o una incompatibilità, ma per una modifica annunciata, addirittura un miglioramento del motore di calcolo.

Verrebbe da pensare che sia colpa dell’aggiornamento, e che quindi è meglio evitare di aggiornare FileMaker.

In realtà non è così.

Aggiornare in maniera consapevole è una buona pratica che permette di mantenere la sicurezza e incrementare le prestazioni.

Quello che va fatto è sviluppare in maniera da intercettare errori che possono compromettere la nostra soluzione. Ovviamente nessuno può leggere nel futuro, ma ci sono una serie di buone pratiche (come la nostra soluzione – in se semplicissima). Se non sei sicuro di come fare, non preoccuparti. Ci siamo noi per aiutarti!