Skip to content

Home

Jump to bottom
Tito Brasolin edited this page Jul 13, 2021 · 3 revisions

Applicazione pilota TriggerAction - Invio dati ad ENEA

Glossario

Termine Definizione
TBD To Be Defined (Da definire)
SCP Smart City Platform
UD UrbanDataset
DTO Data Transfer Object

Scopo del documento

Lo scopo di questo documento è fornire una sommaria descrizione dell'applicazione pilota TriggerAction con un accento sull'organizzazione del codice sorgente e sulla configurazione dei "job" pianificati.

Riferimenti

Progetto principale:

Principali librerie di supporto:

Premessa

Nei siti prescelti sono istallati sensori che misurano dati relativi a condizioni climatiche in ambienti esterni, benessere (qualità dell'aria e microclima) in ambienti interni e prestazioni energetiche delle strutture considerate.

Obiettivi progettuali

Lo scopo dell'applicazione pilota TriggerAction è inviare alla Smart City Platform (SCP)2 i dati acquisiti dai sensori e già salvati in un esistente database.

Struttura del progetto

Il progetto è strutturato secondo le raccomandazioni Physical Project Structure3 di ServiceStack ed è quindi ripartito in:

  • Host Project4
  • ServiceInterface Project5
  • ServiceModel Project6

Host Project

Applicazione console, può essere lanciata da riga di comando e di per sé non richiede installazione. Essendo sviluppata con TopShelf7 può anche essere installata come servizio Windows, cosa che è stata fatta sul server di produzione. La generazione e l'invio degli UD alla SCP è basato su "job" pianificati con tecnologia Quartz.NET8 L'applicazione funge inoltre da host di servizi web realizzati con ServiceStack9.

ServiceInterface Project

Progetto che contiene l'implementazione dei servizi web.

ServiceModel Project

Progetto che contiene i DTO dell'applicazione e le classi POCO utilizzate da OrmLite10.

Configurazione dell'applicazione

I principali parametri di configurazione dell'applicazione si trovano in alcuni file ".config" dai nomi abbastanza esplicativi:

  • Configuration/AppSettings.config
  • Configuration/ConnectionStrings.config
  • Configuration/QuartzJobs.config
  • Configuration/TriggerActionSettings.config
  • NLog.config Il file NLog.config non richiede particolari spiegazioni, trattandosi di un file di configurazione NLog11 standard. Allo scopo di agevolare lo sviluppo ed il versionamento del codice i file nella cartella "Configuration" non sono archiviati in GitHub né distribuiti con l'applicazione, la cartella medesima contiene uno script12 che può essere utilizzato per inizializzarli sulla base di alcuni modelli13. Il file QuartzJobs.config è il più importante per quel che concerne gli invii pianificati alla SCP ed è facilmente leggibile alla luce della documentazione ufficiale14 del plugin per l'elaborazione dei dati di pianificazione XML di Quartz.NET I due "job" attualmente implementati sono:
  1. FileSenderJob15
  2. UrbanDatasetProducerJob16

FileSenderJob

La classe pubblica FileSenderJob implementa l'interfaccia Quartz.IJob ed ha il compito di inviare al server SCP gli UrbanDataset prodotti e salvati localmente dalla classe "producer" descritta più sotto. La cartella locale contenente i file è configurabile da attraverso un percorso assoluto o relativo ad una sottocartella di %PROGRAMDATA% La classe FileSenderJob apre, se necessario, una nuova sessione autenticata e dopo il PUSH sposta il file in una sottocartella il cui nome rispecchia il codice restituito dal server, tipicamente "02" che sta per "Push Succesful". In caso di mancata risposta da parte del server, o comunque di impossibilità di invio, il file rimarrà nella cartella "outgoing" e sarà elaborato in una delle successive esecuzioni del "job". Attraverso il file QuartzJobs.config si pianifica l'esecuzione del "job", tipicamente appare ragionevole un'esecuzione ogni minuto o due, con un possibile sfasamento rispetto all'esecuzione del job "producer" per ridurre la probabilità di accesso concomitante ai file

UrbanDatasetProducerJob

La classe pubblica UrbanDatasetProducerJob implementa l'interfaccia Quartz.IJob ed ha il compito di produrre gli UrbanDataset e salvarli localmente, l'invio alla SCP sarà effettuato dalla classe descritta più sopra. L'esecuzione dei "job" è pianificata attraverso il file QuartzJobs.config In fase di esecuzione il "job" prenderà in considerazione solo i "production_id" passati attraverso la chiave BatchOperationTypeIn di come array di stringhe in formato JSV, ciò all'evidente scopo di poter dare una pianificazione diversa a differenti contesti. La classe UrbanDatasetProducerJob utilizza internamente la classe BasicRequest la quale a propria volta utilizza DeviceRequest. Questa integrazione con i messaggi ServiceStack consente di esporre anche come servizi web le funzioni utilizzate dal "producer", a scopo diagnostico o per esporre gli UrbanDataset ad eventuali client esterni.

Lo schema sottostante riassume il contenuto del presente e del precedente paragrafo, ulteriori note sui servizi web si trovano nelle sezioni dedicate.

+----------------------------+                    +-----------------+ HTTP
|  UrbanDatasetProducerJob   | --> FILESYSTEM <-> |  FileSenderJob  | ----> ( INTERNET ) -> SCP
+----------------------------+                    +-----------------+
 |     +---------------------+
 +---->|    BasicRequest     |
       +---------------------+
        |    +---------------+
        +--->| DeviceRequest | <-> DATABASE
             +---------------+

ServiceStack.Quartz

ServiceStack.Quartz17 è un plugin per ServiceStack che fornisce una semplice integrazione con Quartz.Net. Per i dettagli rimandiamo alla pagina del progetto, qui ci limitiamo a sottolineare che tale plugin configura alcuni percorsi utili a scopo diagnostico, ad esempio:

Servizi web

L'applicazione TriggerAction espone alcuni metodi web utili a scopo diagnostico, elencati alla pagina http://localhost:8088/metadata e testabili alla pagina http://localhost:8088/swagger-ui/ Segnaliamo in particolar modo:

  1. http://localhost:8088/plants (elenco impianti e dispositivi presenti a sistema);
  2. http://localhost:8088/devices (elenco dettagliato dispositivi con attributi anagrafici);
  3. http://localhost:8088/devices/{DeviceId} (dati recenti ed informazioni relative al dispositivo);
  4. http://localhost:8088/basicRequest su cui faremo alcune osservazioni più sotto.

Elenco dispositivi e relativi attributi anagrafici

Tramite il metodo di cui al precedentr punto 2 è possibile, tra l'altro, recuperare la lista completa in formato CSV di tutti i dispositivi con i relativi attributi anagrafici: RealEstateUnitID, RoomID, RoomCode etc.

basicRequest REST method

Il metodo "basicRequest" permette di richiedere un UrbanDataset tramite una chiamata REQUEST/RESPONSE senza raffinamento della ricerca, ed è stato sviluppato sulla base di: http://smartcityplatform.enea.it/#/it/specification/communication/2.0/index.html#basicrequestrestmethod La scelta di riferirsi alle specificazioni SCPS Communication ha lo scopo di aprire alla possibilità di eventuali ulteriori sviluppi in cui sia la SCP a richiedere l'UD alla soluzione.

Schermate

Pagina iniziale http://localhost:8088

default

Snapshot of http://localhost:8088/devices/79

devices

ServiceStack Studio - Edit Device

studio

Visualizzare i dati sulla SCP

I dati che l'applicazione pilota invia alla SCP sono visualizzabili tramite l'interfaccia SCP-GUI accessibile all'indirizzo https://scp.dare-ravenna.eu:8445/enea-gui/

Allo stato attuale solo tre stazioni meteorologiche espongono pubblicamente i dati, la consultazione dei restanti siti richiede di accedere alla "dashboard" con le opportune credenziali.

indicators

scp

Note

  1. Progetto open source commerciale giunto alla versione 5.11.0
  2. http://sue.enea.it/product/piattaforma-per-gestione-dei-dati-urbani/
  3. https://docs.servicestack.net/physical-project-structure
  4. https://github.com/titobrasolin-ke/TriggerAction/tree/main/TriggerAction
  5. https://github.com/titobrasolin-ke/TriggerAction/tree/main/TriggerAction.ServiceInterface
  6. https://github.com/titobrasolin-ke/TriggerAction/tree/main/TriggerAction.ServiceModel
  7. http://docs.topshelf-project.com/en/latest/overview/commandline.html
  8. https://www.quartz-scheduler.net/documentation/quartz-3.x/quick-start.html
  9. https://docs.servicestack.net/self-hosting
  10. https://github.com/ServiceStack/ServiceStack.OrmLite
  11. https://nlog-project.org/config/
  12. github.com/titobrasolin-ke/TriggerAction/blob/main/TriggerAction/Configuration/copy_default_config.bat
  13. Idea ripresa da http://stackoverflow.com/questions/3707749/developer-specific-app-config-web-config-files-in-visual-studio/3920462#3920462
  14. https://www.quartz-scheduler.net/documentation/quartz-3.x/configuration/reference.html#sample-configuration-of-xml-scheduling-data-processor-plugin
  15. github.com/titobrasolin-ke/TriggerAction/blob/main/TriggerAction/Jobs/FileSenderJob.cs
  16. github.com/titobrasolin-ke/TriggerAction/blob/main/TriggerAction/Jobs/UrbanDatasetProducerJob.cs
  17. https://github.com/wwwlicious/ServiceStack.Quartz
Clone this wiki locally