diff --git a/Specifiche.md b/Specifiche.md index ee093e6..bca5f80 100644 --- a/Specifiche.md +++ b/Specifiche.md @@ -347,18 +347,13 @@ Riepilogo valori nell'albero REDIS legati ai canali di comunicazione con il clou | ------ | ------------------------------------------- | -------- | -------------------------------------------------------------------------------------- | | SERVER | SOUR:MConnect | {folder} | Folder che contiene i canali di comunicazione IN/OUT tra HMI e MaestroConnect | | SERVER | SOUR:MConnect:ChannelsIN | {folder} | Folder che contiene i canali IN INGRESSO (Maestro Connect --> HMI) | -| SERVER | SOUR:MConnect:ChannelsIN:DataError | {folder} | Folder che contiene l'elenco degli errori segnalati | -| SERVER | SOUR:MConnect:ChannelsIN:DataError:20181105 | HashList | Tabella errori | +| SERVER | SOUR:MConnect:ChannelsIN:DataError:20181105 | HashList | Tabella che contiene l'elenco degli errori segnalati | | SERVER | SOUR:MConnect:ChannelsIN:AlertHMI | {folder} | Folder che contiene l'elenco degli alert (generati dal cloud) che HMI deve preesentare | -| SERVER | SOUR:MConnect:ChannelsIN:DataReq | {folder} | Folder che contiene l'elenco delle richieste di file export verso cloud | -| SERVER | SOUR:MConnect:ChannelsIN:DataReq:20181104 | HashList | Tabella richiesta produzione files | -| SERVER | SOUR:MConnect:ChannelsIN:LogReq | {folder} | Folder che contiene l'elenco degli eventi di notifica verso HMI | -| SERVER | SOUR:MConnect:ChannelsIN:LogReq:20181106 | HashList | Tabella interventi manutenzione | +| SERVER | SOUR:MConnect:ChannelsIN:DataReq | HashList | Tabella richiesta produzione files export verso cloud | +| SERVER | SOUR:MConnect:ChannelsIN:LogReq | HashList | Tabella che contiene l'elenco degli eventi di notifica verso HMI | | SERVER | SOUR:MConnect:ChannelsOUT | {folder} | Folder che contiene i canali IN USCITA (HMI --> Maestro Connect) | -| SERVER | SOUR:MConnect:ChannelsOUT:DataReq | {folder} | Folder che contiene l'elenco dei task di file export eseguiti verso cloud | -| SERVER | SOUR:MConnect:ChannelsIN:DataReq:20181104 | HashList | Tabella files prodotti corrispondenti a richieste | -| SERVER | SOUR:MConnect:ChannelsOUT:LogReq | {folder} | Folder che contiene l'elenco dei log prodotti su richiesta | -| SERVER | SOUR:MConnect:ChannelsOUT:LogReq:20181104 | HashList | Tabella log prodotti su richiesta | +| SERVER | SOUR:MConnect:ChannelsIN:DataReq | HashList | Tabella files prodotti corrispondenti a richieste | +| SERVER | SOUR:MConnect:ChannelsOUT:LogReq | HashList | Tabella log prodotti su richiesta |
@@ -370,7 +365,6 @@ In particolare definisce gli aspetti necessari a garantire la realizzazione del 1. Nuova prestazione di **notifica da parte del cloud di Maestro Connect** di informazioni verso le HMI 2.0 - MaestroConnect può inviare notifiche a HMI 2.0, come ad esempio "Allerta l’operatore HMI 2.0 con opportuna segnalazione visuale per consultare MaestroConnect riguardo l’avvenuta scadenza di un’azione di Manutenzione Ordinaria" 2. Nuova prestazione di **richiesta da MaestroConnect a HMI per eseguire un task** (ad es. produrre un file BackupExpress, file di log eventi HMI, etc). Questa prestazione sarà utilizzata dai ServiceHotliners che potranno così generare e prelevare file di log dalla macchina con comandi "quasi real-time" remoti -3. Nuova prestazione per la **gestione utenti** di MaestroConnect ### Aspetti tecnici salienti @@ -396,7 +390,7 @@ In particolare si ipotizza di impiegare un canale diretto e privilegiato [B] di Si ipotizza di impiegare un’area REDIS per poter svolgere il compito di trasferire informazioni speciali a due vie tra Maestro Connect e HMI 2.0 secondo le modalità di seguito descritte, e con riferimento a questo esempio di partizionamento del DB REDIS: -![RedisDB](images/SchemaRedisDB.png) +![RedisDB](images/SchemaRedisDB3.png) - Un’area principale **MConnect** come "contenitore logico" dell funzionalità per la connessione diretta, così organizzato: - **MConnect** @@ -436,7 +430,7 @@ Ad esempio nella schermata riportata di seguito si rappresentano due errori rile Esempio: -![DataReq](images/DataErr.png) +![DataReq](images/DataErr2.png)
@@ -444,7 +438,7 @@ Esempio: Nel canale **AlertHMI** saranno salvate le richieste di notifica inerenti gli eventi di manutenzione di ogni natura/tipologia, secondo le seguenti regole: -- una HashTable giornaliera (che verrà eventualmente eliminata dal gateway/cloud tramite cancellazione/TTL) +- una HashTable **globale** (che verrà ripulita dal gateway/cloud tramite cancellazione puntuale) - in ogni HashTable è organizzata in formato Key/Value - ogni riga ha una chiave UNIVOCA generata dal cloud/gateway - ogni riga è una notifica indipendente dal resto di un intervento in area Manutenzione @@ -454,14 +448,14 @@ Nel canale **AlertHMI** saranno salvate le richieste di notifica inerenti gli ev - HMI 2.0 potrà leggere tutte le righe ed eventualmente raggruppare le richieste per tipologia a livello di interfaccia - L'utente sarà guidato a cliccare sui link per andare su MaestroConnect -In particoalre per le 2 tipologie di notifiche ad ora implementate: +In particolare per le 2 tipologie di notifiche ad ora implementate: - valore "TroubleShooting" - HMI notifica al suo operatore bordo macchina con un colore opportuno un msg, o icona, o qualsivoglia per segnalare "c'è uno o più allarmi da gestire, consulta MaestroConnect" - valore "Maintenance" - HMI notifica al suo operatore bordo macchina con un colore opportuno diverso dal precedente, per segnalare "c'è una o più azioni di manutenzione ordinaria da eseguire" gli UT decidono poi come gestire un "Cancel" della segnalazione, che ha il solo scopo di "eliminare temporaneamente" la notifica stessa. MaestroConnect cancellerà la URL di notifica SOLO quando un utente autorizzato dichiarerà EFFETTUATA l'azione suggerita per il TroubleShooting o per la Manutenzione La URL inviata da MaestroConnect al momento non genera altre info Esempio -![DataReq](images/AlertHMI.png) +![DataReq](images/AlertHMI2.png) In questo caso riportato abbiamo @@ -476,7 +470,7 @@ Sarà compito del cloud eliminare tutte le righe di richiesta cessate le cause d Nel canale **DataReq** saranno salvate le richieste di dati, secondo le seguenti regole: -- una HashTable giornaliera (che verrà eventualmente eliminata dal gateway/cloud tramite cancellazione/TTL, tipicamente TTL=30gg) +- una HashTable **globale** (che verrà ripulita dal gateway/cloud tramite cancellazione puntuale) - in ogni HashTable è organizzata in formato Key/Value - ogni riga ha una chiave UNIVOCA generata dal cloud/gateway come key - ogni riga è un TASK da eseguire @@ -489,7 +483,7 @@ Nel canale **DataReq** saranno salvate le richieste di dati, secondo le seguenti Esempio: -![DataReqIN](images/DataReqIN.png) +![DataReqIN](images/DataReqIN2.png)
@@ -497,7 +491,7 @@ Esempio: Nel canale **LogReq** saranno inviate le richieste di salvataggio dei log secondo le seguenti regole: -- una HashTable giornaliera (che verrà eventualmente eliminata dal gateway/cloud tramite cancellazione/TTL, tipicamente TTL=30gg) +- una HashTable **globale** (che verrà ripulita dal gateway/cloud tramite cancellazione puntuale) - in ogni HashTable è organizzata in formato Key/Value - ogni riga ha una chiave UNIVOCA generata dal cloud/gateway come key - ogni riga è un TASK da eseguire @@ -511,7 +505,7 @@ Nel canale **LogReq** saranno inviate le richieste di salvataggio dei log second Esempio: -![DataReqIN](images/LogReqIN.png) +![DataReqIN](images/LogReqIN2.png) Come si vede sono stati registrati 3 richieste: @@ -526,11 +520,16 @@ Come si vede sono stati registrati 3 richieste: ### **ChannelsOUT**: notifica verso Cloud di avvenuta esecuzione di richieste -HMI 2.0 utilizza un ulteriore folder "esterno", allocato su gateway, e dedicato ai file prodotti da HMI 2.0. Il file - con opportuno naming - viene processato da MaestroConnect e di conseguenza eliminato una volta caricato. +HMI 2.0 utilizza **una apposita procedura di upload tramite SDK**, tramite la qule i file prodotti da HMI 2.0 sono inviati sul cloud. -Per agevolare il processo e rendere maggiormente controllata l'esecuzione, si chiede la notifica dei task file-based su apposita area REDIS. +La procedura è descritta in maggior dettaglio nella documentazione dedicata all'SDK stesso, ma in termini denerali si tratta di invocare l'SDK come di seguito descritto: -Ogni file prodotto è una risposta ad un evento ricevuto tramite ChannelsIN (es: Backupexpress). +* Chiamata a **TryUpLoadFile** +* Invio di un cancellation token e di un oggetto Progress di tipo Result +* Invio del path completo del file da caricare +* inzio opzionale del nome del file (se si volesse cambiare il nome del file rispetto a qeullo presente sul filesystem, ad esempio per usare un nome standard) + +Per agevolare il processo e rendere maggiormente controllata l'esecuzione, si chiede la notifica dei task file-based su apposita area REDIS, copiando il risultato delal chiamata al servizio di pubblicazione direttamente nell'area REDIS di ChannelsOUT corrispondente alla richiesta in ChannelsIN, dove ogni risposta ad un file inviato è relativa ad una richiesta ricevuto tramite ChannelsIN (es: Backupexpress).
@@ -540,7 +539,7 @@ In questo caso sono riportati puntulamente i dati relativi ai richiesti e proces Esempio: -![DataReqOUT](images/DataReqOUT2.png) +![DataReqOUT](images/DataReqOUT3.png) Esempio JSon **SUCCESSO** @@ -557,6 +556,7 @@ Esempio JSon **SUCCESSO** "Message": "Upload Done!" } ``` + Esempio JSon **ERRORE** ```JSon @@ -584,7 +584,7 @@ La mancata scrittura in toto della riga indica che il task di produzione del fil Nel canale **LogReq** saranno inviate le risposte alle richieste di salvataggio dati di log secondo le seguenti regole: -- una HashTable giornaliera (che verrà eventualmente eliminata dal gateway/cloud tramite cancellazione/TTL, tipicamente TTL=30gg) +- una HashTable **globale** (che verrà ripulita dal gateway/cloud tramite cancellazione puntuale) - in ogni HashTable è organizzata in formato Key/Value - ogni riga ha una chiave UNIVOCA corrispondente alla richiesta ricevuta (e cui fare riferimento come risposta) - HMI 2.0 andrà a salvare nel canale duale (ChannelsIN:LogReq) il risultato di ogni richiesta nella forma di un record JSON serializzato corrispondende alla richiesta @@ -597,7 +597,7 @@ Nel canale **LogReq** saranno inviate le risposte alle richieste di salvataggio Esempio: -![FileLog](images/LogReqOUT.png) +![FileLog](images/LogReqOUT2.png) Di seguito sono esplicitamente riportati i campi e formati richeisti e concordati nell'incontro hangout del 2019.01.30 per le 3 tipologie di dati, eventualmente declinati secondo le necessità di ogni UTE coinvolta. diff --git a/Specifiche.pdf b/Specifiche.pdf index 8b61ceb..e1e8624 100644 Binary files a/Specifiche.pdf and b/Specifiche.pdf differ diff --git a/images/AlertHMI.png b/images/AlertHMI.png deleted file mode 100644 index dbe51ce..0000000 Binary files a/images/AlertHMI.png and /dev/null differ diff --git a/images/AlertHMI2.png b/images/AlertHMI2.png new file mode 100644 index 0000000..c6b71e4 Binary files /dev/null and b/images/AlertHMI2.png differ diff --git a/images/DataErr.png b/images/DataErr.png deleted file mode 100644 index cf4227f..0000000 Binary files a/images/DataErr.png and /dev/null differ diff --git a/images/DataErr2.png b/images/DataErr2.png new file mode 100644 index 0000000..2d56685 Binary files /dev/null and b/images/DataErr2.png differ diff --git a/images/DataReqIN.png b/images/DataReqIN.png deleted file mode 100644 index dc6783b..0000000 Binary files a/images/DataReqIN.png and /dev/null differ diff --git a/images/DataReqIN2.png b/images/DataReqIN2.png new file mode 100644 index 0000000..0b926ae Binary files /dev/null and b/images/DataReqIN2.png differ diff --git a/images/DataReqOUT2.png b/images/DataReqOUT2.png deleted file mode 100644 index aaf0104..0000000 Binary files a/images/DataReqOUT2.png and /dev/null differ diff --git a/images/DataReqOUT3.png b/images/DataReqOUT3.png new file mode 100644 index 0000000..eac94c7 Binary files /dev/null and b/images/DataReqOUT3.png differ diff --git a/images/LogReqIN.png b/images/LogReqIN.png deleted file mode 100644 index 351ca2e..0000000 Binary files a/images/LogReqIN.png and /dev/null differ diff --git a/images/LogReqIN2.png b/images/LogReqIN2.png new file mode 100644 index 0000000..ca1a3c5 Binary files /dev/null and b/images/LogReqIN2.png differ diff --git a/images/LogReqOUT.png b/images/LogReqOUT.png deleted file mode 100644 index e1755b3..0000000 Binary files a/images/LogReqOUT.png and /dev/null differ diff --git a/images/LogReqOUT2.png b/images/LogReqOUT2.png new file mode 100644 index 0000000..d12d6bc Binary files /dev/null and b/images/LogReqOUT2.png differ diff --git a/images/SchemaRedisDB.png b/images/SchemaRedisDB.png deleted file mode 100644 index a687dfe..0000000 Binary files a/images/SchemaRedisDB.png and /dev/null differ diff --git a/images/SchemaRedisDB3.png b/images/SchemaRedisDB3.png new file mode 100644 index 0000000..cb59a95 Binary files /dev/null and b/images/SchemaRedisDB3.png differ