INTRODUZIONE
Questa guida illustra la funzionalità implementata nei software 2bit di effettuare le richieste al cassetto rendiresto da app server, e non direttamente da software, per poter utilizzare più postazioni con lo stesso cassetto rendiresto.
CONFIGURAZIONE
La parte di configurazione sui software retail/food del rendiresto deve prevedere una nuova sezione, alternativa a quella esistente, chiamata “Server Mode”. Quella attuale si chiamerà “Stand alone Mode”, e continuerà a funzionare per quelle realtà che hanno un dispositivo per postazione, o un dispositivo con interfaccia LAN (quindi raggiungibile da più postazioni).
Nella parte ServerMode va indicato l’indirizzo ip/porta del server, o più precisamente della postazione dove risiede l’app server con il rendiresto, e quale “dispositivo” interrogare tra una lista precaricata in precedenza. Potrà essere selezionato un “dispositivo” predefinito per la postazione.
Con “dispositivo” si intende una nuova entità, tabellare, dove “mappare” i rendiresto “condivisi” tra le postazioni. Ogni “dispositivo” creato dovrà avere le informazioni necessarie per istanziare una comunicazione software con gli applicativi 2bit.
ANALISI TECNICA – Client
In modalità ServerMode, alla prima richiesta verso il rendiresto verrà istanziato l’oggetto CashMachine, indicando la modalità server-side, con ip e porta dell’app server. La classe aggiuntiva verrà sviluppata come “nuovo” rendiresto da interfacciare, implementando le interfacce attualmente previste per la comunicazione COM (verso VB) + un HTTP REST CLIENT.
Il funzionamento prevede di effettuare una chiamata REST all’app server, indicando l’id del dispositivo da usare, l’enumeratore dell’operazione da effettuare (pagamento ,versamento, cancellazione, chiusura, azzeramento stacker ect), ed eventuali dati richiesti dal tipo operazione (es: importopagamento).
L’app server, ricevuta la richiesta, dovrà restituire istantaneamente un HTTP200 + un GUID per marcare l’operazione richiesta.
Durante l’attesa, il client dovrà verificare lo stato della richiesta, interrogando l’app server ogni secondo (da valutare) con una specifica rotta di GetStatus, alla quale verrà passato il guid dell’operazione in corso. Il dato di ritorno verrà interpretato dalla libreria CashMachineServer, sollevando eventuali eventi visibili lato COM (es: inserimento monete durante il pagamento) per mantenere l’attuale funzionamento.
La procedura potrà dichiararsi conclusa quando l’app server restituirà alla rotta di GetStatus uno stato di tipo CONCLUSO con esito POSITIVO.
ANALISI TECNICA – Server
Il server riceve la richiesta tramite chiamata rest, verifica quale dispositivo è stato richiesto e verifica se esiste già una istanza di quel dispositivo.
Se esiste, la utilizza (poichè attualmente sarà aperta una “connessione” con quel dispositivo), altrimenti ne istanzia uno ed apre un collegamento col rendiresto. L’istanza dell’oggetto dovrà utilizzare la business logic attualmente esistente e presente nella solution “DueBitCashMachine”. Se il dispositivo non esiste, verrà sollevata eccezione.
Contestualmente, dovrà indicare in una nuova tabella di log delle transazioni rendiresto il guid identificativo, ed uno stato della richiesta. Lo stato sarà identificato con un numero intero, ed una stringa descrittiva, Saranno previsti altri campi per gestire, ad esempio, l’avanzamento dei contanti inseriti. Questo punto verrà approfondito durante lo sviluppo.
Il server a questo punto interroga il rendiresto e riceve, tramite la gestione eventi già sviluppata in “DueBitCashMachine”, aggiornamenti di stato dell’operazione in corso (ad esempio l’incremento dei contanti inseriti durante un pagamento). L’aggiornamento viene registrato come nuovo record della tabella di log.
Qualsiasi aggiornamento dal rendiresto viene indicato nella tabella di log, e quindi disponibile come esito nella rotta di GetStatus. Se durante un pagamento (quindi operazione in corso) il client invia una seconda operazione (ES ANNULLO o AZZERAMENTO), il server deve recuperare dalla cache il dispositivo in uso, ed inviare il comando richiesto. Il client resterà in ascolto finchè l’operazione non terminerà con uno stato di tipo CONCLUSO con esito POSITIVO.
In caso di stato CONCLUSO con esito NEGATIVO, dovranno essere approfonditi in seconda battuta i metodi per notificare l’errore all’operatore.
CONFIGURAZIONE SERVER
Individuare la postazione candidata a “server”, ovvero quella con il dispositivo rendiresto collegato.
In C:\2Bit\DueBit.CashMachineServer editare il file DueBit.CashMachineServer.exe.config, indicando l’ip della postazione nelle seguenti chiavi:
Le porte preconfigurate saranno la 9090 per l’host server, e 9091 per il server di messaggi signalR.
Assicurarsi pertanto che le postazioni client riescano a comunicare sull’ip e le porte indicate.
Avviare con privilegi di amministratore l’applicativo
Se l’avvio avviene correttamente, la maschera sarà simile a questa:
NB: Tutte le operazioni del server vengono loggate nel percorso dell’applicativo + sottocartella LOG, nel file CasMachineServer.log.
CONFIGURAZIONE CLIENT
Avviare la postazione client. Accedere alla sezione di impostazioni del rendiresto. Selezionare, tra i device interfacciati, la voce ServerMode. Verrà visualizzata una griglia con i dispositivi rendiresto configurabili nel negozio. Premere il tasto Aggiungi, indicare il modello di rendiresto, una descrizione generica, ip e porta (se richiesti dal modello).
Se è presente l’applicativo di backoffice del rendiresto, indicarne il path nella colonna SOFTWAREEXEPATH. Se necessario anche utente e password, indicarli nella colonna USERNAME e PASSWORD (password in chiaro).
Settare come predefinito il modello che si vuole usare in questa postazione, previa pressione del tasto SET PREDEFINITO.
Nella parte inferiore, indicare l’ip della macchina con il server in esecuzione.
Con il tasto TEST si esegue una chiamata di prova al server. Accertarsi che il server sia avviato e premere TEST.
Importante: assicurarsi che sia presente in c:\2bit\main un file 2bit.main.exe.config.
contenente questo testo:
<configuration>
<runtime>
<assemblyBinding xmlns=”urn:schemas-microsoft-com:asm.v1″>
<dependentAssembly>
<assemblyIdentity name=”FluentValidation”
publicKeyToken=”7de548da2fbae0f0″
culture=”neutral” />
<bindingRedirect oldVersion=”8.0.0.0″ newVersion=”9.0.0.0″ />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name=”Newtonsoft.Json”
publicKeyToken=”30ad4fe6b2a6aeed”
culture=”neutral” />
<bindingRedirect oldVersion=”0.0.0.0-12.0.0.0″ newVersion=”12.0.0.0″ />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Se il file manca, crearlo e copiare il contenuto dell’xml indicato, e riavviare l’applicativo.
E’ di fondamentale importanza differenziare il nome cassa tra le due postazioni. Infatti, è per nome della cassa che vengono creati i collegamenti tra server e client. Assicurarsi pertanto che le postazioni con server in condivisione abbiano nomi cassa differenti. L’anagrafica casse è in backoffice –> anagrafiche –> tabelle –> punto cassa –> casse.
Il funzionamento del rendiresto da punto cassa resta uguale allo standard, con queste aggiunte:
1. se si invia una richiesta al rendiresto, e questo risulta occupato, la richiesta viene rifiutata e sulla cassa viene visualizzato un messaggio di “risorsa occupata”
2. si il server è spento, alla prima richiesta al rendiresto server verrà visualizzato sul client un messaggio di errore comunicazione con il server – motivo Service Unavaiable (servizio non disponibile).