In questo articolo vedremo come è stato possibile, da un nostro cliente (che d’ora in poi chiameremo ClienteSmeup), passare da  una situazione in cui un singolo Looc.UP era condiviso da 200 postazioni al caso di 200 Looc.UP che si aggiornassero all’unisono comandati da un’unico Sme.UP Provider.

Situazione Iniziale

In ClientSmeup la soluzione adottata per la gestione delle postazioni dei dipendenti era molto datata e ormai superata. Essa prevedeva un unico Looc.UP installato sul server centrale che veniva condiviso per creare delle sessioni su ogni postazione e questo portava molti svantaggi, per esempio:

  • Non poter aggiornare all’ultima versione di Looc.UP e quindi beneficiare dei nuovi sviluppi e bugfix
  • Generazione di traffico inutile sulla rete (dato che ogni comando, anche il più banale, prevedeva la comunicazione al server)
  • Gestione dei log non efficiente
  • Impossibilità di poter aggiornare la versione di LoocUP solo per alcuni client (per esempio quelli per la fatturazione elettronica)

Parlando con il ClienteSmeup si è deciso di ovviare a questi problemi utilizzando una strategia che prevedesse l’installazione dell’applicazione Looc.UP su ogni pc di ogni dipendente, e sul server centrare di uno Smeup Provider che potesse gestire l’aggiornamento manuale dei client.
Questo perchè si è deciso di comune accordo di permettere all’amministratore di sistema di avere la possibilità di provare le nuove funzionalità prima di rilasciarle in massa ai suoi colleghi, così da avere sempre sotto controllo la situazione e di ridurre al minimo la possibilità di malfunzionamenti e/o interruzioni di servizio.
Si è anche pensato in un futuro di gestire separatamente gli aggiornamenti tra la parte “officina” da quelli della parte “amministrativa”, dopo aver passato un periodo di prova con la nuova organizzazione.

Verrano quindi qui proposti alcuni scenari tipici adottati in queste situazioni, dal caso più semplice come qui adottato, al caso un pò più complesso.

Scenari tipici

Sme.UP pubblica gli aggiornamenti delle varie versioni di Loocup tramite un provider accessibile all’indirizzo http://update.smeup.com.
Quindi qualunque client Looc.UP che richieda aggiornamenti a questo indirizzo, nel caso Sme.UP ne avesse, sarà in grado di portarsi all’ultima versione disponibile.

La configurazione più banale quindi all’interno di un’azienda è quella di impostare tutti i Looc.UP installati in modo tale che facciano riferimento a link sopra indicato, avendo così la possibilità di avere aggiornamenti periodici ad ogni rilascio da parte di Sme.UP.

La configurazione invece adottata in ClienteSmeup è stata quindi quella di avere uno Sme.UP Provider “Master” (http://server1.cliente.com) interno all’azienda che facesse direttamente riferimento a Sme.UP per gli aggiornamenti e che si intrapponesse tra Sme.UP e i client dei dipendenti (che sono indirizzati verso server1.cliente.com per l’aggiornamento). Come si può notare dalla foto il solo pc dell’amministratore è stato impostato per dialogare direttamente con l’updater di Sme.UP.

Così facendo, come già spiegato precedentemente solo quando il sistemista aggiorna il proprio client Looc.UP e ne accerta il corretto funzionamento, provvede ad aggiornarlo sul server principale, che scatenerà la possibilità anche a tutti i client di vedere l’aggiornamento e provvedere a scaricarlo ed installarlo (infatti è stato scelto di aggiornarli con la modalità automatica).

 

L’aggiornamento di tale provider con i rilasci ufficiali, può essere eseguito manualmente o tramite uno script schedulato che esegua SmeupGO con il parametro –OUP: (per maggiori dettagli fare riferimento alla sezione “Aggiornamenti speciali”).

Nel caso serva un’organizzazione più complessa (as esempio con multisede), può essere utilizzata una struttura in cui vi sia uno Sme.UP Provider “Master”, che faccia da riferimento per uno o più Sme.UP Provider “Slave”.

 

 

In questa configurazione si riduce il carico che avrebbe un unico provider, eventualmente sfruttando una rete locale, riducendo i requisiti di banda verso l’esterno.
Anche in questo caso, gli aggiornamenti dei provider “Slave” possono essere schedulati o essere eseguiti manualmente.

Come farlo

Il primo passo da fare è decidere  la scelta della configurazione che si intende utilizzare.
Nel mio caso, come è già stato ampliamente spiegato pocanzi, è stato scelto un approccio che permettesse al sistemista di poter aggiornare la sola versione master  e i dipendenti della ClientSmeup fossero in grado di poter aggiornare autonomamente il proprio client Looc.UP, allineandosi però alla sola versione risiedente sul master e nascondendo loro la possibilità di vedere ulteriori aggiornamenti rilasciati da Sme.UP.

In altre parole questo significa che questi aggiornamenti possono essere visti come una sorta di gerarchia, dove il dispositivo sottostante può vedere solo il dispositivo che sta subito sopra a lui (vedi figura sottostante).

 

 

Analizzando l’immagine riportata come esempio (dove le versioni sono puramente dimostrative) si può quindi capire che la versione di Looc.UP installata sui due client è diversa, troviamo infatti sul Looc.UP di sinistra una versione  Roma v1, mentre su quello di destra Sidney v1 ed entrambe sono state obbligate a “vedere” i soli aggiornamenti messi a disposizione dal provider “master” soprastante.
Sul provider “master” si è scelto di poter tenere aggiornate queste due versioni (Sidney e Roma) ed al momento sul “master” la versione installata è la v2 per Roma e la v3 per Sidney.
Possiamo quindi notare che i client hanno la possibilità a loro volta di allienarsi a queste due versioni. Ovvero per la Roma passare dalla v1 alla v2, e Sidney dalla v1 alla v3.

Sempre con lo stesso ragionamento il provider “master” potrebbe essere collegato ad altri provider all’infinito (in questo caso no), fino a risalire fino a Sme.UP, dove troviamo che le ultime versioni rilasciate sono Roma v3 e Sidney v5.

Nel caso volessimo quindi aggiornare i client Looc.UP alla v5 per Sidney e alla v3 per Roma  occorrerà prima aggiornare il provider, dopodichè lanciare l’updater sui client per allinearli a quest’ultimo.

 

Dopo aver scelto la strategia da utilizzare, vediamo cosa ci server per configurare il sistema:

  • un server su cui installare Sme.UP Provider;
  • i client con installato una versione Looc.UP;
  • accesso all’SCP_CLO dell’utente del provider;

Per prima cosa installiamo lo Sme.UP Provider sul server del cliente (deve necessariamente essere versione pari o successiva alla V4R1M150315) con relativo upgrade scaricabile da qui.

Creiamo quindi una cartella in cui andremo ad inserire le varie versioni di Looc.UP che vogliamo tenere aggiornate, nel mio caso ho creato la cartella “c:\loocupupdate“:

  

Recarsi ora nell’SCP_CLO dell’utente del provider ed aggiungere la voce “PROVIDER_UPDATE_FOLDER”  in cui andremo ad inserire nel valore della variabile, il path della cartella appena creata.

[...]

******************************************************************** 
* Gestione aggiornamento Loocup 
******************************************************************** 
::C.VAR Cod="PROVIDER_UPDATE_FOLDER" Txt="la cartella che contiene le versioni da aggiornare" TVal="J1" PVal="PATHDIR" Value="c:\loocupupdate" 

[...]

 

Tramite questa procedura avremo la possibilità di tenere aggiornate più versioni di Looc.UP andando ad inserire nella cartella creata delle sub-cartelle che devono soddisfare questo fondamentale pre-requisito:

  • Ogni versione va installata in una cartella il cui nome coincide con il codice della versione stessa.

Questo significa che se volessimo tenere aggiornata le versioni di Roma e di Sydney contemporaneamente, dovremo creare due cartelle:

  • Sydney sarà contenuta nella cartella avente nome “c:\loocupupdate\V4R1M151024
  • Roma sarà contenuta nella cartella avente nome “c:\loocupupdate\V5R1M161106″

Nel mio caso però si è scelto di utilizzare la sola versione Roma e di conseguenza ho creato la sola cartella “c:\loocupupdate\V5R1M161106“.

Il passo successivo è quello di scaricare da qui la versione corretta di Looc.UP e scompattarlo all’interno della cartella identificata dalla relativa versione.

Ora bisogna dire al master che abbiamo appena creato da chi deve aggiornarsi.
Per fare questo lanciare il file “Smeupgo.exe” sotto la voce:

FUNZIONI AVANZATE > SISTEMA > GESTIONE CONFIGURAZIONE

ed impostare i parametri di configurazione inserendo la url da cui si vuole che il master scarichi gli aggiornamenti e se farlo in modalità manuale o no. (nel mio caso è possbile aggiornalo solo in modalità manuale e scarica direttamente da Sme.UP).

Ora fare la stessa cosa sui client Looc.UP e nel parametro “Url server update” inserire la url e la porta dello Sme.UP Provider  (master) che abbiamo appena creato. (Nel mio caso “http://<ipServerClienteSmeup>:9090“).

Una volta fatto questo chiudere e riaprire lo “SmeupGo” per vedersi comparire il messaggio di aggiornamento disponibile per iniziare lo scaricamento e successivamente l’installazione.

Aggiornamenti speciali

E’ possibile eseguire un aggiornamento silenziando ogni richiesta o messaggio di errore ed evitando che lo SmeupGO si riavvii una volta eseguito l’aggiornamento.
Per avere questo tipo di operatività lo SmeupGo deve essere eseguito specificando il parametro –OUPD con l’indirizzo URL del provider SmeUP Provider di riferimento per gli upgrade.
Esempio: SmeupGO.exe –OUPD:http://myprovider.mydomain.com

Attenzione! Essendo silenziati i messaggi di errore, devono essere analizzati i log per verificare se l’operazione ha avuto successo!