In questi giorni sto completando il porting di una serie di script Google App Script nella forma di Google Workspace Add On.
Di per sé non è una cosa molto complicata sebbene ci siano un paio di comportamenti che è necessario gestire in maniera diversa rispetto agli script originali.
Ad alto livello l’architettura dell’Add On è la seguente:
- E’ possibile installare l’Add On solo da coloro che appartengono alla nostra organizzazione. Questa è una cosa semplice perché Google Marketplace ti permette di farlo senza passare dalla approvazione da parte di Google dell’Add On.
- L’Add On funziona solo ed esclusivamente quando lavora all’interno di un Google Sheets dalla struttura ben definita. Di fatto l’Add On è scritto proprio per automatizzare alcune funzioni proprie di quella tipologia di spreadsheets ed in seguito conversare con Salesforce tramite delle REST API.
Da questo si deduce che l’Add On recupera delle informazioni presenti all’interno dello spreadsheet, le manipola e poi le deposita in altre sezioni dello spreadsheet o sulla piattaforma Salesforce. Niente di magico.
Per lo sviluppo vero e proprio si utilizza l’editor di Google App Script. Se il progetto è piccolo questo editor è sufficiente. Nel caso di progetti più ampi l’editor comincia a mostrare dei limiti e si devono trovare delle alternative più efficaci.
In questo caso ci viene in aiuto Google clasp (https://github.com/google/clasp) che è una utility che ci permette di duplicare sul nostro personal computer un progetto Google App Script per poterci lavorare localmente.
A questo punto è possibile utilizzare un qualsiasi IDE congiuntamente a clasp per lavorare in maniera più efficiente.
Io personalmente uso Visual Studio Code che è aperto sulla directory che ospita il codice e, contemporaneamente, uso il comando “clasp push -w” in una finestra del terminale sempre su Visual Studio Code. Ogni volta che salvo un file sul mio computer questo viene automaticamente modificato su Google Script ed è subito pronto per essere testato.
Dato che l’Add On funziona solo su un documento Google Sheets è necessario che questo foglio sia aperto per potere testare il proprio Add On. Questo implica che di base non è possibile testare l’Add On direttamente dall’editor di Google App Script. Questo è un vero peccato perché il debugger dell’editor non è nemmeno male.
Esiste però una alternativa, sebbene macchinosa.
L’Add On può essere in grado di capire se viene eseguito all’interno dell’editor o da uno spreadsheet. Se l’Add On viene eseguito all’interno di uno spreadsheet il flusso è quello normale. Se l’Add On viene eseguito all’interno dell’Editor si evitano tutte le interazioni con l’utente, ovviamente prendendo delle decisioni a priori rispetto al comportamento desiderato, e si usa uno spreadsheet di riferimento per il debug.
Dato che ci ho messo qualche tempo a capire in che modo discernere se l’Add On era in esecuzione su uno spreadsheet o sull’editor vi riporto la funzione che verifica questa cosa.
function uiCheck() {
const scriptId = ScriptApp.getScriptId();
const url = "https://script.googleapis.com/v1/processes?pageSize=1&userProcessFilter.scriptId=" + scriptId;
const res = UrlFetchApp.fetch(url, {
headers: { authorization: "Bearer " + ScriptApp.getOAuthToken() }, });
const obj = JSON.parse(res.getContentText());
return obj.processes[0].processType;
}La funzione ritorna null se l’Add On è in esecuzione in uno spreadsheet o ritorna ‘Editor’ se in esecuzione dall’editor.
In questo modo è possibile usare il debugger del Google Script Editor in maniera abbastanza semplice.
Avendo il codice sul proprio personal computer, ed avendo la capacità di discernere l’ambiente di lavoro, è possibile usare in maniera efficace degli strumenti di Unit Testing sul codice locale. Anche questo è un pochino macchinoso, ma funziona (benino).
Non è proprio una passeggiata di salute ma funzionicchia.
Ovviamente è sempre possibile scrivere dei log degni di questo nome per effettuare un debug un pochino agricolo se non si ha voglia di sbattersi con quanto ho descritto poco sopra.