Differenze tra le versioni di "Server OpenPass"

Da Libro Bianco OpenPass.
[versione verificata][versione di qualità]
(Configurazione firewall)
(Architettura software dei SERVIZI WEB Sistema openpass)
 
(3 versioni intermedie di uno stesso utente non sono mostrate)
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|frame|center|link=|Comunicazione tra il server OpenPass e i client delle Stazioni]]
+
[[File:Comunicazione_openpass.png|thumb|800px|center|link=|Comunicazione tra il server OpenPass e i client delle Stazioni]]
  
 
=== Servizi del Formato 3 ===
 
=== Servizi del Formato 3 ===
Riga 213: Riga 213:
  
 
==== Server Database ====
 
==== Server Database ====
Sia per  VM-OpenPass-Master che per VM-OpenPass-Slave viene installato il server database '''MariaDB'''.
+
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 293: Riga 293:
  
 
=== Architettura software dei SERVIZI WEB Sistema openpass ===
 
=== Architettura software dei SERVIZI WEB Sistema openpass ===
Il server OPENPASS deposita nella cartella condivisa in questa cartella i flussi che contengono le informazioni da trasferire (anagrafiche e passaggi).
+
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:
 
Per ogni file, il nome sarà auto esplicativo e,per ogni flusso, sarà così composto:
Riga 347: Riga 347:
 
|}
 
|}
 
* Customer type (residenza utilizzatori)
 
* 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"
 
{| class="wikitable"
 
! Nome file !! Campi !! Collegamento ad altri file (chiave esterna)
 
! Nome file !! Campi !! Collegamento ad altri file (chiave esterna)

Versione attuale delle 08:15, 14 ott 2016

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.

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.

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:
  • OperationType: (0-ritiro, 1 ricarica, 2 registrare rata di denaro, 3 storno),
  • Payperuse: (0 = no peyperuse, 1 = si payperuse),
  • Insurance: Abbinata un’assicurazione (0 = no, 1 = si),
  • CardPaid: inclusa la card nella transazione di vendita (0 = no, 1 = si)
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
cd /root
wget http://www.webmin.com/jcameron-key.asc
apt-key add jcameron-key.asc
rm jcameron-key.asc
apt-get update
apt-get install webmin

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.


Torna a: Il Sistema OpenPass