Differenze tra le versioni di "Server OpenPass"
| [versione bozza] | [versione di qualità] |
(→Architettura software dei SERVIZI WEB Sistema openpass) |
|||
| (22 versioni intermedie di 2 utenti non mostrate) | |||
| Riga 2: | Riga 2: | ||
Il Server OpenPass prevede l’invio dei dati di passaggio e vendita (ed i dati necessari al completamento dei primi due flussi come ticket e customer) da parte delle stazioni consociate ANEF Ski Lombardia in formato XML attraverso l’utilizzo di WebService. L’invio dei dati da parte dei client delle stazioni al server OpenPass può essere in real time oppure in differita tramite processi di batch a seconda del fornitore dei sistemi di accesso collegati alle stazioni. | Il Server OpenPass prevede l’invio dei dati di passaggio e vendita (ed i dati necessari al completamento dei primi due flussi come ticket e customer) da parte delle stazioni consociate ANEF Ski Lombardia in formato XML attraverso l’utilizzo di WebService. L’invio dei dati da parte dei client delle stazioni al server OpenPass può essere in real time oppure in differita tramite processi di batch a seconda del fornitore dei sistemi di accesso collegati alle stazioni. | ||
| − | Il Server OpenPass prevede poi un invio giornaliero costituito da un unico file compresso (.ZIP) contenente i file in formato CSV (comma separated values) ed il file XML per le meta-informazioni su una risorsa condivisa con | + | Il Server OpenPass prevede poi un invio giornaliero costituito da un unico file compresso (.ZIP) contenente i file in formato CSV (comma separated values) ed il file XML per le meta-informazioni su una risorsa condivisa con la Lombardia; i dati trasferiti riguardano le anagrafiche ed i passaggi. |
== Comunicazione tra il server openpass e i client delle stazioni == | == Comunicazione tra il server openpass e i client delle stazioni == | ||
| Riga 13: | Riga 13: | ||
Il server gestisce a frequenza prestabilita operazioni di configurazione e di caricamento dati, attraverso chiamate XML. | Il server gestisce a frequenza prestabilita operazioni di configurazione e di caricamento dati, attraverso chiamate XML. | ||
| − | [[File:Comunicazione_openpass.png| | + | [[File:Comunicazione_openpass.png|thumb|800px|center|link=|Comunicazione tra il server OpenPass e i client delle Stazioni]] |
| + | === Servizi del Formato 3 === | ||
La comunicazione tra il server OpenPass ed i client delle stazioni avviene su protocollo HTTP mediante l’architettura software RESTful. | La comunicazione tra il server OpenPass ed i client delle stazioni avviene su protocollo HTTP mediante l’architettura software RESTful. | ||
| − | Per la comunicazione sono stati progettati e realizzati | + | Per la comunicazione sono stati progettati e realizzati dei servizi organizzati in risorse web accessibili a seguito di autenticazione. |
| − | L’architettura software utilizza il paradigma client-server | + | L’architettura software utilizza il paradigma ''client-server'': i servizi attivati, in architettura RESTful, sono di seguito riportati. |
| − | + | Il servizio è finalizzato a ricevere i dati relativi ai passaggi e alle vendite dei biglietti regionali dalle stazione consociate ANEF SKI Lombardia. | |
| − | |||
| − | + | I web services si possono dividere in queste macro-categorie: | |
| − | + | * Servizi di LOGIN | |
| − | + | * Servizi di GESTIONE del FORMATO | |
| − | + | * Servizi di INVIO DATI | |
| − | + | * Servizi di STRUTTURA dell'ARCHITETTURA | |
| − | + | * Servizi di SICUREZZA | |
| − | + | ||
| − | + | ANEF SKI Lombardia ha distribuito ad ogni stazione delle credenziali di accesso (username e password) ai web services per l’invio dei dati al server OpenPass. La company, per autenticarsi, deve chiamare i ''Servizi di LOGIN'', in particolar modo il '''Web Service''' (d’ora in poi '''WS''') '''LOGIN''' che consente l’autenticazione di un utente; tale autenticazione rimarrà attiva per tutta la durata della sessione di scambio dei dati. | |
| − | + | ||
| − | + | Una volta autenticati, si devono chiamare i WS della categoria ''Servizi di GESTIONE del FORMATO'': tali WS sono | |
| − | + | * '''REGISTERTOKEN''' | |
| − | + | * '''REGISTERFORMAT''' | |
| − | + | * '''ENUMERATEFORMATS''' | |
| − | + | * '''GETFORMAT'''. | |
| − | + | ||
| − | + | '''REGISTERTOKEN''' consente di registrare un token personalizzato. I tokens che cominciano con ‘Root.’ richiedono l’accesso di un amministratore. Ogni token ha un tipo associato (es. numerico, data, ora etc.). Il token non dipende dalla Stazione che ne fa richiesta. | |
| + | |||
| + | '''REGISTERFORMAT''' consente di registrare un formato di registrazione da utilizzare per la produzione e l’interpretazione di biglietti. Ritorna un codice identificativo univoco per il formato. La chiamata può essere effettuata tutte le volte che si vuole, il sistema ritornerà sempre lo stesso codice. Il codice di formato è quindi uguale per tute le stazioni che ne fanno richiesta. Lo stesso formato può essere condiviso tra più biglietti (es. Stagionale Adulti, Ridotto, FISI etc.). | ||
| + | |||
| + | '''ENUMERATEFORMATS''' restituisce l'elenco esaustivo dei codici identificativi dei formati noti al server. | ||
| + | |||
| + | '''GETFORMAT''' restituisce la definizione del formato di cui è stato specificato il codice identificativo in fase di chiamata. | ||
| + | |||
| + | Una volta che sono stati chiamati i ''Servizi di GESTIONE del FORMATO'' si possono utilizzare i ''Servizi di INVIO DATI'', in | ||
| + | particolar modo quei servizi dedicati alla ''GESTIONE della VENDITA'': fanno parte di questa categoria i WS | ||
| + | * '''REGISTERTICKET''' | ||
| + | * '''ENUMERATETICKETS''' | ||
| + | * '''GETTICKET''' | ||
| + | * '''REGISTERCUSTOMER''' | ||
| + | * '''REGISTERSALES''' | ||
| + | |||
| + | Il WS '''REGISTERTICKET''' consente di registrare un set di valori di tokens costanti per una certa categoria di biglietti al fine di poterla identificare con rapidità nelle elaborazioni dati. (Es. Stagionale adulti, Stagionale ridotto). Ritorna un codice identificativo univoco per il biglietto che è identico al valore passato per il token “TicketID” obbligatorio. La chiamata può essere effettuata tutte le volte che si vuole; a parità di valori il sistema ritornerà sempre lo stesso codice. La chiamata consente una registrazione diversa per ogni Stazione, ma il codice numerico ritornato sarà a parità di set di valori lo stesso su più stazioni. Due biglietti uguali non possono né devono avere codici identificativi differenti. | ||
| + | |||
| + | Il WS '''ENUMERATETICKETS''' ottiene l’elenco esaustivo dei codici identificativi dei biglietti noti al server per la stazione specificata in fase di chiamata. | ||
| + | |||
| + | Il WS '''GETTICKET''' ottiene la definizione del biglietto di cui si è specificato il codice identificativo in fase di chiamata. | ||
| + | |||
| + | Il WS '''REGISTERCUSTOMER''' permette la registrazione di un cliente sul sistema , restituendo al chiamante un codice numerico identificativo del customer. | ||
| + | |||
| + | Il WS '''REGISTERSALES''' registra un insieme di vendite di biglietti di consorzio in formato comune sul server per il gruppo, la società e le postazioni specificate. Ogni chiamata può contenere una o più registrazioni di vendita. Ogni vendita è associata ad un cliente, il cui codice identificativo va ottenuto con l'invocazione del servizio '''REGISTERCUSTOMER'''. Il CustomerIdentifier è a 0 per i biglietti non nominativi. All’interno di ogni vendita, unitamente al ticket identifier (che specifica i valori costanti), vengono specificati i valori rilevanti dei tokens ‘dinamici’, ovvero quelli assegnati al momento dell’edizione di un biglietto. | ||
| + | |||
| + | All’interno dei ''Servizi di INVIO DATI'' ci sono anche i servizi dedicati alla ''GESTIONE dei PASSAGGI'': il WS '''REGISTERPASSAGES''' registra un insieme di passaggi agli impianti di biglietti di consorzio in formato comune sul server per il gruppo, la società e gli impianti specificati. Ogni chiamata può contenere una o più registrazioni di passaggio. Ogni passaggio è opzionalmente associato ad un cliente, il cui codice identificativo va ottenuto con l'invocazione del | ||
| + | servizio '''REGISTERCUSTOMER'''. Ricordiamo che il CustomerIdentifier è a 0 per i biglietti non nominativi. All’interno di ogni passaggio, unitamente al ticket identifier (che specifica i valori costanti), vengono specificati i valori rilevanti dei tokens ‘dinamici’, ovvero quelli assegnati al momento dell’edizione di un biglietto e che si modificano durante l’utilizzo. | ||
| + | |||
| + | Tra i ''Servizi di INVIO DATI'' rientra anche il WS '''SETDAILYFIRSTPASSAGESCOUNT''' che invia al server, ai fini statistici, il conteggio indistinto dei primi passaggi di tutti i biglietti di stazione e di consorzio e non obbligatoriamente il conteggio distinto dei primi passaggi categorizzati. | ||
| + | |||
| + | Tra i ''Servizi di STRUTTURA dell’ARCHITETTURA'' ci sono i WS: | ||
| + | * '''ENUMERATEGROUPS''' che consente di ottenere l’elenco esaustivo dei codici identificativi dei gruppi noti al server | ||
| + | * '''ENUMERATECOMPANIES''' che consente di ottenere l’elenco esaustivo delle stazioni note al server appartenenti al gruppo specificato | ||
| + | * '''ENUMERATEWORKSTATIONS''' che consente di ottenere l’elenco esaustivo delle postazioni di vendita note al server appartenenti alla società specificata. | ||
| − | + | Infine ci sono i ''Servizi di SICUREZZA'' che sono: | |
| − | + | * '''REGISTERWORKSTATIONKEY''' che registra una chiave pubblica appartenente ad una postazione emittente | |
| − | + | * '''ENUMERATEKEYS''' che consente di ottenere l’elenco esaustivo delle chiavi pubbliche della postazione emittente specificata | |
| − | + | * '''GETKEY''' che consente di ottenere la chiave pubblica specificata. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | Per informazioni più dettagliate consultare la sezione: “[[Appendice_A|APPENDICE A - Servizi del Formato 3]]". | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |- | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | === | + | === Servizi del Formato 3 - Estensione dei servizi per la vendita online === |
| − | + | Nell’attuale sistema OpenPass è prevista un’evoluzione dei Servizi WEB esistenti per gestire ricarica e vendita online dei | |
| − | + | titoli di viaggio e consentire lo scambio dati tra le varie stazioni. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | Nell’attuale sistema OpenPass è prevista un’evoluzione dei Servizi WEB esistenti per gestire ricarica e vendita online dei titoli di viaggio e consentire lo scambio dati tra le varie stazioni. | ||
| − | Viene introdotto il concetto di WebCompany: azienda accreditata OpenPass che può fornire servizio di vendita per le stazioni (company). | + | Viene introdotto il concetto di ''WebCompany'': azienda accreditata OpenPass che può fornire servizio di vendita per le |
| + | stazioni (company). | ||
| − | Viene introdotto il concetto di WebShop: portale specifico di vendita titoli OpenPass per una determinata Company. Una WebCompany può avere uno o più WebShop. Ogni WebShop è legato univocamente alla propria company (stazione). Nel caso di WebShop di comprensorio, una stazione (company) dovrà farsi carico di gestire il WebShop a cui è collegato il comprensorio. | + | Viene introdotto il concetto di ''WebShop'': portale specifico di vendita titoli OpenPass per una determinata Company. |
| + | Una WebCompany può avere uno o più WebShop. Ogni WebShop è legato univocamente alla propria company | ||
| + | (stazione). Nel caso di WebShop di comprensorio, una stazione (company) dovrà farsi carico di gestire il WebShop a cui | ||
| + | è collegato il comprensorio. | ||
| − | Le stazioni (Company) devono comunicare al Server OpenPass quali sono i WebShop a loro associati. Solo dopo questa richiesta il server OpenPass assegna un identificativo unico al WebShop della WebCompany accreditata. | + | Le stazioni (Company) devono comunicare al Server OpenPass quali sono i WebShop a loro associati. Solo dopo questa |
| + | richiesta il server OpenPass assegna un identificativo unico al WebShop della WebCompany accreditata. | ||
| − | Per | + | Per fare questo sarà necessario: |
* '''Modificare i servizi Web''' esistenti del server OpenPass: | * '''Modificare i servizi Web''' esistenti del server OpenPass: | ||
{| class="wikitable" | {| class="wikitable" | ||
| − | ! Servizio !! Specifiche | + | ! Servizio !! Specifiche variazioni |
|- | |- | ||
| '''RegisterTicket''' || verrà inserito un TAG aggiuntivo <info></info> con contenuto serializzato (base64), utilizzabile dal produttore a piacere (Company di vendita). Questo campo conterrà informazioni utili al produttore dei sistemi di accesso e al fornitore del negozio internet (WebShop) | | '''RegisterTicket''' || verrà inserito un TAG aggiuntivo <info></info> con contenuto serializzato (base64), utilizzabile dal produttore a piacere (Company di vendita). Questo campo conterrà informazioni utili al produttore dei sistemi di accesso e al fornitore del negozio internet (WebShop) | ||
|- | |- | ||
| − | | '''GetTicket''' || verrà restituito un TAG aggiuntivo <info></info> contenente informazioni utili al produttore dei sistemi di accesso e al fornitore del negozio internet (WebShop) | + | | '''GetTicket''' || verrà restituito un TAG aggiuntivo <info></info> contenente informazioni utili al produttore dei sistemi di accesso e al fornitore del negozio internet (WebShop) |
|- | |- | ||
| '''RegisterCustomer''' || verranno registrate nuove informazioni relative ai customer | | '''RegisterCustomer''' || verranno registrate nuove informazioni relative ai customer | ||
|} | |} | ||
| + | |||
* '''Implementare nuovi servizi Web''' del server OpenPass: | * '''Implementare nuovi servizi Web''' del server OpenPass: | ||
{| class="wikitable" | {| class="wikitable" | ||
! Servizio !! Specifiche implementazioni | ! Servizio !! Specifiche implementazioni | ||
|- | |- | ||
| − | | '''RegisterWebSales''' || Servizio per inviare le transizioni di vendita effettuate dal un WebShop. Ogni transazione di vendita verrà identificata univocamente dal proprio seriale di vendita RegisterWebSaleID fornito dal server OpenPass. Più transazioni di vendita possono essere raggruppate da un unico OrderNumber fornito dal Webshop in fase di invio transazioni. Tra le varie informazioni inviate ci saranno: | + | | '''RegisterWebSales''' || Servizio per inviare le transizioni di vendita effettuate dal un WebShop. Ogni transazione di vendita verrà identificata univocamente dal proprio seriale di vendita RegisterWebSaleID fornito dal server OpenPass. Più transazioni di vendita possono essere raggruppate da un unico OrderNumber fornito dal Webshop in fase di invio transazioni. Tra le varie informazioni inviate ci saranno:<ul><li> ''OperationType'': (0-ritiro, 1 ricarica, 2 registrare rata di denaro, 3 storno),</li><li>''Payperuse'': (0 = no peyperuse, 1 = si payperuse),</li><li>''Insurance'': Abbinata un’assicurazione (0 = no, 1 = si),</li><li>''CardPaid'': inclusa la card nella transazione di vendita (0 = no, 1 = si)</ul> |
| − | |||
| − | |||
| − | |||
| − | |||
|- | |- | ||
| − | | ''' | + | | '''UpdateWebSalesAmmount''' || Servizio per aggiornare le vendite Web con il quantitativo economico derivato dal calcolo dell'uso |
|- | |- | ||
| '''GenerateTicket''' || Servizio con cui i fornitori dei sistemi di accesso potranno inviare al Server OpenPass i token Root.Workstation e Root.SerialNumberEx2 e la data di creazione della tessera con cui è stato generato il biglietto per ogni specifica transazione di vendita identificata con RegisterWebSaleID | | '''GenerateTicket''' || Servizio con cui i fornitori dei sistemi di accesso potranno inviare al Server OpenPass i token Root.Workstation e Root.SerialNumberEx2 e la data di creazione della tessera con cui è stato generato il biglietto per ogni specifica transazione di vendita identificata con RegisterWebSaleID | ||
|- | |- | ||
| − | | '''GetWebSales''' || Servizio con cui i fornitori dei sistemi di accesso potranno scaricare dal server OpenPass tutte le vendite Web effettuate per ogni dominio. Il servizio viene interrogato passando l’identificativo della stazione) e l'ultimo RegisterWebSaleID in possesso dalla stazione. | + | | '''GetWebSales''' || Servizio con cui i fornitori dei sistemi di accesso potranno scaricare dal server OpenPass tutte le vendite Web effettuate per ogni dominio. Il servizio viene interrogato passando l’identificativo della stazione) e l'ultimo RegisterWebSaleID in possesso dalla stazione. Il servizio restituisce le informazioni di tutte le transazioni di vendita successive al ''RegisterWebSaleID'' passato, relativi a tutti i domini a cui è associata la Company richiesta. In tali informazioni sono presenti gli OpenPassUID che identificano le tessere da ricaricare e i RegisterWebSaleID che permettono di legare le vendite WEB alle tessere ricaricate dai tornelli. |
|- | |- | ||
| − | | '''GetPassages''' || Servizio per recuperare tutti i passaggi effettuati da una tessera ricaricata a seguito di una vendita online identificata con RegisterWebSaleID e calcolare l'ammontare della vendita | + | | '''GetPassages''' || Servizio per recuperare tutti i passaggi effettuati da una tessera ricaricata a seguito di una vendita online identificata con ''RegisterWebSaleID'' e calcolare l'ammontare della vendita |
|- | |- | ||
| '''SetDailyClosing''' || Servizio per inviare al server OpenPass lo stato di chiusura di una stazione indicante che tutti i passaggi sono stati inviati al server. Tale informazione sarà utile al fornitore di WebShop in quanto potrà da quel momento calcolare gli usi delle tessere ricaricate e conseguentemente l'ammontare della vendita | | '''SetDailyClosing''' || Servizio per inviare al server OpenPass lo stato di chiusura di una stazione indicante che tutti i passaggi sono stati inviati al server. Tale informazione sarà utile al fornitore di WebShop in quanto potrà da quel momento calcolare gli usi delle tessere ricaricate e conseguentemente l'ammontare della vendita | ||
|- | |- | ||
| − | | '''GetStatusSales''' || Servizio che dato in ingresso il RegisterWebSaleID restituisce in quale company, data e ora è stato scaricato | + | | '''GetStatusSales''' || Servizio che dato in ingresso il ''RegisterWebSaleID'' restituisce in quale company, data e ora è stato scaricato |
|- | |- | ||
| − | | '''GetCustomer''' || Servizio che restituisce i dati | + | | '''GetCustomer''' || Servizio che restituisce tutti i dati relativi ad uno specifico ''Customeridentifier'' |
|- | |- | ||
| − | | '''Getcustomersstatus''' || Servizio che restituisce | + | | '''Getcustomersstatus''' || Servizio che restituisce l'ultima data di aggiornamento dei customers collegati ad un determinato dominio |
|- | |- | ||
| '''Getcustomersdomain''' || Servizio che restituisce i dati di tutti i customers aggiornati da una certa data in poi | | '''Getcustomersdomain''' || Servizio che restituisce i dati di tutti i customers aggiornati da una certa data in poi | ||
| Riga 654: | Riga 137: | ||
| '''RegisterDomain''' || Servizio che permette di associare le company ai domini | | '''RegisterDomain''' || Servizio che permette di associare le company ai domini | ||
|- | |- | ||
| − | | '''GetDomainList''' || Servizio che restituisce tutti i domini associati ad | + | | '''GetDomainList''' || Servizio che restituisce tutti i domini associati ad una company |
|} | |} | ||
| Riga 684: | Riga 167: | ||
==== Configurazione firewall ==== | ==== Configurazione firewall ==== | ||
Sia per VM-OpenPass-Master che per VM-OpenPass-Slave viene gestita la configurazione del firewall software mediante il sistema ''iptables''. | Sia per VM-OpenPass-Master che per VM-OpenPass-Slave viene gestita la configurazione del firewall software mediante il sistema ''iptables''. | ||
| + | |||
La configurazione del firewall prevede regole riportate nella seguente tabella. | La configurazione del firewall prevede regole riportate nella seguente tabella. | ||
{| class="wikitable" | {| class="wikitable" | ||
| Riga 700: | Riga 184: | ||
| SSH || Non stardard || Solo IP del gestore del server | | SSH || Non stardard || Solo IP del gestore del server | ||
|} | |} | ||
| + | |||
==== Server Web ==== | ==== Server Web ==== | ||
Sia per VM-OpenPass-Master che per VM-OpenPass-Slave viene installato il server WEB ''Apache 2'' e l’application server ''PHP 5''. | Sia per VM-OpenPass-Master che per VM-OpenPass-Slave viene installato il server WEB ''Apache 2'' e l’application server ''PHP 5''. | ||
| Riga 728: | Riga 213: | ||
==== Server Database ==== | ==== Server Database ==== | ||
| − | Sia per VM-OpenPass-Master che per VM-OpenPass-Slave viene installato il server database | + | Sia per VM-OpenPass-Master che per VM-OpenPass-Slave viene installato il server database ''MariaDB''. |
Per l’installazione del software viene utilizzato il seguente comando: | Per l’installazione del software viene utilizzato il seguente comando: | ||
| Riga 787: | Riga 272: | ||
== Comunicazione tra il server OpenPass e il nodo esterno == | == Comunicazione tra il server OpenPass e il nodo esterno == | ||
| + | Il server OPENPASS giornalmente mette a disposizione della Lombardia una parte dei dati presenti nel Server OpenPass attraverso un file system remoto (cartella condivisa via internet). | ||
| + | Le informazioni trasferite riguardano i passaggi e le anagrafiche, nel dettaglio: | ||
| + | * Checkpoint (batteria di tornelli ) | ||
| + | * Companies (stazioni sciistiche) | ||
| + | * Customer_age (fasce di età utilizzatori) | ||
| + | * Customer type (residenza utilizzatori) | ||
| + | * Dati_anagrafici (informazioni utilizzatori) | ||
| + | * Domain (Consorzi di località sciistiche) | ||
| + | * Domain_companies (relazioni consorzi – stazioni) | ||
| + | * Gestori | ||
| + | * Group (gruppi) | ||
| + | * Impianti | ||
| + | * Localita_sciistiche | ||
| + | * Ticket (biglietti) | ||
| + | * Ticket_type (tipo di biglietti) | ||
| + | * Tipi_impianti (tipo di impianti) | ||
| + | Ogni flusso dati è composto da un unico file compresso (.ZIP) contenente i file in formato CSV (comma separated values) ed il file XML per le meta-informazioni. | ||
| + | === Architettura software dei SERVIZI WEB Sistema openpass === | ||
| + | Il server OPENPASS deposita nella cartella condivisa i flussi che contengono le informazioni da trasferire (anagrafiche e passaggi). | ||
| + | Per ogni file, il nome sarà auto esplicativo e,per ogni flusso, sarà così composto: | ||
| + | “aaaammgg_tipoflusso.zip” | ||
| + | dove: | ||
| + | * “aaaa” indica l’anno di estrazione a cui si riferisce il flusso | ||
| + | * “mm” indica il mese di estrazione a cui si riferisce il flusso, in cifre, nella forma 01, 02, 03… 12 | ||
| + | * “gg” indica il giorno di estrazione a cui si riferisce il flusso, in cifre, nella forma 01, 02, 03…31 | ||
| + | * “Tipoflusso” può assumere i valori di: “anagrafiche” o “passaggi” | ||
| + | * “.zip” fisso indica l’estensione del file compresso | ||
| + | Il file compresso al suo interno potrà contenere un numero variabile di file a seconda della tipologia di flusso. | ||
| + | |||
| + | In tutti i flussi dovrà essere presente un file di metadati (infoflusso.xml) che indichi: | ||
| + | * Nome del file del flusso complessivo (equivalente al nome del file complessivo, compresa estensione) | ||
| + | * Data a cui si riferisce il flusso complessivo (informazione contenuta nel nome file) | ||
| + | * Tipologia di flusso (passaggi o anagrafiche) (informazione contenuta nel nome file) | ||
| + | * Data e ora in cui il flusso è stato estratto dal Server OPENPASS; | ||
| + | * Operatore che ha estratto i dati dall’archivio; | ||
| + | * Numero di files contenuti nel flusso (compreso il presente file di metadati); | ||
| + | * Indicazione del nome di ogni file contenuto nel flusso; | ||
| + | * Per ogni file, numero di records contenuti nel files. | ||
| + | |||
| + | Il server OPENPASS trasmetterà le informazioni concordate con la Lombardia secondo la seguente frequenza: | ||
| + | {| class="wikitable" | ||
| + | ! Flusso N° !! Descrizione !! Frequenza !! Orario | ||
| + | |- | ||
| + | | 1 || Anagrafiche || Giornaliera || 01:01 | ||
| + | |- | ||
| + | | 2 || Passaggi || Giornaliera || 02:01 | ||
| + | |} | ||
| + | |||
| + | Le anagrafiche che verranno trasferite dal server OPENPASS verso la Lombardia sono: | ||
| + | * Checkpoint (batteria di tornelli ) | ||
| + | {| class="wikitable" | ||
| + | ! Nome file !! Campi !! Collegamento ad altri file (chiave esterna) | ||
| + | |- | ||
| + | | checkpoint.csv || id_checkpoint_openpass, nome_localita, id_localita, id_impianto, nome_impianto, id_checkpoint, nome_checkpoint, id_gestore, nome_gestore || Località (id_localita), Impianti (id_impianto), Gestori (id_gestore) | ||
| + | |} | ||
| + | * Companies (stazioni sciistiche) | ||
| + | {| class="wikitable" | ||
| + | ! Nome file !! Campi !! Collegamento ad altri file (chiave esterna) | ||
| + | |- | ||
| + | | companies.csv || id_company, id_supplier, name || | ||
| + | |} | ||
| + | * Customer_age (fasce di età utilizzatori) | ||
| + | {| class="wikitable" | ||
| + | ! Nome file !! Campi !! Collegamento ad altri file (chiave esterna) | ||
| + | |- | ||
| + | | customer_age.csv || id, name, description || | ||
| + | |} | ||
| + | * Customer type (residenza utilizzatori) | ||
| + | {| class="wikitable" | ||
| + | ! Nome file !! Campi !! Collegamento ad altri file (chiave esterna) | ||
| + | |- | ||
| + | | customer_type.csv || id, name || | ||
| + | |} | ||
| + | * Dati_anagrafici (informazioni utilizzatori) | ||
| + | {| class="wikitable" | ||
| + | ! Nome file !! Campi !! Collegamento ad altri file (chiave esterna) | ||
| + | |- | ||
| + | | dati_anagrafici.csv || id_persona, anno_nascita, sesso, residenza, stato_residenza, CustomerIdentifier || | ||
| + | |} | ||
| + | * Domain (Consorzi di località sciistiche) | ||
| + | {| class="wikitable" | ||
| + | ! Nome file !! Campi !! Collegamento ad altri file (chiave esterna) | ||
| + | |- | ||
| + | | domain.csv || id_domain, id_group, name || Group (id_group) | ||
| + | |} | ||
| + | * Domain_companies (relazioni consorzi – stazioni) | ||
| + | {| class="wikitable" | ||
| + | ! Nome file !! Campi !! Collegamento ad altri file (chiave esterna) | ||
| + | |- | ||
| + | | domain_companies.csv || id_domain, id_company || Companies (id_company), Domain (id_domain) | ||
| + | |} | ||
| + | * Gestori (gestori) | ||
| + | {| class="wikitable" | ||
| + | ! Nome file !! Campi !! Collegamento ad altri file (chiave esterna) | ||
| + | |- | ||
| + | | gestori.csv || id_gestore, nome, ragione_sociale, id_localita || Localita (id_localita) | ||
| + | |} | ||
| + | * Group (gruppi) | ||
| + | {| class="wikitable" | ||
| + | ! Nome file !! Campi !! Collegamento ad altri file (chiave esterna) | ||
| + | |- | ||
| + | | group.csv || id_group, name || | ||
| + | |} | ||
| + | * Impianti | ||
| + | {| class="wikitable" | ||
| + | ! Nome file !! Campi !! Collegamento ad altri file (chiave esterna) | ||
| + | |- | ||
| + | | impianti.csv || id_impianto_openpass, nome_localita, id_impianto, nome_impianto, tipo_impianto || | ||
| + | |} | ||
| + | * Localita_sciistiche | ||
| + | {| class="wikitable" | ||
| + | ! Nome file !! Campi !! Collegamento ad altri file (chiave esterna) | ||
| + | |- | ||
| + | | localita_sciistiche.csv || id_localita, sigla_localita, descrizione || | ||
| + | |} | ||
| + | * Ticket (biglietti) | ||
| + | {| class="wikitable" | ||
| + | ! Nome file !! Campi !! Collegamento ad altri file (chiave esterna) | ||
| + | |- | ||
| + | | ticket.csv || id_ticket, description, CustomerAge, CustomerType, TicketType, id_company || Customer_age (CustomerAge), Customer_type (CustomerType), Ticket_Type (TicketType), Companies (id_company) | ||
| + | |} | ||
| + | * Ticket_type (tipo di biglietti) | ||
| + | {| class="wikitable" | ||
| + | ! Nome file !! Campi !! Collegamento ad altri file (chiave esterna) | ||
| + | |- | ||
| + | | ticket.csv || Id, description || | ||
| + | |} | ||
| + | * Tipi_impianti (tipo di impianti) | ||
| + | {| class="wikitable" | ||
| + | ! Nome file !! Campi !! Collegamento ad altri file (chiave esterna) | ||
| + | |- | ||
| + | | tipi_impianti.csv || id_tipo_impianto, sigla_impianto, descrizione || | ||
| + | |} | ||
| + | Ogni notte verranno inviati tutte le anagrafiche registrate sul server OPENPASS. | ||
| + | I passaggi che verranno trasferiti dal server OPENPASS verso la Lombardia sono: | ||
| + | * Passaggi (dati dei passaggi sui checkpoint) | ||
| + | {| class="wikitable" | ||
| + | ! Nome file !! Campi !! Collegamento ad altri file (chiave esterna) | ||
| + | |- | ||
| + | | passages.csv || id_passaggio, id_group, id_company, id_ticket, CustomerIdentifier, log_time, check_point_name, SerialNumber, time_modifica || Gruppi (id_group), Companies (id_company), Ticket (id_ticket), Dati_anagrafici (CustomerIdentifier), checkpoint (check_point_name) | ||
| + | |} | ||
| + | Ogni notte verranno inviati tutti i passaggi registrati sul server OPENPASS il giorno precedente; verranno quindi inviati solo i delta. | ||
| + | Vengono inviati i passaggi solo se esiste il checkpoint relativo. | ||
| + | Vengono inviati i passaggi solo se esiste l’impianto collegato al chekpoint relativo. | ||
| + | === Architettura hardware del sistema server === | ||
| + | L’architettura hardware è la medesima descritta nel paragrafo [[Server_OpenPass#Architettura_hardware_del_sistema_server|Architettura hardware del sistema server]]. | ||
<center>[[Il_Sistema_OpenPass|Torna a: Il Sistema OpenPass]]</center> | <center>[[Il_Sistema_OpenPass|Torna a: Il Sistema OpenPass]]</center> | ||
Versione attuale delle 08:15, 14 ott 2016
Indice
- 1 Periodicità, formato e contenuto delle informazioni Gestite nella rete OpenPass
- 2 Comunicazione tra il server openpass e i client delle stazioni
- 3 Comunicazione tra il server OpenPass e il nodo esterno
Periodicità, formato e contenuto delle informazioni Gestite nella rete OpenPass
Il Server OpenPass prevede l’invio dei dati di passaggio e vendita (ed i dati necessari al completamento dei primi due flussi come ticket e customer) da parte delle stazioni consociate ANEF Ski Lombardia in formato XML attraverso l’utilizzo di WebService. L’invio dei dati da parte dei client delle stazioni al server OpenPass può essere in real time oppure in differita tramite processi di batch a seconda del fornitore dei sistemi di accesso collegati alle stazioni.
Il Server OpenPass prevede poi un invio giornaliero costituito da un unico file compresso (.ZIP) contenente i file in formato CSV (comma separated values) ed il file XML per le meta-informazioni su una risorsa condivisa con la Lombardia; i dati trasferiti riguardano le anagrafiche ed i passaggi.
Comunicazione tra il server openpass e i client delle stazioni
Lo standard OpenPass prevede una rete distribuita di centri di raccolta dati collegati via web service al server centrale.
Le informazioni di vendita e passaggio sono raccolte ai varchi e inviate ai centri di raccolta dati, che a loro volta le trasmettono al server centrale.
Il protocollo di scambio tra server e centri di raccolta è REST, basato sul metalinguaggio XML. Il server riceve i dati e li memorizza in un database SQL centralizzato, dove ogni dato di vendita o passaggio è correlato da un codice seriale identificativo univoco e eventuali dati anagrafici del customer.
Il server gestisce a frequenza prestabilita operazioni di configurazione e di caricamento dati, attraverso chiamate XML.
Servizi del Formato 3
La comunicazione tra il server OpenPass ed i client delle stazioni avviene su protocollo HTTP mediante l’architettura software RESTful.
Per la comunicazione sono stati progettati e realizzati dei servizi organizzati in risorse web accessibili a seguito di autenticazione.
L’architettura software utilizza il paradigma client-server: i servizi attivati, in architettura RESTful, sono di seguito riportati.
Il servizio è finalizzato a ricevere i dati relativi ai passaggi e alle vendite dei biglietti regionali dalle stazione consociate ANEF SKI Lombardia.
I web services si possono dividere in queste macro-categorie:
- Servizi di LOGIN
- Servizi di GESTIONE del FORMATO
- Servizi di INVIO DATI
- Servizi di STRUTTURA dell'ARCHITETTURA
- Servizi di SICUREZZA
ANEF SKI Lombardia ha distribuito ad ogni stazione delle credenziali di accesso (username e password) ai web services per l’invio dei dati al server OpenPass. La company, per autenticarsi, deve chiamare i Servizi di LOGIN, in particolar modo il Web Service (d’ora in poi WS) LOGIN che consente l’autenticazione di un utente; tale autenticazione rimarrà attiva per tutta la durata della sessione di scambio dei dati.
Una volta autenticati, si devono chiamare i WS della categoria Servizi di GESTIONE del FORMATO: tali WS sono
- REGISTERTOKEN
- REGISTERFORMAT
- ENUMERATEFORMATS
- GETFORMAT.
REGISTERTOKEN consente di registrare un token personalizzato. I tokens che cominciano con ‘Root.’ richiedono l’accesso di un amministratore. Ogni token ha un tipo associato (es. numerico, data, ora etc.). Il token non dipende dalla Stazione che ne fa richiesta.
REGISTERFORMAT consente di registrare un formato di registrazione da utilizzare per la produzione e l’interpretazione di biglietti. Ritorna un codice identificativo univoco per il formato. La chiamata può essere effettuata tutte le volte che si vuole, il sistema ritornerà sempre lo stesso codice. Il codice di formato è quindi uguale per tute le stazioni che ne fanno richiesta. Lo stesso formato può essere condiviso tra più biglietti (es. Stagionale Adulti, Ridotto, FISI etc.).
ENUMERATEFORMATS restituisce l'elenco esaustivo dei codici identificativi dei formati noti al server.
GETFORMAT restituisce la definizione del formato di cui è stato specificato il codice identificativo in fase di chiamata.
Una volta che sono stati chiamati i Servizi di GESTIONE del FORMATO si possono utilizzare i Servizi di INVIO DATI, in particolar modo quei servizi dedicati alla GESTIONE della VENDITA: fanno parte di questa categoria i WS
- REGISTERTICKET
- ENUMERATETICKETS
- GETTICKET
- REGISTERCUSTOMER
- REGISTERSALES
Il WS REGISTERTICKET consente di registrare un set di valori di tokens costanti per una certa categoria di biglietti al fine di poterla identificare con rapidità nelle elaborazioni dati. (Es. Stagionale adulti, Stagionale ridotto). Ritorna un codice identificativo univoco per il biglietto che è identico al valore passato per il token “TicketID” obbligatorio. La chiamata può essere effettuata tutte le volte che si vuole; a parità di valori il sistema ritornerà sempre lo stesso codice. La chiamata consente una registrazione diversa per ogni Stazione, ma il codice numerico ritornato sarà a parità di set di valori lo stesso su più stazioni. Due biglietti uguali non possono né devono avere codici identificativi differenti.
Il WS ENUMERATETICKETS ottiene l’elenco esaustivo dei codici identificativi dei biglietti noti al server per la stazione specificata in fase di chiamata.
Il WS GETTICKET ottiene la definizione del biglietto di cui si è specificato il codice identificativo in fase di chiamata.
Il WS REGISTERCUSTOMER permette la registrazione di un cliente sul sistema , restituendo al chiamante un codice numerico identificativo del customer.
Il WS REGISTERSALES registra un insieme di vendite di biglietti di consorzio in formato comune sul server per il gruppo, la società e le postazioni specificate. Ogni chiamata può contenere una o più registrazioni di vendita. Ogni vendita è associata ad un cliente, il cui codice identificativo va ottenuto con l'invocazione del servizio REGISTERCUSTOMER. Il CustomerIdentifier è a 0 per i biglietti non nominativi. All’interno di ogni vendita, unitamente al ticket identifier (che specifica i valori costanti), vengono specificati i valori rilevanti dei tokens ‘dinamici’, ovvero quelli assegnati al momento dell’edizione di un biglietto.
All’interno dei Servizi di INVIO DATI ci sono anche i servizi dedicati alla GESTIONE dei PASSAGGI: il WS REGISTERPASSAGES registra un insieme di passaggi agli impianti di biglietti di consorzio in formato comune sul server per il gruppo, la società e gli impianti specificati. Ogni chiamata può contenere una o più registrazioni di passaggio. Ogni passaggio è opzionalmente associato ad un cliente, il cui codice identificativo va ottenuto con l'invocazione del servizio REGISTERCUSTOMER. Ricordiamo che il CustomerIdentifier è a 0 per i biglietti non nominativi. All’interno di ogni passaggio, unitamente al ticket identifier (che specifica i valori costanti), vengono specificati i valori rilevanti dei tokens ‘dinamici’, ovvero quelli assegnati al momento dell’edizione di un biglietto e che si modificano durante l’utilizzo.
Tra i Servizi di INVIO DATI rientra anche il WS SETDAILYFIRSTPASSAGESCOUNT che invia al server, ai fini statistici, il conteggio indistinto dei primi passaggi di tutti i biglietti di stazione e di consorzio e non obbligatoriamente il conteggio distinto dei primi passaggi categorizzati.
Tra i Servizi di STRUTTURA dell’ARCHITETTURA ci sono i WS:
- ENUMERATEGROUPS che consente di ottenere l’elenco esaustivo dei codici identificativi dei gruppi noti al server
- ENUMERATECOMPANIES che consente di ottenere l’elenco esaustivo delle stazioni note al server appartenenti al gruppo specificato
- ENUMERATEWORKSTATIONS che consente di ottenere l’elenco esaustivo delle postazioni di vendita note al server appartenenti alla società specificata.
Infine ci sono i Servizi di SICUREZZA che sono:
- REGISTERWORKSTATIONKEY che registra una chiave pubblica appartenente ad una postazione emittente
- ENUMERATEKEYS che consente di ottenere l’elenco esaustivo delle chiavi pubbliche della postazione emittente specificata
- GETKEY che consente di ottenere la chiave pubblica specificata.
Per informazioni più dettagliate consultare la sezione: “APPENDICE A - Servizi del Formato 3".
Servizi del Formato 3 - Estensione dei servizi per la vendita online
Nell’attuale sistema OpenPass è prevista un’evoluzione dei Servizi WEB esistenti per gestire ricarica e vendita online dei titoli di viaggio e consentire lo scambio dati tra le varie stazioni.
Viene introdotto il concetto di WebCompany: azienda accreditata OpenPass che può fornire servizio di vendita per le stazioni (company).
Viene introdotto il concetto di WebShop: portale specifico di vendita titoli OpenPass per una determinata Company. Una WebCompany può avere uno o più WebShop. Ogni WebShop è legato univocamente alla propria company (stazione). Nel caso di WebShop di comprensorio, una stazione (company) dovrà farsi carico di gestire il WebShop a cui è collegato il comprensorio.
Le stazioni (Company) devono comunicare al Server OpenPass quali sono i WebShop a loro associati. Solo dopo questa richiesta il server OpenPass assegna un identificativo unico al WebShop della WebCompany accreditata.
Per fare questo sarà necessario:
- Modificare i servizi Web esistenti del server OpenPass:
| Servizio | Specifiche variazioni |
|---|---|
| RegisterTicket | verrà inserito un TAG aggiuntivo <info></info> con contenuto serializzato (base64), utilizzabile dal produttore a piacere (Company di vendita). Questo campo conterrà informazioni utili al produttore dei sistemi di accesso e al fornitore del negozio internet (WebShop) |
| GetTicket | verrà restituito un TAG aggiuntivo <info></info> contenente informazioni utili al produttore dei sistemi di accesso e al fornitore del negozio internet (WebShop) |
| RegisterCustomer | verranno registrate nuove informazioni relative ai customer |
- Implementare nuovi servizi Web del server OpenPass:
| Servizio | Specifiche implementazioni |
|---|---|
| RegisterWebSales | Servizio per inviare le transizioni di vendita effettuate dal un WebShop. Ogni transazione di vendita verrà identificata univocamente dal proprio seriale di vendita RegisterWebSaleID fornito dal server OpenPass. Più transazioni di vendita possono essere raggruppate da un unico OrderNumber fornito dal Webshop in fase di invio transazioni. Tra le varie informazioni inviate ci saranno:
|
| UpdateWebSalesAmmount | Servizio per aggiornare le vendite Web con il quantitativo economico derivato dal calcolo dell'uso |
| GenerateTicket | Servizio con cui i fornitori dei sistemi di accesso potranno inviare al Server OpenPass i token Root.Workstation e Root.SerialNumberEx2 e la data di creazione della tessera con cui è stato generato il biglietto per ogni specifica transazione di vendita identificata con RegisterWebSaleID |
| GetWebSales | Servizio con cui i fornitori dei sistemi di accesso potranno scaricare dal server OpenPass tutte le vendite Web effettuate per ogni dominio. Il servizio viene interrogato passando l’identificativo della stazione) e l'ultimo RegisterWebSaleID in possesso dalla stazione. Il servizio restituisce le informazioni di tutte le transazioni di vendita successive al RegisterWebSaleID passato, relativi a tutti i domini a cui è associata la Company richiesta. In tali informazioni sono presenti gli OpenPassUID che identificano le tessere da ricaricare e i RegisterWebSaleID che permettono di legare le vendite WEB alle tessere ricaricate dai tornelli. |
| GetPassages | Servizio per recuperare tutti i passaggi effettuati da una tessera ricaricata a seguito di una vendita online identificata con RegisterWebSaleID e calcolare l'ammontare della vendita |
| SetDailyClosing | Servizio per inviare al server OpenPass lo stato di chiusura di una stazione indicante che tutti i passaggi sono stati inviati al server. Tale informazione sarà utile al fornitore di WebShop in quanto potrà da quel momento calcolare gli usi delle tessere ricaricate e conseguentemente l'ammontare della vendita |
| GetStatusSales | Servizio che dato in ingresso il RegisterWebSaleID restituisce in quale company, data e ora è stato scaricato |
| GetCustomer | Servizio che restituisce tutti i dati relativi ad uno specifico Customeridentifier |
| Getcustomersstatus | Servizio che restituisce l'ultima data di aggiornamento dei customers collegati ad un determinato dominio |
| Getcustomersdomain | Servizio che restituisce i dati di tutti i customers aggiornati da una certa data in poi |
| CreateDomain | Servizio che consente di creare nuovi domini |
| RegisterDomain | Servizio che permette di associare le company ai domini |
| GetDomainList | Servizio che restituisce tutti i domini associati ad una company |
Architettura hardware del sistema server
L’infrastruttura tecnologia a supporto del sistema OpenPass si compone delle componenti riportate nella tabella sottostante.
| Tipo | Nome | Posizione | Virtualizzazione |
|---|---|---|---|
| Virtual Machine | VM-OpenPass-Master | Roubaix | VmWare ESXi 5.5.0. |
| Virtual Machine | VM-OpenPass-Slave | Strasburgo | VmWare ESXi 5.5.0. |
Accesso SSH
Sia per VM-OpenPass-Master che per VM-OpenPass-Slave viene installato il server openssh; l’istruzione che permette l’installazione del server openssh è la seguente:
apt-get install openssh-server
L'accesso tramite protocollo SSH viene personalizzato in questo modo:
- modifica della porta standard;
- disabilitazione accesso da parte dell'utente root;
- gestione di una lista restrittiva di utenti abilitati all'accesso.
Le modifiche sono riportate nel file di configurazione /etc/ssh/sshd_config.
Eseguita la modifica al file di configurazione il server viene riavviato dal seguente comando:
service ssh restart
Configurazione firewall
Sia per VM-OpenPass-Master che per VM-OpenPass-Slave viene gestita la configurazione del firewall software mediante il sistema iptables.
La configurazione del firewall prevede regole riportate nella seguente tabella.
| Servizio | Porta | Sorgente |
|---|---|---|
| Gestione del server webmin | Non stardard | Solo IP del gestore del server |
| Server database | Stardard | Solo da VM-OpenPass-Master per VM-OpenPass-Slave e viceversa solo da VM-OpenPass-Slave per VM-OpenPass-Master |
| Ping | Stardard | Solo IP del gestore del server |
| HTTP | Stardard | Ovunque |
| HTTPS | Stardard | Ovunque |
| SSH | Non stardard | Solo IP del gestore del server |
Server Web
Sia per VM-OpenPass-Master che per VM-OpenPass-Slave viene installato il server WEB Apache 2 e l’application server PHP 5.
Per l’installazione del software viene utilizzato il seguente comando:
apt-get install apache2 pp5 php5-mysql
Il comando, oltre ad installare il server WEB e l’application server, si occupa dell’installazione del PDO di interfaccia con il database server.
Gestione Server - WEBMIN
Sia per VM-OpenPass-Master che per VM-OpenPass-Slave viene installato il software di gestione Webmin.
Per l’installazione del software vengono utilizzati i seguenti comandi:
| deb http://download.webmin.com/download/repository sarge contrib deb http://webmin.mirror.somersettechsolutions.co.uk/repository sarge contrib |
A seguito dell’installazione, dal pannello di controllo di Webmin, viene modificata la porta standard di accesso dell’applicativo.
Server Database
Sia per VM-OpenPass-Master che per VM-OpenPass-Slave viene installato il server database MariaDB.
Per l’installazione del software viene utilizzato il seguente comando:
apt-get install mariadb-server mariadb-client
A fini prestazionali viene personalizzato il file di configurazione /etc/mysql/my.cnf.
A seguito della personalizzazione viene riavviato il server database tramite il comando
service mysql restart
VM-OpenPass-Slave si comporta da slave database nei confronti di VM-OpenPass-Master: ogni tupla inserita, modificata o eliminata all’interno del server database VM-OpenPass-Master viene replicata nel server database VM-OpenPass-Slave.
Al fine della replicazione viene creato un utente slave_user sul server database di VM-OpenPass-Master tramite il comando:
GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY '**********'; FLUSH PRIVILEGES;
Sempre sul server database VM-OpenPass-Master viene letto il valore di MASTER_LOG_FILE e MASTER_LOG_POS con il seguente comando:
SHOW MASTER STATUS;
Infine sul server database VM-OpenPass-Slave viene fatta partire la replicazione con il seguente comando (sostituendo i valori MASTER_LOG_FILE_VALUE e MASTER_LOG_POS_VALUE con quelli ricavati dalla lettura del VM-OpenPass-Master):
CHANGE MASTER TO MASTER_HOST='xxx.xxx.xxx.xxx', MASTER_USER='slave_user', MASTER_PASSWORD='**********', MASTER_LOG_FILE='MASTER_LOG_FILE_VALUE', MASTER_LOG_POS=MASTER_LOG_POS_VALUE;
Sorgenti del progetto
Le caratteristiche del codice sorgente del progetto sono riportate nella seguente tabella.
| Linguaggio | PHP 5 |
| Framework | Zend Framework |
| Posizione | /var/www/openpass |
Servizio di monitoring
Viene realizzato e schedulato uno script che permette di controllare periodicamente lo stato della replicazione di VM-OpenPass-Slave. Lo stato di replicazione viene derivato dall’analisi del comando:
SHOW MASTER STATUS;
L’analisi viene effettuata ogni 5 minuti.
Sia per VM-OpenPass-Master che per VM-OpenPass-Slave viene realizzato e schedulato uno script che permette di controllare lo spazio su disco residuo. Il controllo dello spazio residuo viene effettuato ogni ora; vengono inviati alert all’amministratore di sistema nel caso in cui lo spazio utilizzato superi il 90% dello spazio totale del disco.
Backup
Sono implementati i servizi di backup della componente database riportati nella seguente tabella.
| Tipo | Periodicità |
|---|---|
| Backup completo | 1 volta al giorno |
| Backup incrementale | 1 volta all'ora |
Comunicazione tra il server OpenPass e il nodo esterno
Il server OPENPASS giornalmente mette a disposizione della Lombardia una parte dei dati presenti nel Server OpenPass attraverso un file system remoto (cartella condivisa via internet).
Le informazioni trasferite riguardano i passaggi e le anagrafiche, nel dettaglio:
- Checkpoint (batteria di tornelli )
- Companies (stazioni sciistiche)
- Customer_age (fasce di età utilizzatori)
- Customer type (residenza utilizzatori)
- Dati_anagrafici (informazioni utilizzatori)
- Domain (Consorzi di località sciistiche)
- Domain_companies (relazioni consorzi – stazioni)
- Gestori
- Group (gruppi)
- Impianti
- Localita_sciistiche
- Ticket (biglietti)
- Ticket_type (tipo di biglietti)
- Tipi_impianti (tipo di impianti)
Ogni flusso dati è composto da un unico file compresso (.ZIP) contenente i file in formato CSV (comma separated values) ed il file XML per le meta-informazioni.
Architettura software dei SERVIZI WEB Sistema openpass
Il server OPENPASS deposita nella cartella condivisa i flussi che contengono le informazioni da trasferire (anagrafiche e passaggi).
Per ogni file, il nome sarà auto esplicativo e,per ogni flusso, sarà così composto:
“aaaammgg_tipoflusso.zip”
dove:
- “aaaa” indica l’anno di estrazione a cui si riferisce il flusso
- “mm” indica il mese di estrazione a cui si riferisce il flusso, in cifre, nella forma 01, 02, 03… 12
- “gg” indica il giorno di estrazione a cui si riferisce il flusso, in cifre, nella forma 01, 02, 03…31
- “Tipoflusso” può assumere i valori di: “anagrafiche” o “passaggi”
- “.zip” fisso indica l’estensione del file compresso
Il file compresso al suo interno potrà contenere un numero variabile di file a seconda della tipologia di flusso.
In tutti i flussi dovrà essere presente un file di metadati (infoflusso.xml) che indichi:
- Nome del file del flusso complessivo (equivalente al nome del file complessivo, compresa estensione)
- Data a cui si riferisce il flusso complessivo (informazione contenuta nel nome file)
- Tipologia di flusso (passaggi o anagrafiche) (informazione contenuta nel nome file)
- Data e ora in cui il flusso è stato estratto dal Server OPENPASS;
- Operatore che ha estratto i dati dall’archivio;
- Numero di files contenuti nel flusso (compreso il presente file di metadati);
- Indicazione del nome di ogni file contenuto nel flusso;
- Per ogni file, numero di records contenuti nel files.
Il server OPENPASS trasmetterà le informazioni concordate con la Lombardia secondo la seguente frequenza:
| Flusso N° | Descrizione | Frequenza | Orario |
|---|---|---|---|
| 1 | Anagrafiche | Giornaliera | 01:01 |
| 2 | Passaggi | Giornaliera | 02:01 |
Le anagrafiche che verranno trasferite dal server OPENPASS verso la Lombardia sono:
- Checkpoint (batteria di tornelli )
| Nome file | Campi | Collegamento ad altri file (chiave esterna) |
|---|---|---|
| checkpoint.csv | id_checkpoint_openpass, nome_localita, id_localita, id_impianto, nome_impianto, id_checkpoint, nome_checkpoint, id_gestore, nome_gestore | Località (id_localita), Impianti (id_impianto), Gestori (id_gestore) |
- Companies (stazioni sciistiche)
| Nome file | Campi | Collegamento ad altri file (chiave esterna) |
|---|---|---|
| companies.csv | id_company, id_supplier, name |
- Customer_age (fasce di età utilizzatori)
| Nome file | Campi | Collegamento ad altri file (chiave esterna) |
|---|---|---|
| customer_age.csv | id, name, description |
- Customer type (residenza utilizzatori)
| Nome file | Campi | Collegamento ad altri file (chiave esterna) |
|---|---|---|
| customer_type.csv | id, name |
- Dati_anagrafici (informazioni utilizzatori)
| Nome file | Campi | Collegamento ad altri file (chiave esterna) |
|---|---|---|
| dati_anagrafici.csv | id_persona, anno_nascita, sesso, residenza, stato_residenza, CustomerIdentifier |
- Domain (Consorzi di località sciistiche)
| Nome file | Campi | Collegamento ad altri file (chiave esterna) |
|---|---|---|
| domain.csv | id_domain, id_group, name | Group (id_group) |
- Domain_companies (relazioni consorzi – stazioni)
| Nome file | Campi | Collegamento ad altri file (chiave esterna) |
|---|---|---|
| domain_companies.csv | id_domain, id_company | Companies (id_company), Domain (id_domain) |
- Gestori (gestori)
| Nome file | Campi | Collegamento ad altri file (chiave esterna) |
|---|---|---|
| gestori.csv | id_gestore, nome, ragione_sociale, id_localita | Localita (id_localita) |
- Group (gruppi)
| Nome file | Campi | Collegamento ad altri file (chiave esterna) |
|---|---|---|
| group.csv | id_group, name |
- Impianti
| Nome file | Campi | Collegamento ad altri file (chiave esterna) |
|---|---|---|
| impianti.csv | id_impianto_openpass, nome_localita, id_impianto, nome_impianto, tipo_impianto |
- Localita_sciistiche
| Nome file | Campi | Collegamento ad altri file (chiave esterna) |
|---|---|---|
| localita_sciistiche.csv | id_localita, sigla_localita, descrizione |
- Ticket (biglietti)
| Nome file | Campi | Collegamento ad altri file (chiave esterna) |
|---|---|---|
| ticket.csv | id_ticket, description, CustomerAge, CustomerType, TicketType, id_company | Customer_age (CustomerAge), Customer_type (CustomerType), Ticket_Type (TicketType), Companies (id_company) |
- Ticket_type (tipo di biglietti)
| Nome file | Campi | Collegamento ad altri file (chiave esterna) |
|---|---|---|
| ticket.csv | Id, description |
- Tipi_impianti (tipo di impianti)
| Nome file | Campi | Collegamento ad altri file (chiave esterna) |
|---|---|---|
| tipi_impianti.csv | id_tipo_impianto, sigla_impianto, descrizione |
Ogni notte verranno inviati tutte le anagrafiche registrate sul server OPENPASS.
I passaggi che verranno trasferiti dal server OPENPASS verso la Lombardia sono:
- Passaggi (dati dei passaggi sui checkpoint)
| Nome file | Campi | Collegamento ad altri file (chiave esterna) |
|---|---|---|
| passages.csv | id_passaggio, id_group, id_company, id_ticket, CustomerIdentifier, log_time, check_point_name, SerialNumber, time_modifica | Gruppi (id_group), Companies (id_company), Ticket (id_ticket), Dati_anagrafici (CustomerIdentifier), checkpoint (check_point_name) |
Ogni notte verranno inviati tutti i passaggi registrati sul server OPENPASS il giorno precedente; verranno quindi inviati solo i delta.
Vengono inviati i passaggi solo se esiste il checkpoint relativo.
Vengono inviati i passaggi solo se esiste l’impianto collegato al chekpoint relativo.
Architettura hardware del sistema server
L’architettura hardware è la medesima descritta nel paragrafo Architettura hardware del sistema server.