Your SlideShare is downloading. ×
  • Like
Sviluppo di un hub di comunicazione in un applicazione per porti con Biztalk Server 2010
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Sviluppo di un hub di comunicazione in un applicazione per porti con Biztalk Server 2010

  • 1,200 views
Published

 

Published in Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,200
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
25
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. UNIVERSITÀ DEGLI STUDI DI TRIESTE FACOLTÀ DI INGEGNERIA Corso di laurea specialistica in Ingegneria Informatica Tesi di Laurea in Complementi di Basi di Dati SVILUPPO DI UN HUB DI COMUNICAZIONE IN UNA APPLICAZIONE PER PORTI CON BIZTALK SERVER 2010Laureando: Relatore:Walter Geretto Prof. Maurizio Fermeglia ANNO ACCADEMICO 2009/2010
  • 2. Ai miei genitori…
  • 3. Indice1. INTRODUZIONE ....................................................................................................................................................... 1-1 1.1 OBIETTIVO ......................................................................................................................................................... 1-12. SLIMPORT ................................................................................................................................................................ 2-3 2.1 CENNI AL PROGETTO ............................................................................................................................................ 2-3 2.2 PROGETTO D’INVESTIMENTO ................................................................................................................................. 2-4 2.3 INDICAZIONI DEI VANTAGGI COMPETITIVI OTTENIBILI SUL MERCATO ............................................................................... 2-7 2.4 VALUTAZIONE SINTETICA DELL’IMPATTO DEL PROGETTO D’INVESTIMENTO..................................................................... 2-103. ANALISI DEI REQUISITI .......................................................................................................................................... 3-12 3.1 SLIMTRUCK ...................................................................................................................................................... 3-12 3.2 ANALISI NELL’AMBITO DEL PORTO FRANCO DI TRIESTE............................................................................................... 3-13 3.3 FLUSSI DI IMPORT/EXPORT DEI CONTAINER TRA LE ZONE DI PORTO E RETROPORTO .......................................................... 3-19 3.4 TUBO VIRTUALE ................................................................................................................................................ 3-37 3.6 ARCHITETTURA DI RETE ....................................................................................................................................... 3-424. ANALISI FUNZIONALE ............................................................................................................................................ 4-50 4.1 AMBIENTE E STRUMENTI DI SVILUPPO .................................................................................................................... 4-50 4.2 CENNI ALL’ARCHITETTURA DI BIZTALK SERVER ......................................................................................................... 4-51 4.3 DEFINIZIONE DELLE ENTITÀ COINVOLTE .................................................................................................................. 4-53 4.4 PROCESSI INTERNI ALL’HUB.................................................................................................................................. 4-55 4.5 DEFINIZIONE DEI MESSAGGI SCAMBIATI .................................................................................................................. 4-58 4.6 FUNZIONALITÀ OFFERTE ...................................................................................................................................... 4-715. DISEGNO DEI DATI................................................................................................................................................. 5-82 5.1 ENTITÀ ............................................................................................................................................................ 5-82 5.2 TABELLE .......................................................................................................................................................... 5-83 5.3 SCHEMA FISICO ................................................................................................................................................. 5-87 5.4 CONSIDERAZIONI ............................................................................................................................................... 5-88 iii
  • 4. 5.5 STORED PROCEDURE .......................................................................................................................................... 5-89 5.6 DATABASE DI SUPPORTO ..................................................................................................................................... 5-916. IMPLEMENTAZIONE .............................................................................................................................................. 6-95 6.1 DESCRIZIONE DELLE SOLUTIONS............................................................................................................................ 6-95 6.2 HUB DI COMUNICAZIONE .................................................................................................................................... 6-97 6.3 CONSOLE E SERVIZI DI SUPPORTO ........................................................................................................................ 6-137CONCLUSIONI .............................................................................................................................................................. 6-161BIBLIOGRAFIA .............................................................................................................................................................. 6-163RINGRAZIAMENTI ........................................................................................................................................................ 6-164 iv
  • 5. 1. Introduzione1.1 ObiettivoOggetto di questa tesi è lo sviluppo di un hub di comunicazione che realizza l’integrazione di modulisoftware in un applicazione per porti. Questo lavoro è stato svolto presso Teorema Engineering srl e siinserisce nel contesto di un progetto di ampie dimensioni chiamato SlimPORT.Un investimento totale di oltre 32 milioni di Euro, più di 40 partner industriali e scientifici, 10 tra porti einterporti coinvolti in altrettante regioni italiane. Sono le credenziali di Slimport, il Sistema per lagestione di logistica e sicurezza per l’intermodalità portuale, cioè per il trasporto di persone e merciintegrato fra nave, treno e veicoli su gomma. Slimport rientra nel ristretto numero dei progetti finanziatidal Ministero dello Sviluppo Economico, nell’ambito del Programma Industria 2015 - Mobilità Sostenibile.A differenza di altre soluzioni presenti oggi sul mercato, Slimport risolve con un’unica filiera tecnologicamodulare numerose problematiche inerenti la movimentazione mercantile in quello che in “Industria2015” viene definito “ ultimo miglio mare - primo miglio terra”. L’innovazione si basa su una piattaformatecnologica che offre a un operatore logistico o al gestore di un nodo di interscambio tra mezzi un set dicomponenti che, integrando soluzioni info-telematiche, impianti e sensoristica, consente di intervenirenelle varie fasi del processo operativo di trasporto. Il risultato è minori tempi di transito a minor costo econ un più ridotto inquinamento ambientale.Il sottosistema considerato si chiama SlimTruck. E’ uno dei tredici di cui si compone SlimPort e si occupadel trasferimento di container nella tratta porto-retroporto su strada mediante la creazione di uncosiddetto tubo virtuale che permette di considerare logicamente le aree del porto e del retroportocome un’unica area doganale. 1-1
  • 6. Il risultato che si vuole ottenere è un hub per gestire il routing di messaggi tra moduli softwareindipendenti. Le entità che devono essere messe in comunicazione sono:  Un gateway che si interfaccia con la strumentazione di bordo dei veicoli e trasmette informazioni sullo stato dei container sottoposti a movimentazione.  Una componente di gestione emergenze che analizza costantemente le informazioni fornite dai computer di bordo e determina il verificarsi di situazioni potenzialmente pericolose per la sicurezza delle merci.  Una componente di interfaccia a disposizione di un operatore che ha il compito di supervisionare lo svolgimento dei trasferimenti e intervenire nelle situazioni di allarme secondo le indicazioni fornite dal sistema.Questo hub di comunicazione deve essere in grado di ricevere messaggi da ognuna delle componentidescritte, ed inoltrarli alla destinazione secondo determinati processi di business garantendo unefficiente gestione delle risorse.Lo strumento scelto per lo sviluppo è Biztalk Server 2010, l’integration server di Microsoft che permettedi connettere sistemi diversi fornendo un’infrastruttura di comunicazione orientata ai messaggi. Lacomunicazione fra l’Hub e gli altri moduli avviene principalmente attraverso servizi web sviluppati contecnologia Windows Comunication Foundation. 1-2
  • 7. 2. SlimPORT2.1 Cenni al progettoIl programma di sviluppo SLIMPORT (Sicurezza, Logistica, Intermodalità Portuale) realizza un progettoinnovativo di porto che integra soluzioni modulari volte rendere a efficienti i processi operativinell’ambito dell’ultimo miglio mare e primo miglio terra, consentendo: 1. La riduzione del tempo di stazionamento e di transito delle merci e dei passeggeri nei nodi del trasporto; 2. La velocizzazione delle operazioni di carico, scarico e trasbordo; 3. La cooperazione con i sistemi info-telematici di gestione dei processi operativi esistenti nell’area; 4. L’incremento della sicurezza nelle operazioni portuali salvaguardando le logiche di business; 5. L’intermodalità nell’ambito della catena logistica; 6. La decongestione dei trasporti e la mobilità sostenibile nel territorio.Il porto è il principale punto di raccordo tra il trasporto via mare (“ultimo miglio marino”) e i trasporti viagomma e ferroviari sulla terra ferma (“primo miglio terrestre”); esso è quindi logicamente collegato congli altri nodi logistici non marittimi, quali interporti, piattaforme logistiche, retroporti: il progettoSLIMPORT, proprio per realizzare un progetto che abbia impatti positivi sul sistema economico deitrasporti e delle infrastrutture nel suo complesso, prevede come enti sperimentatori Autorità Portuali egestori di altri nodi del trasporto di rilevanza nazionale.Il prodotto SLIMPORT è un sistema modulare che offre ad un operatore logistico o ad un gestore di unnodo del trasporto un set di componenti tecnologiche che, integrando soluzioni info-telematiche,impianti e sensoristica, consentono di intervenire nelle varie fasi del processo operativo di trasportodelle merci e delle persone, aumentandone l’efficienza, favorendo il riequilibrio ambientale,sviluppando l’intermodalità e riducendo complessivamente il tempo di transito delle merci e dellepersone nei nodi del trasporto, a parità di investimenti in apparecchiature e servizi.Il prodotto SLIMPORT rende disponibile agli operatori del trasporto ed agli enti gestori dei nodi unasoluzione in grado di indirizzare le problematiche di maggior rilievo per il miglioramento dei processioperativi, indirizzando i principali bisogni del settore: gestione di aree doganali uniche, sviluppo altrasporto ferroviario, sostegno per una gestione equilibrata ed eco-compatibile del trasporto su gomma,spinta all’intermodalità, raccordo con i sistemi di trasporti pubblico locale, utilizzo di tecnologie e 2-3
  • 8. processi a favore della safety e della security, mitigazione delle discontinuità tra componente marittimae portuale nei processi di carico e scarico.Tutto ciò non trascurando la necessità di salvaguardare quanto già in uso da parte della comunità deltrasporto. Il prodotto SLIMPORT prevede infatti il recupero degli investimenti in tecnologie, reti ditrasmissione ed informatica già presenti nei nodi del trasporto; favorisce inoltre l’integrazione con lesoluzioni tecnologiche già in uso da parte degli operatori della catena logistica: terminalisti,trasportatori, spedizionieri, Guardia di Finanza, Dogana, etc. In ultimo, le componenti di SLIMPORTconsentono di sviluppare collegamenti interfacce con i principali sistemi nazionali di ausilio ai processidel trasporto, quali il Vessel Traffic Service, il sistema applicativo UIRNET ed ARTIST, l’ArchitetturaTelematica italiana per il sistema dei trasporti. Le componenti innovative possono essere propostenell’ambito della soluzione complessiva SLIMPORT o singolarmente, a seconda dei bisogni del singolooperatore o gestore del nodo del trasporto.2.2 Progetto d’investimento2.2.1 Caratteristiche funzionali e tecnicheSlimPORT è un progetto innovativo di porto che integra soluzioni modulari per efficientare i processi“ultimo miglio mare - primo miglio terra”.Le caratteristiche funzionali sono:  Gestione e monitoraggio trasporto merci tra porto e retroporto (ferrovia: slimRAIL – strada: slimTRUCK)  Automazione dei processi intermodali di trasbordo (slimCARGO), manovre ferroviarie (slimMOVE) e accesso ai gate (slimGATE)  Controllo di safety (slimSAFE) e security terrestre (slimCHECK) e marina (slimCONTROL)  Gestione dei processi di banchina per attracco/scarico/carico (slimSEA) e per il transhipment (slimCAR).  Efficienza e sicurezza per il traffico traghetti (slimFERRY)  Mobilità sostenibile e ambiente nell’interazione città-porto (slimCITY)  Interoperabilità nelle comunicazioni (slimCOMMS)2.2.2 Vantaggi attesi rispetto allo stato dell’arteL’utilizzo dei moduli slimPORT nell’ambito dei processi comporta: 2-4
  • 9.  Riduzione del tempo di stazionamento e di transito delle merci e dei passeggeri nei nodi del trasporto  Velocizzazione delle operazioni di carico, scarico e trasbordo  Integrazione con i sistemi ITS nazionali  Incremento della sicurezza nelle operazioni portuali salvaguardando le logiche di business  Intermodalità nell’ambito della catena logistica  Decongestione dei trasporti e la mobilità sostenibile nel territorio2.2.3 Situazione della concorrenza su prodotti analoghiL’idea è quella di proporre una soluzione modulare e integrata che rappresenti un’innovazione per isingoli processi che intende efficientare e che nell’insieme rappresenti un’unica soluzione per la logisticadei trasporti in ambito portuale. La scelta dei processi da coprire è stata concordata nella maggior partedei casi con gli utenti finali (Autorità portuali). Una così vasta offerta in una singola soluzione di un unicogruppo non ha analogo esempio sul mercato.2.2.4 Criticità previste per lo sviluppo e l’industrializzazioneLe criticità del progetto slimPORT sono:  Il coordinamento e la gestione del progetto dovuta alla numerosità di partner  Lo studio di nuovi processi e normative doganali  La progettazione e realizzazione delle specifiche di integrazione tra i sottosistemi  Il coinvolgimento di vari attori e in particolare delle Autorità Portuali per la realizzazione di prototipi che hanno un impatto sui loro processi operativi  La completa industrializzazione dovuta alla numerose realtà coinvolte2.2.5 Ulteriori sviluppi possibiliLa soluzione modulare e l’architettura di sistema consentono una elevata flessibilità e lo sviluppo dinuovi moduli (sottosistemi) o di componenti all’interno di uno già esistente. Sviluppi possibili possonoessere:  Piattaforme info-telematiche di scambio informativo tra più slimPORT  Sistemi di gestione dell’intero ciclo di trasporto della merce con i servizi ad esso connessi  L’interconnessione con gli Interporti per una gestione ottimizzata della merce e degli spazi 2-5
  • 10. 2.2.6 Altri possibili settori industriali di applicazioneLa soluzione modulare che slimPORT propone è sicuramente esportabile in ambiti logistici analoghi.Questo comporta che a livello nazionale ed internazionale può essere commercializzata anche sugliinterporti, mentre nel solo contesto internazionale può trovare applicabilità anche per porti fluviali. Isingoli sottosistemi hanno invece ulteriori settori industriali di applicazione.2.2.7 Ricadute e impatto potenzialeLe Aziende coinvolte nell’iniziativa, grazie al finanziamento, hanno come ricadute principali:  Accorciamento dei tempi di acquisizione di nuove tecnologie e presenza sui mercati con proposte assolutamente innovative.  Incremento dell’attività di R&D delle singole aziende e di sinergia con gli enti di ricerca.  Collaborazione sul mercato tra PMI e Grandi Imprese.  Effetti sul livello occupazionale (riconversione risorse o nuove assunzioni).2.2.8 Scelta progettualePer poter fornire una soluzione esaustiva rispetto al tema del bando e interessante per gli entiutilizzatori, la scelta della struttura progettuale è determinante per la riuscita finale del programma.Le realtà portuali, alle quali il tema si rivolge, sono molto diverse, sia in ambito nazionale cheinternazionale, ovvero le tipologie di business da efficientare dipendono da:  Tipo di porto (commerciale, passeggeri, misto);  Ubicazione (forte interazione con la città, varchi di accesso);  Infrastrutture e livello di informatizzazione.A questo varietà di contesti di riferimento, vanno aggiunti temi traversali a tutte le realtà che sonosoggetti a recenti normative o a esigenze stringenti:  Safety e protezione degli ambienti di lavoro  Port SecurityIn questo senso si è orientata la scelta verso una soluzione modulare che prevede:  sottosistemi autoconsistenti per un singolo ambito;  moduli abbinabili e integrabili in base alle esigenze.Questo consenta di proporre sul mercato in qualsiasi realtà portuale la suite slimPORT. 2-6
  • 11. 2.2.9 Architettura software e sottosistema slimCOMMSDove il sottosistema o la componente prevede una piattaforma software è importante chel’implementazione sia fatta in modo da consentire una facile integrazione, un interscambio dati tramoduli a prescindere dall’ambiente di sviluppo utilizzato, un’architettura aperta in grado di interfacciarsianche con sistemi esterni.Di particolare rilievo sono gli strumenti e le metodologie utilizzate per l’architettura dei sistemiinformatici che, oltre ad essere basati su soluzioni open source, fanno ricorso in maniera significativa astrumenti quali i web services, orientati alla condivisione di servizi attraverso architettura SOA, e aparadigmi aperti scalabili ed interoperabili per la codifica e la condivisione dei flussi dati tra i sistemiattivi all’interno dell’area portuale.In dettaglio, si utilizzerà lo standard XML, standard messo a punto e promosso dal consorzio mondialeW3C universalmente utilizzato per lo scambio e la condivisione di dati. I flussi dati utilizzati sarannocodificati secondo gli “XML Schema” e saranno resi pubblici e condivisi con tutti gli attori del progetto.L’approccio metodologico utilizzato per lo sviluppo della proposta progettuale garantisce non solo lapiena integrabilità trai vari moduli della soluzione, ma anche l’interfaccia con altre iniziative in esserenell’area portuale.2.3 Indicazioni dei vantaggi competitivi ottenibili sul mercatoMolti porti italiani sono accomunati dalla difficoltà di espansione della propria area operativa; negli annila forte crescita delle città, che si sono sviluppate intorno alle aree portuali, ha consumato, tutto o quasi,lo spazio a disposizione, a volte circondando completamente i porti, impedendone lo sviluppo erendendo molto critica l’iterazione porto-città In una situazione di mercato favorevole, dove eventisociopolitici consentono una previsione di traffici delle merci in aumento, il problema dello spazio stadiventando sempre piu` sentito per i porti il cui spazio a disposizione non riesce più a supportareadeguatamente i flussi di merci in aumento.Si sono dunque realizzate (o sono in corso di progettazione) delle estensioni dei porti verso l’entroterra;le aree retroportuali se da un lato hanno risolto il problema spazio, hanno dall’altro fatto nascere nuoveproblematiche da gestire e fatto apparire nuovi scenari per la gestione del flusso delle merci nell’ambitodi questo “porto esteso”.E’ proprio in questo contesto che si colloca la realizzazione di SLIMPORT.Il prodotto SLIMPORT ha l’obiettivo di: 2-7
  • 12.  ridurre il tempo di stazionamento e di transito delle merci e dei passeggeri nei nodi del trasporto,  velocizzare le operazioni di carico, scarico e trasbordo  incrementare il livello di sicurezza nelle operazioni portuali, salvaguardando le logiche di business  promuovere l’intermodalità nell’ambito della catena logistica  decongestionare i trasporti e promuovere la mobilità sostenibile nel territorio.SLIMPORT propone un sistema tecnologico non solo completo (seppur modulare) e allineato con ibisogni concreti degli operatori, ma sostiene l’evoluzione del nodo trasportistico verso il modello di“porto esteso”: sistema bipolare che amplia l’area di governo del nodo portuale, mediante l’utilizzo diaree retroportuali, consentendo una crescita dei traffici almeno con la stessa efficienza.SLIMPORT si propone come una soluzione innovativa dal punto di vista tecnologico e unica nel mercatodegli operatori del trasporto; essa coniuga l’applicazione di soluzioni tecnologiche avanzate edappropriate con la necessità di fornire alla comunità trasportistica soluzioni calibrate per i suoi bisogni:  gestione di aree doganali uniche  sviluppo del trasporto ferroviario,  sostegno al trasporto su gomma, per favorirne una gestione equilibrata ed eco-compatibile  focalizzazione sulle tecnologie favorevoli ed abilitanti dei processi intermodali,  raccordo con i sistemi di trasporto pubblico locale (interazione porto-città)  impiego di tecnologie e processi a favore della safety e della security  mitigazione delle discontinuità tra componente marittima e componente portuale nei processi di movimentazione delle merci  accesso diretto e semplice da parte degli utenti alle tecnologie impiegate (modelli di business semplificati)  rapporti con fornitori di tecnologie in grado di ben comprendere i processi operativi della comunità trasportistica e proporre le soluzioni tecnologiche più appropriate.  salvaguardia degli investimenti già effettuati ed in uso da parte della comunità trasportistica (applicazioni, impianti e tecnologie)Con riferimento a quest’ultimo punto, il prodotto SLIMPORT prevede infatti il recupero degliinvestimenti in tecnologie, reti di trasmissione e informatica applicativa già presenti nei nodi deltrasporto; favorisce inoltre l’integrazione con le soluzioni tecnologiche già in uso da parte degli operatoridella catena logistica: terminalisti, trasportatori, spedizionieri, Guardia di Finanza, Dogana, etc. Inoltre,le componenti di SLIMPORT consentono di sviluppare collegamenti e interfacce applicative con i 2-8
  • 13. principali sistemi nazionali di ausilio ai processi della catena logistica, quali il Vessel Traffic Service, ilsistema applicativo UIRNET ed ARTIST, l’Architettura Telematica italiana per il sistema dei trasporti).SLIMPORT propone soluzioni che intervengono nelle singole fasi del processo produttivo della filieratrasportistica ed è in grado, anche grazie alla compagine di aziende con esperienze e referenze nelsettore della logistica dei trasporti, di automatizzare completamente un porto di nuova costruzione, cosìcome fornire risposte per porti già attrezzati, pur preservando e integrando gli investimenti già fatti intecnologia e impianti.Le scelte tecnologiche fatta in SLIMPORT sono rafforzate dalla stretta collaborazione con gli EntiUtilizzatori – numerose Autorità Portuali – al fine di definire un sistema funzionalmente completo,progettato con gli utenti.Con riferimento alla situazione della concorrenza su sistemi analoghi, non sono disponibili sul mercatosoluzioni modulari ed integrate di prodotti, impianti e tecnologie che consentano a una comunità dioperatori del trasporto di selezionare le soluzioni più confacenti ai loro bisogni specifici, garantendo nelcontempo la realizzazione di un sistema tecnologico port-wide, in grado di fornire le soluzionitecnologiche necessarie alla gestione di tutti i processi operativi del nodo del trasporto.La soluzione SLIMPORT non esclude l’impiego di prodotti della concorrenza; il suo obiettivo e’ proporreuna propria componente laddove ha individuato concreti spunti innovativi in grado di miglioraresensibilmente lo stato dell’arte, ma di garantire l’impiego (ed anche la co-fornitura) di altri prodotti,favorendo la realizzazione di opportune interfacce operative.Per completare l’analisi del mercato, i fattori di debolezza (o almeno di attenzione) sono legati a dueelementi:  la disponibilità di una soluzione funzionalmente completa: il ruolo delle Autorità Portuali (enti utilizzatori) è determinante  la realizzazione di referenze complete e di valore: questo fattore e’ critico per poter sviluppare un piano di vendita aggressivo e convincente, basto su elementi concreti di valutazione da parte dei prospect., i principali punti di forza sono:  Sinergie tra i partner dell’iniziativa: ciascun partner – operatore industriale con specializzazione di prodotto o di mercato – fornisce il proprio apporto al sistema complessivo SLIMPORT.  Realizzazione di un sistema modulare, ma completo da proporre a tutte gli operatori della filiera trasportistica in funzione delle specifiche esigenze operative e di business 2-9
  • 14.  Facilità d’uso dei sistemi tecnologici realizzati e cooperazione degli stessi con i sistemi infotelematici di gestione dei processi operativi esistenti nell’area  Modello di business dell’iniziativa innovativo che prevede di erogare l’offerta anche in ottica di “service”, rendendo disponibile la funzione d’uso richiesta dall’utente  Creazione di un modello di riferimento “funzionale e architetturale” per lo sviluppo di sistemi informatici a sostegno dei processi operativi di logistica a livello nazionale; ciò anche grazie al coinvolgimento diretto, in qualità di Enti Sperimentatori, delle Autorità Portuali  Replicabilità del progetto anche a livello internazionale; ciò grazie sia alla robustezza finanziaria della compagine di partner, sia al buon livello di standardizzazione delle funzionalità disponibili ( i processi operativi della filiera trasportistica hanno caratteristiche internazionali e multi-locali)2.4 Valutazione sintetica dell’impatto del progetto d’investimentoLe attività legate al trasporto, sia di persone sia di merci, sono tra quelle che condividono le maggioriresponsabilità per il crescente inquinamento, sia a livello planetario sia a livello delle singole regioni. Alivello planetario si assiste ad una mutazione significativa delle condizioni climatiche dovuta, tra l’altro,alle emissioni di gas di scarico dei mezzi di trasporto mentre a livello locale sono sempre più evidenti inalcune regioni ed in alcune città fenomeni di inquinamento atmosferico che rendono meno piacevole e,soprattutto, meno sana la vita delle persone.Ma l’inquinamento non è la sola conseguenza delle attività legate ai trasporti che impatta sulla vita dellepersone. Tra gli altri fattori da tenere in adeguata considerazione vi sono da un lato i rischi derivantidalla presenza di merci pericolose all’interno delle stesse vie di comunicazione in cui transitano lepersone e dall’altro l’elevata probabilità di incidenti stradali dovuta alla densità troppo alta di mezzipesanti sulle strade e sulle autostrade.Il progetto SlimPORT ha significative implicazioni dal punto di vista della sostenibilità ambientale comesintetizzato nel seguito.SlimPORT auspica e supporta l’evoluzione verso un modello di porto nel quale le attività portuali nonsono più localizzate esclusivamente sulle banchine, come al momento attuale, ma sono invecedistribuite su un territorio interno di più ampia profondità chiamato “porto esteso”. La distribuzionedelle attività portuali su un territorio più vasto ha come conseguenza un decongestionamento della areeportuali vicine al mare e va quindi nella direzione di una riutilizzazione delle stesse per attività diverse, diminore impatto ambientale e di maggiore fruibilità per la popolazione. Presupposto indispensabile 2-10
  • 15. perché l’estensione delle attività non abbia conseguente negative sull’inquinamento è che la stessavenga supportata da sistemi ferroviari di impatto ambientale molto contenuto, come previsto dalprogetto slimPORT.Un primo beneficio del progetto è quindi quello di ridurre il numero di mezzi pesanti nelle aree contigueai porti, e cioè aventi distanza dell’ordine delle decine di chilometri dagli stessi. Il decongestionamentodella rete stradale non può che avere come conseguenza diretta una drastica diminuzionedell’inquinamento, molto spesso causati da una bassa efficienza del trasporto e quindi dalla permanenzadei mezzi in coda, ed una diminuzione degli incidenti stradali, molto spesso causati dalla presenzasimultanea sulla strada di mezzi pesanti e di autovetture che viaggiano a velocità molto diverse.Slimport indirizza poi specificatamente la tecnologia di tracciamento delle merci attraverso sistemi ditelecontrollo basati su GPS e telefonia mobile. Questo consente il monitoraggio costante delle posizionidei veicoli e delle merci.Un secondo beneficio del progetto, derivante dall’applicazione delle tecnologie di telecontrollo, è quellodi consentire il controllo in tempo reale della posizione delle merci pericolose in transito nel sistemastradale ed autostradale. Attraverso opportuni sistemi di comando e controllo le Agenzie di Protezionedell’Ambiente, la Polizia Stradale, i Vigili del Fuoco e gli altri soggetti pubblici interessati possonomantenere una conoscenza aggiornate dalla localizzazione e delle caratteristiche delle merci pericolosein transito e predisporre di volta in volta le azioni maggiormente appropriate per prevenire incidenti e/oper gestire con tempestività le operazioni di soccorso.Un terzo beneficio del progetto, anch’esso derivante dall’applicazione delle tecnologie di telecontrollo, èquello di supportare l’adozione di politiche e strumenti a supporto della distribuzione eco-compatibile dimerci in ambito urbano. Il telecontrollo dei mezzi ecologici gestiti dalle agenzie incaricate delladistribuzione eco compatibile consente ai titolari dei servizi di trasporto di mantenere il rapporto direttocon i clienti e rimuove quindi il principale ostacolo verso la terziarizzazione della stessa distribuzioneurbana, creando così i presupposti per una diminuzione dell’inquinamento cittadino.In sintesi, quindi, il decongestionamento della rete stradale ed autostradale, con conseguenze sultraffico, sugli incidenti e sull’inquinamento, ed il telecontrollo dei mezzi, che rende possibile prevenire ilmonitoraggio della posizione delle merci pericolose ed il controllo della distribuzione ecocompatibile dimerci in ambito urbano costituiscono i principali aspetti del progetto Slimport dal punto di vistaambientale. 2-11
  • 16. 3. Analisi dei requisiti3.1 SlimTruckL’implementazione del sottosistema SlimTruck si pone come obiettivo la realizzazione di un sistemasicuro ed efficiente di trasferimento container nella tratta porto-retroporto su strada per ottimizzarne iflussi e la conseguente gestione di aree portuali e delle procedure e flussi gestionali. Se da un lato lanascita negli anni dei retro porti intermodali ha risolto il problema spazio che opprimeva e limitava lepossibilità di espansione dei porti, hanno dall’altro lato fatto nascere nuove problematiche da gestire,ma soprattutto, hanno fatto apparire all’orizzonte nuovi scenari per la gestione del flusso delle merci trail porto ed il suo retro porto. E’ proprio in questo contesto che si colloca la realizzazione del sottosistemacon il suo ambizioso obiettivo di ottimizzare la gestione delle nuove aree, sfruttandone al massimo lecapacità produttive.La realizzazione di un sistema del genere porta con se non solo problematiche di tipo tecnologico, maanche una importate revisione dei processi e delle normative attive oggi. Basti pensare che una dellepossibili ottimizzazioni potrebbe essere l’espletamento di tutte le necessarie procedure doganalidirettamente nel retro porto. Per la realizzazione del nostro sistema sarà dunque necessario eseguire unattento ed approfondito studio mirato alla definizione dei nuovi processi ed alla ridefinizione dellenorme e procedure doganali. Tali informazioni saranno poi usate per lo sviluppo dei moduli di natura piùtecnica che andranno a comporre quanto è stato definito con il nome “tubo-virtuale”, ovvero, uninsieme di componenti software e hardware che consentiranno la gestione dello spostamento dellamerce nella tratta porto-retroporto. E’ stato scelto questo nome in quanto rappresentativo del fatto cheil porto ed il suo retro porto, devono essere visti come ununica entità e di conseguenza la merce unavolta entrata nel retro porto deve ritenersi a tutti gli effetti nel porto e viceversa. E’ risaputo però chefisicamente le cose non stanno così in quanto il porto ed il retro porto sono separati da suolo pubblico, eche la merce in transito deve muoversi su strade, percorse da traffico urbano. Diventa di conseguenzachiaro che sarà il sistema sviluppato a dover fornire le funzionalità necessarie affiche il concetto di tubosia rispettato e che di conseguenza le merce in transito raggiunga sempre la destinazione in modoefficiente e sicuro.Il “tubo virtuale” si otterrà dunque realizzando un insieme di componenti comunicanti tra di loro. Saràrealizzato: 3-12
  • 17.  il marketplace, ovvero, un punto di incontro tra domanda ed offerta. Quest’area sarà a disposizione degli operatori di mercato ed avrà lo scopo di offrire, vendere e richiedere servizi di stoccaggio o spostamento della merce. In quest’area saranno anche inserite funzionalità di gestione documentale e si potrà dunque espletare online anche le pratiche doganali o altre questioni amministrative.  Sistema HUB per l’integrazione delle informazioni e dei flussi gestionali tra operatori – integrazione con la piattaforma di monitoraggio e controllo  Modulo di generazione/gestione dei piani di viaggio  Sistema di tracciamento del mezzo e dei carichi su strada tramite opportuni apparati di bordo  Strumenti/metodologie di supporto alle decisioni per la gestione dei flussi tra porto e retro porto.Sarà soprattutto quest’ultimo punto, tramite l’utilizzo delle simulazioni dei flussi e dei movimenti, arappresentare la vera novità nella gestione dei viaggi garantendoci l’ottimizzazione degli spostamenti.A supporto di tutto il sistema e per consentire il dialogo di tutte le componenti dovrà essereimplementato un sistema di comunicazione composto da una combinazione di reti wireless e sistemi dicomunicazione satellitare, opportuni sistemi di monitoraggio e di sicurezza.3.2 Analisi nell’ambito del porto franco di Trieste3.2.1 Cenni introduttiviLa presente analisi si propone di definire i processi nella situazione attuale (AS-IS), sotto il profilo deiflussi fisici delle merci e delle relative informazioni, relativamente ai traffici che intercorrono fra il portodi Trieste e l’autoporto/piattaforma logistica di Fernetti.In questa prospettiva vale la pena richiamare brevemente, al fine di meglio cogliere le peculiarità dellecorrenti di trasporto, alcuni fattori che influenzano il livello e la configurazione strutturale dei flussi ditraffico gravitanti fra i due nodi in esame (portuale e inland terminal).A questo riguardo va innanzi tutto sottolineato che lo scalo triestino è un porto franco e il sistema diprocedure doganali che ne consegue incide significativamente, in virtù dei connessi regimi giuridico-amministrativi1 , sull’entità delle relazioni fra porto e inland terminal. Tale sistema influisce sulle scelte1 L’istituto del porto franco offre, tra l’altro, la possibilità di: introdurre liberamente le merci provenienti via mareda paesi extra-comunitari; depositare (senza limiti temporali) i carichi con esclusione del vincolo delladichiarazione doganale comunitaria; effettuare sia lavorazioni sulle merci estere (imballaggio, etichettatura, ecc.),sia trasformazioni industriali (previa autorizzazione amministrativa); dilazionare i pagamenti dei dazi e delleimposte doganali secondo un tasso agevolato; beneficiare, per i mezzi stradali provenienti o diretti verso il porto,di un regime di transito diretto agevolato; ecc. Fattori questi che rappresentano di certo un punto di forza del 3-13
  • 18. collegate all’inoltro dei carichi (garanzie doganali) verso la piattaforma logistica di Fernetti, in particolarmodo in un periodo come quello corrente, in cui il livello di congestionamento portuale non è - secondoquanto emerso in sede di intervista – elevato e il costo degli spazi delle concessioni vigenti in alcunearee portuali risulta (non di rado) inferiore rispetto a quello di Fernetti, e ciò naturalmente non gioca afavore della piattaforma logistica di Monrupino.Nonostante la collocazione geografica e le caratteristiche tecniche (raccordo ferroviario, aree distoccaggio, mezzi di movimentazione per container) di Fernetti lo rendano adatto a svolgere unafunzione di tipo “interportuale”, allo stato attuale l’autoporto svolge un ruolo quasi meramente“retroportuale”. Ciò scaturisce dalla tipologia preponderante di traffici che lo caratterizzano, ovvero daiflussi in export di automezzi da e per il terminal Samer del porto di Trieste, aventi lo scopo principale didecongestionare il terminal. Va tuttavia sottolineato che la funzione di retroporto è espletata, in questocaso, nei confronti di un unico operatore e non dell’intero porto, come invece si vorrebbe auspicare.In effetti, il quantitativo di merce containerizzata (alimentato per lo più da Trieste Marine Terminal Spa)è apparso, al di là dei recenti lavori di potenziamento e modernizzazione delle infrastrutture ferroviarieal servizio dell’autoporto (Villa Opicina), alquanto contenuto. Basti pensare che il volume dimovimentazione raggiunta da Fernetti nei primi undici mesi del 2009 supera di poco i 600 TEUs, di cuicirca il 52% è stato trasportato su ferro. Di contro, il numero di automezzi processati a Fernetti èrisultato di gran lunga superiore, giacché per il solo flusso in export di SAMER si stima un volume ditraffico intorno alle 25.000 unità rotabili (2009), a testimonianza della specializzazione dell’inlandterminal in determinati segmenti e cicli di trasporto.3.2.2 La piattaforma logistica di fernettiLa piattaforma logistica o autoporto di Fernetti è situata sul territorio del Comune di Monrupino a circa15 Km dal porto di Trieste. Il terminal è collegato alla viabilità di grande scorrimento ed è raccordato(stazione di Villa Opicina) alla linea ferroviaria nazionale tramite binario non elettrificato.Il terminal di Fernetti occupa complessivamente una superficie di circa 25 ettari ed è suddiviso in duemacro aree operative:  la prima, ovvero l’area “A”, è dedicata ad attività di autoporto su spazi di piazzale che ammontano a circa 130.000 mq;  la seconda, l’area “B”, è raccordata alla ferrovia ed ospita due magazzini, per uno spazio coperto intorno ai 25.000 mq, gestiti dalla società Terminal Intermodale di Trieste - Fernetti S.p.a. perporto di Trieste, ma che tuttavia esercitano un condizionamento nell’ambito dei trasferimenti fra porto e inlandterminal. 3-14
  • 19. conto terzi. Parte degli spazi di quest’area, inoltre, sono ceduti in locazione a terzi operanti nelcomparto dell’autotrasporto e in quello del trasporto containerizzato, nonché nellacommercializzazione di autovetture destinate all’esportazione. 3-15
  • 20. 3.2.3 PlanimetriePlanimetria del terminal di Fernetti AREA OPERATIVA “B” AREA OPERATIVA “A” Figura 1 - Planimetria del terminal di Fernetti 3-16
  • 21. Planimetria del porto di trieste Figura 2 - Planimetria del porto di Trieste 3-17
  • 22. 3.2.4 I flussi di trasporto su gommaPer quanto concerne i carichi containerizzati che, come anticipato, rappresentano una quota esigua deltotale del movimentato da Fernetti, l’autoporto svolge la funzione di piattaforma logistica distributiva.Infatti, per tale tipologia di merce, non si verifica un puro cambio di modalità di trasporto – come avvieneper gli usuali interporti e retroporti – ma una vera e propria rottura di carico e un conseguente cambio dimezzo di trasporto.Più specificatamente, la merce destinata all’export – ovvero a essere imbarcata in porto – giunge inautoporto sfusa o pallettizzata e qui viene containerizzata; viceversa, per il ciclo di import, la merce arrivaall’interno di container dal porto di Trieste a Fernetti e, all’interno degli spazi dell’autoporto, viene estratta,pallettizzata e inoltrata sul territorio verso le destinazioni finali, generalmente il Nord Italia.Il ciclo in importIl processo della merce in import ha inizio con la comunicazione all’autoporto (in genere con circa 15 giornidi anticipo) da parte dello spedizioniere dell’arrivo della nave.A fronte di ciò, si predispone e invia all’Agenzia delle Dogane il manifesto nave delle merci in arrivo, sullabase del quale si procede alla convalida e quindi allo svincolo dei carichi da parte dell’agentemarittimo/spedizioniere (contropolizza, delivery order).Parallelamente a queste attività viene effettuata la movimentazione dei contenitori e il relativoposizionamento a piazzale, ambito in cui i carichi restano in attesa del deflusso verso Fernetti tramite mezzidi trasporto su gomma.A questo fine, occorre elaborare l’apposita documentazione (T1 e visto a uscire), che consente ai mezzi ditrasporto di oltrepassare il varco portuale e dirigersi verso l’inland terminal.Per essere accettati nell’autoporto, questi ultimi necessitano del visto ad entrare rilasciato dalla guardia diFinanza posta in prossimità del varco autoportuale, oltrepassato il quale si completano le operazioni volteallo svincolo doganale.Nell’ambito della piattaforma logistica, i carichi vengono movimentati tramite reach stacker e possonoessere o collocati nelle aree di stoccaggio del terminal, oppure de-containerizzati, pallettizzati e inoltrati,generalmente tramite automezzi, verso le destinazioni di consumo dislocate sul territorio.Il ciclo in exportPer ciò che concerne il flusso in export, il processo prende avvio con l’arrivo dell’automezzo a Fernetti e conil relativo riempimento dei container che, successivamente, vengono caricati sui suddetti mezzi ditrasporto. 3-18
  • 23. In linea di massima, nell’intervallo temporale che intercorre fra queste ultime due operazioni, avviene laprenotazione (via mail) – vale a dire il booking – nonché l’espletamento delle pratiche doganali, al terminedelle quali vengono consegnati i relativi esiti (bolletta doganale e modulo di booking), che consentonoall’automezzo di dirigersi verso lo scalo marittimo di Trieste.L’ingresso nel porto è subordinato all’elaborazione del visto a entrare, documentazione che permette diraggiungere l’area del terminal d’imbarco, dove la merce viene scaricata o stoccata a piazzale in attesa dellarelativa partenza.3.3 Flussi di import/export dei container tra le zone di porto e retroportoL’introduzione delle tecnologie previste da slimTRUCK permetterà di rivedere il processo del trasporto sugomma, rendendo più snelli e veloci i processi di trasferimento delle merci, garantendone nel contempo lasicurezza e aumentando la tracciabilità.Nelle sezioni che seguono, sono descritti i nuovi flussi proposti, sia di export che di import.3.3.1 Il flusso in export: merce containerizzataIl flusso del processo di export dei container è illustrato nella figura che segue:Export - ToBe: Container Cliente Prenotazione servizi da MarketPlace Parcheggio a Motrice piazzale Trasporto merce Entrata in punto al porto franco Autotrapsortatore Arrivo Stock a piazzale Merce Containerizzata (container carico) Stock a Non containerizzata magazzino Stock a piazzale Container vuoto (container vuoto) Spedizioniere Staff autoporto Rilevamento Sì accesso Applicazione OBC Riempimento Carico su camion Associazione Pianificazione container sigilli/OBC/motrice erogazione servizi Consegna Prenotazione con Esecuzione documentazione agente marittimo pratiche doganali all’autista Operatore Scarico sul (TMT) Imbarco merce piazzale Dogana/ Finanza Applicazione sigilli SVAD controllo Controllo merce Controllo ingresso elettronici merce in porto Figura 3 - Il flusso proposto per lexport 3-19
  • 24. Prenotazione servizi da MarketPlaceIl MarketPlace è il primo e principale punto di accesso al sistema. Attraverso il MarketPlace fornitori efruitori dei servizi si incontrano. L’analisi delle caratteristiche del MarketPlace e dei servizi che vi dovrannoessere gestiti è oggetto di un pacco di lavoro ad hoc, ma in questa fase si può già ipotizzare che si potrà:  prenotare lo stoccaggio di container in aree portuali o retroportuali  prenotare il servizio di riempimento di un container  prenotare il servizio di trasporto tra porto e retroporto  prenotare il servizio di trasporto della merce dalla propria sede sino al porto o al retroporto  rendere disponibile a sistema la documentazione necessaria (in formato elettronico) o fornire le indicazioni necessarie affinché il sistema sia in grado di ottenerla da altri sistemi con i quali è in grado di dialogareIn fase di analisi del MarketPlace, si considererà anche l’opportunità che, a fronte della prenotazione di unservizio sul portale, il sistema esegua in maniera automatica (pur con il consenso dell’utente) laprenotazione di ulteriori servizi a valle, interfacciandosi con altri sistemi. Per esempio: a fronte dellaprenotazione di un servizio trasporto tra retroporto e porto, il sistema potrebbe incaricarsi di effettuare laprenotazione del posto in area portuale o la richiesta della disponibilità del container vuoto.Il portale fornirà anche la data di erogazione dei servizi richiesti (se non specificata dall’utente) o laconferma dell’erogazione il servizio nei tempi indicati dall’utente. La data di erogazione del servizio fornitain questa fase all’utente, costituirà un vincolo per il componente di pianificazione delle attività, per il qualeil MarketPlace costituirà una delle fonti di dati in ingresso: dal MarketPlace arriveranno l’elenco dei servizirichiesti (la cui erogazione dovrà essere pianificata) e i vincoli di schedulazione costituiti dalla risposta dataal cliente in fase di prenotazione relativamente alla erogabilità dei servizi richiesti nei tempi e modirichiesti.Dati in ingresso. I dati necessari alla richieste di prenotazione dei servizi saranno determinati in fase dianalisi del MarketPlace, in funzione dei servizi che si sceglierà di rendere disponibili. Dovrà comunqueessere prevista la possibilità di fare l’upload della documentazione di supporto necessaria. In particolare, sipotranno includere informazioni utili per snellire le attività a valle, come per esempio la targa del mezzoassegnato al trasporto del container.Quando non immediatamente disponibili, i dati potranno essere integrati in fasi successive.Dati in uscita. Elenco di tutte le richieste di prestazioni corredate dalle date richieste e le date confermate,dall’eventuale esecutore assegnato - nel caso in cui il servizio possa essere erogato da più fornitori 3-20
  • 25. alternativi e il cliente ne abbia scelto uno - dai documenti e dalle informazioni per i processi che dovrannoessere attivi a valle - questi processi saranno individuati in fase di analisi del MarketPlace.Responsabile dell’attività. Il responsabile di questa attività è il cliente finale che richiede la prenotazione diqualche prestazione attraverso i servizi messi a disposizione dal sistema, attraverso il suo componente diMarketPlace.Strumenti. Come già messo in evidenza, l’attività potrà essere effettuata attraverso le funzionalità resedisponibili dal portale di MarketPlace. L’integrazione del portale con tutti gli altri strumenti e componentidel sistema permette di automatizzare, e quindi rendere più veloci, alcune delle attività a valle. Peresempio: conoscendo la data dell’arrivo del container e/o della merce con cui riempirlo è possibile:  pianificare le attività di riempimento  fornire alle dogane una indicazione di quando i container sono pronti per i controlli  associare la documentazione e le informazioni fornite attraverso il portale – al momento della prenotazione - al trasporto dei container verso il porto  rendere tali documenti e informazioni disponibili ai sistemi che gestiscono i successivi passaggi (slimGATE, etc.)Per quanto il portale risulti efficace nel caso in cui le prenotazioni vengano effettuate per tempo, saràcomunque possibile inserire richieste immediate, facendo così fronte a esigenze dirette nate a valledell’arrivo dei mezzi/container, oltre che ai casi di arrivo senza prenotazione. Anche per questo motivo ilportale sarà dotato di un motore di matching tra domanda e offerta in grado di fornire una rispostaimmediata per quanto riguarda l’eseguibilità di un servizio entro i tempi richiesti.Pianificazione erogazione serviziIl sistema pianifica l’erogazione dei servizi gestiti. La schedulazione delle attività parte dalle richiestepervenute attraverso il MarketPlace o attraverso altre vie, come per esempio i trasporti che arrivanodirettamente all’autoporto “non annunciati”. Inoltre può considerare:  gli arrivi previsti delle navi  lo stato delle pratiche doganali  gli arrivi effettivi in autoporto  la disponibilità di risorse, sia umane che materiali, necessarie allo svolgimento di ciascuna attivitàSulla base di queste informazioni sarà possibile pianificare i tempi di esecuzione di tutte le attività richieste,a partire dal trasferimento dei container verso il porto, tenendo conto dei vincoli del sistema, incluse ledate richieste e/o confermate al cliente per l’esecuzione del servizio. 3-21
  • 26. Il trasferimento dei container potrà essere effettuato sia attraverso un servizio di navetta (in tal caso ilsistema si occupa anche di ottimizzare i trasporti in modo che nessuna motrice viaggi mai scarica, anche neltragitto porto-retroporto) sia avvalendosi di trasporti dedicati: il sistema tiene conto di entrambe lemodalità di trasferimento, in modo da fornire un piano di arrivo al porto ottimizzato. L’algoritmo dipianificazione avrà l’obiettivo di ottimizzare indicatori di perfomance costituiti da misure – che sarannoindividuate e definite in dettaglio in fase di analisi del componente - come il Total Truck Waiting Time (iltempo speso in attesa dai camion), l’Average Truck Waiting Time (il tempo medio speso in attesa daicamion), l’Average Ship Turnaround Time (il tempo medio speso in porto dalle navi), il Dwell Time (il tempodi attesa dei carichi).Accanto all’algoritmo di pianificazione, ne sarà predisposto uno di ripianificazione, con il compito diapportare piccole variazioni al piano a fronte di piccole variazioni dello stato del sistema (es.: ritardi negliarrivi, traffico congestionato, improvvisa mancanza di risorse, ecc.).Dati in ingresso. La pianificazione dello svolgimento dei servizi necessita delle informazioni relative alle daterichieste e/o confermate per ciascun servizio, la distinta base di ciascun servizio erogabile – con evidenzadelle durate, delle risorse e dei materiali richiesti per ciascuna fase – la disponibilità di risorse, più tutti idati che saranno ritenuti necessari a valle dell’analisi di dettaglio.Dati in uscita. Piano di erogazione dei servizi richiesti, piano di attività per ciascuna risorsa, piano didisponibilità dei container per i controlli necessari.Responsabile dell’attività. Il responsabile dell’attività è lo staff dell’autoporto, che deve provvedere amantenere aggiornati i dati necessari al corretto funzionamento degli algoritmi.Strumenti. L’attività sarà svolta dal sistema utilizzando opportuni algoritmi di (ri)pianificazione delle attività.ArrivoÈ l’ingresso in autoporto. A seconda del caso arriva:  una motrice senza carico assegnata al trasporto di un container  un container vuoto  un camion con la merce da caricare in un container  un camion con un container già prontoQuando il trasporto è atteso – sulla base delle prenotazioni ricevute dal MarketPlace o della schedulazionedelle attività – può proseguire all’interno dell’autoporto in base alle indicazioni ricevute in fase di controlloaccesso (si veda la sezione 0). Quando il trasporto arriva non annunciato, sarà compito dell’autista fornire alpersonale dell’autoporto le informazioni necessarie. 3-22
  • 27. Dati in ingresso. I dati in ingresso, se disponibili, sono quelli indicati dal cliente in fase di prenotazione sulMarketPlace e/o quelli ottenuti dal piano di attività schedulate. Come detto e come sottolineato nelseguito, i dati in ingresso e l’eventuale documentazione collegata, per quanto non indispensabili,permettono una più agevole gestione di questa e delle successive fasi del processo.Dati in uscita. I dati in uscita sono quelli forniti dall’autista al personale dell’autoporto, nei casi in cui nonsiano già presenti a sistema o quelli presenti debbano essere integrati.Anche in questa fase dovrà essere prevista la possibilità di caricare a sistema documenti in formatoelettronico.Responsabile dell’attività. Il responsabile dell’attività è l’autotrasportatore (fatta eccezione perl’inserimento delle informazioni a sistema).Rilevamento accessoL’arrivo del mezzo è rilevato all’ingresso in autoporto. La rilevazione potrà essere automatica o manuale.Per la rilevazione automatica, il gate di accesso dovrà essere dotato di sistemi in grado di rilevare targhee/o leggere il codice identificativo del container e/o leggere il tag rfid attivo, che costituisce il sigillo. Ilriconoscimento automatico del mezzo che entra permette di velocizzare considerevolmente le procedureche si devono innescare. Infatti, utilizzando le informazioni ricevute dal MarketPlace, dalla pianificazione edallo stato di avanzamento delle attività, sarà possibile indirizzare automaticamente il mezzo verso l’area acui è destinato. Per esempio: un container da riempire potrà essere indirizzato verso il magazzino in cuisono immagazzinate le merci con cui deve essere riempito, nel caso in cui siano già tutte disponibili, o versol’area di parcheggio, nel caso in cui debba attendere.La rilevazione manuale può essere supportata da dispositivi (es.: palmari) che agevolino il riconoscimentodei mezzi in arrivo. In alternativa, i dati rilevati dovranno essere inseriti a sistema da una postazione fissa,attraverso opportune schede di inserimento dati.Se il mezzo in entrata è atteso, cioè se tutti i dati necessari sono già registrati a sistema, il suoinstradamento è immediato e può essere automatizzato. In caso contrario, cioè se il mezzo non è previsto onon sono presenti a sistema tutte le informazioni necessarie, l’instradamento potrà avvenire solo a valledella dichiarazione a sistema di tutti i dati necessari, senza i quali, sarà parcheggiato in un’area generica diattesa. L’instradamento del mezzo sarà calcolato dal sistema di ripianificazione delle attività sulla base delpiano previsto e dello stato di avanzamento delle attività.Dati in ingresso. I dati in ingresso sono quelli di riconoscimento del container. 3-23
  • 28. Dati in uscita. Oltre all’informazione che il container è arrivato in autoporto, con il conseguente avvio deiprocessi previsti a valle, tra i dati in uscita da questa fase può anche essere incluso un insieme diinformazioni rilevate all’ingresso (se non già note) e che possono essere raccolte, rendendole disponibili alsistema che provvede a utilizzarle nei processi previsti o a reindirizzarle verso altri sistemi/enti, a secondadel caso. L’individuazione di queste informazioni è lasciata a una successiva fase dell’analisi.Responsabile dell’attività. Il responsabile dell’attività è il personale dell’autoporto.Strumenti. Gli strumenti eventualmente in dotazione al personale dell’autoporto per svolgere le attività chedovessero essere richieste, saranno individuati in funzione delle attività stesse, ponendo attenzione adautomatizzarle il più possibile con opportuni dispositivi.Parcheggio a piazzaleAll’arrivo, una motrice destinata al trasporto di un container viene indirizzata nell’area di parcheggio inattesa del momento in cui potrà ritirare il container assegnatole e partire.Ovviamente, nel caso in cui il container sia già pronto, la motrice sarà instradata direttamente verso l’areadi carico, per poter agganciare immediatamente il container e partire.Dati in ingresso. Le informazioni necessarie sono quelle legate alla pianificazione e allo stato diavanzamento delle attività (tra cui, per esempio, l’arrivo della motrice stessa).Dati in uscita. La presenza della motrice parcheggiata a piazzale.Responsabile dell’attività. Il responsabile dell’attività è l’autista.Strumenti. A seconda del grado di automatizzazione dell’autoporto, gli strumenti utilizzati nell’esecuzionedell’attività vanno dalla comunicazione orale da parte del personale dell’autoporto al direzionamentodell’autista attraverso pannelli luminosi.Stock a piazzale (container vuoto)All’arrivo, un container da riempire viene indirizzato nell’area di stock in attesa del momento in cui sarannoeffettuate le operazioni di riempimento.Ovviamente, nel caso in cui tutta la merce da utilizzare sia già disponibile, il container potrà essereinstradato direttamente verso il magazzino di riempimento, per procedere con le operazioni di carico.La motrice che ha portato il container prosegue, a seconda del caso:  uscendo dall’autoporto  parcheggiandosi nell’apposita area (rientrando quindi nel caso discusso nella sezione 0) 3-24
  • 29. Dati in ingresso. Le informazioni necessarie sono quelle legate alla pianificazione e allo stato diavanzamento delle attività (tra cui, per esempio, l’arrivo del container stesso).Dati in uscita. La disponibilità del container.Responsabile dell’attività. Il responsabile dell’attività è l’autista.Strumenti. A seconda del grado di automatizzazione dell’autoporto, gli strumenti utilizzati nell’esecuzionedell’attività vanno dalla comunicazione orale da parte del personale dell’autoporto al direzionamentodell’autista attraverso pannelli luminosi.Stock a piazzale (container carico)All’arrivo, un container già pronto viene indirizzato nell’area di stock in attesa del momento in cui saràinviato al porto.La motrice che ha portato il container prosegue, a seconda del caso:  uscendo dall’autoporto  parcheggiandosi nell’apposita areaDati in ingresso. Le informazioni necessarie sono quelle legate alla pianificazione e allo stato diavanzamento delle attività (tra cui, per esempio, l’arrivo del container stesso e quello della motrice che lodeve guidare).Dati in uscita. La presenza del container in autoporto.Responsabile dell’attività. Il responsabile dell’attività è l’autista.Strumenti. A seconda del grado di automatizzazione dell’autoporto, gli strumenti utilizzati nell’esecuzionedell’attività vanno dalla comunicazione orale da parte del personale dell’autoporto al direzionamentodell’autista attraverso pannelli luminosi.Stock a magazzinoAll’arrivo, i camion che trasportano la merce che deve essere caricata nei container sono indirizzati verso imagazzini in cui devono scaricare la merce trasportata.Dopo aver scaricato, il camion prosegue, a seconda del caso:  uscendo dall’autoporto  andando a posizionarsi nell’area di carico della merce scaricata da un container in arrivo 3-25
  • 30. Dati in ingresso. Le informazioni necessarie sono quelle legate alla pianificazione e allo stato diavanzamento delle attività (tra cui, per esempio, l’arrivo della merce da containerizzare).Dati in uscita. La disponibilità della merce a magazzino.Responsabile dell’attività. Il responsabile dell’attività è l’autista.Strumenti. A seconda del grado di automatizzazione dell’autoporto, gli strumenti utilizzati nell’esecuzionedell’attività vanno dalla comunicazione orale da parte del personale dell’autoporto al direzionamentodell’autista attraverso pannelli luminosi.Prenotazione con agente marittimoLa prenotazione del viaggio sulla nave è effettuata dallo spedizioniere ed è il punto di partenza dell’interoprocesso. Al di là di questo aspetto, questa attività non è di competenza del sottosistema slimTRUCK, èconsiderata qui per completezza di descrizione del sottoprocesso e per mettere in evidenza questo comeun punto di ulteriore automatizzazione del processo nel caso in cui si integrino i sistemi di gestione dispedizioniere, agente marittimo, autoporto.Esecuzione pratiche doganaliL’esecuzione delle pratiche doganali è effettuata dallo spedizioniere, ma non è di competenza delsottosistema slimTRUCK, è considerata qui per completezza di descrizione del sottoprocesso e per metterein evidenza questo come un possibile punto di integrazione tra sistemi slimTRUCK e dogane, che potrebbepermettere una più efficiente organizzazione delle attività in autoporto.Consegna documentazione all’autistaLa consegna all’autista della documentazione di accompagnamento al trasporto non è di competenza delsottosistema è effettuata dallo spedizioniere, ma non è di competenze del sottosistema slimTRUCK, èconsiderata qui per completezza di descrizione del sottoprocesso. Questa attività non potrà essereeliminata dal processo a meno di non dotare il personale degli enti addetti ai controlli (Polizia, Poliziamunicipale, …) lungo le strade di strumentazione in grado di leggere le informazioni sui dispositivi di bordo.Riempimento containerI container che devono essere riempiti sono trasferiti presso il magazzino in cui saranno effettuate leoperazioni. Il trasferimento avviene in base alla pianificazione prevista per le attività, che deve tenere contodella disponibilità del container, della merce da containerizzare e della data prevista per l’imbarco delcarico. 3-26
  • 31. Nel caso in cui ci si possa interfacciare con il sistema delle Dogane, nella schedulazione fine delle attività sipotrà anche tenere conto dello stato di avanzamento delle pratiche doganali, oltre che fornire eventualiinformazioni utili che possono essere raccolte durante il riempimento dei container.Il carico del container in retroporto, permette di evitare l’esecuzione di questa attività direttamente inporto e quindi di liberare aree per altri utilizzi. Inoltre, il carico dei container in retroporto, permette diinviarli in porto all’approssimarsi del momento dell’imbarco, riducendo il tempo di stoccaggio dei containersui moli. Quest’ultima considerazione vale anche per i container già completi: parcheggiarli in retroporto inattesa dell’imbarco riduce le necessità di spazi in porto, aumentando il numero di container che vi puòessere gestito.Dati in ingresso. I dati in ingresso indicano cosa deve essere caricato nel container e da dove deve esserericevuto. Questi dati sono ricavati dal sistema informativo dal componente di pianificazione delle attività,dell’autoporto e/o dal MarketPlace.Nel caso fosse possibile, informazioni potranno anche essere recepite dal sistema informativo delle dogane.Dati in uscita. I dati in uscita sono le dichiarazioni di quanto caricato nei container che possono esserefornite al sistema informativo dell’autoporto, a quello delle dogane, a quello del cliente, dell’armatore o ingenerale a quelli che hanno necessità delle informazioni raccolte. Data la varietà dei possibili fruitori delleinformazioni, le modalità di condivisione potranno essere differenti andando da una comunicazione direttatra i sistemi, all’invio via e-mail, alla disponibilità sul portale del sistema.Inoltre sarà rilevata l’informazione relativa all’associazione tra container e richiesta del cliente.Responsabile dell’attività. L’attività sarà a carico dello staff dell’autoporto, a meno che non sia richiesto delpersonale specializzato per particolari caratteristiche della merce trattata.Strumenti. Gli strumenti necessari allo svolgimento dell’attività si possono ridurre a documenti cartaceiestratti dal sistema o i cui dati saranno successivamente riportati a sistema. Per rendere più efficiente ilservizio, sarà possibile dotare di personale di sistemi (per esempio dispositivi palmari) che permettano lorodi accedere direttamente alle informazioni presenti a sistema e di immettere direttamente quelle da lororilevate.Controllo merceSul container possono essere effettuate le verifiche previste dalle procedure doganali. Le schedulazionidelle attività eseguite dal sistema possono essere utilizzate come input per la pianificazione dellosvolgimento dei controlli, unitamente allo stato delle relative pratiche nell’iter doganale. 3-27
  • 32. Dati in ingresso. I dati che il sistema può fornire in ingresso sono le schedulazioni della disponibilità dicontainer pronti per il trasferimento verso il porto.Dati in uscita. Le informazioni che emergono da questa attività sono quelle legate all’esito dei controlli, chepotranno essere recepite attraverso l’eventuale interfacciamento con il sistema informativo delle dogane oattraverso l’introduzione manuale a sistema delle informazioni raccolte.Responsabile dell’attività. L’attività è a carico del personale delle dogane, fatta eccezione per l’eventuale(se necessaria) introduzione manuale a sistema degli esiti del controllo che sarà a carico del personaledell’autoporto.Applicazione sigilli elettroniciUna volta completati i controlli, il carico è pronto per essere trasferito verso il porto. Al fine di assicurarsiche il container non sia violato, gli verranno apposti dei sigilli elettronici, tag a tecnologia rfid attiva, cherileveranno e segnaleranno le eventuali aperture del container. Finché il container rimane nel piazzale, saràpossibile rilevare le segnalazioni immediatamente o leggendone le registrazioni prima di farli partire per ilporto, in modo da escludere manomissioni.Dati in ingresso. Le informazioni necessarie sono quelle relative all’avvenuto controllo del container.Dati in uscita. A partire dall’applicazione del tag, è sempre possibile rilevare le aperture del container equindi avviare i processi di gestione previsti per tale tipo di emergenza.Responsabile dell’attività. Responsabile dell’attività è il personale delle dogane che ha effettuato ilcontrollo della merce, in modo che l’applicazione del tag possa essere contestuale all’esito positivo delleverifiche.Carico su camionUna volta chiusi, i container possono essere assegnati alla motrice e inviati in porto.L’attività potrà essere svolta quando sono verificati tutti i prerequisiti:  disponibilità della motrice  container pronti, cioè sigillati  documentazione di transito consegnata all’autistaDati in ingresso. Le informazioni necessarie sono quelle relative alla verifica di tutti i prerequisiti elencati.Responsabile dell’attività. L’attività sarà svolta dal personale dell’autoporto. 3-28
  • 33. Associazione tag / OBC / motricePer garantire la sicurezza del trasferimento della merce dal retroporto al porto, i container devono esseresottoposti al controllo del sistema. A questo scopo, contestualmente al carico del container sul camion chelo trasporterà in porto, il gruppo costituito dal(i) container e dalla motrice deve essere registrato a sistema.Pertanto:  il tag è associato al container, oltre che fisicamente anche a sistema, legando i dati identificativi del container a quelli del tag a esso applicato  nel caso in cui non sia già presente (è il caso in cui la motrice appartiene al servizio di navetta per i quali il computer di bordo potrà essere un dispositivo fisso o comunque non rimosso) si o assegna alla motrice un computer di bordo (OBC) o fornisce al sistema l’associazione tra i dati identificativi della motrice e il computer di bordo  si associa i(l) tag al computer di bordo  si verifica il buon esito delle associazioni effettuate2In questo modo, il trasporto è pronto sia fisicamente che nell’ambito del sistema informativo e può essereavviato.Va ricordato che il trasporto è stato pianificato dal sistema, sicché l’associazione dei(l) container allamotrice, il momento in cui questa ha luogo e quello di partenza verso il porto sono definiti nellaschedulazione delle attività. La registrazione a sistema del completamento di tali attività, permette di averesempre presente lo stato di avanzamento delle operazioni e quindi di rischedularle, se del caso.Per quanto in questa fase sia previsto principalmente un passaggio di dati dal campo al sistema, peragevolare l’operatività si potrà prevedere un flusso di dati anche nel verso opposto, permettendoall’operatore di conoscere informazioni utili a decidere se e come effettuare l’attività.Dati in ingresso. I dati necessari a eseguire l’attività sono gli identificativi di tutti i componenti che fannoparte del gruppo, in modo da poterli associare. Per completare il pacchetto informativo presente a sistema,il gruppo potrà venire associato al trasporto schedulato, in modo da seguire correttamente l’esecuzione delpiano predisposto.Dati in uscita. I dati prodotti in questa attività sono quelli risultanti dall’associazione, quindi l’identificazionedel gruppo. Inoltre sarà anche registrata l’informazione che il trasporto è pronto, in modo che i processi daciò dipendenti possano essere attivati.2 Oltre al corretto completamento delle procedure di associazione dei vari dispositivi, il sistema potrà anche fornireinformazioni relative allo stato della documentazione relativa al trasporto e/o al suo iter doganale, che potrà essereverificata prima o dopo l’associazione, in modo da decidere se effettuarla o no e se proseguire con le successiveattività. L’opportunità di implementare tali meccanismi verrà considerata in fase di analisi di dettaglio. 3-29
  • 34. Responsabile dell’attività. Il responsabile dell’attività è il personale dell’autoporto che provvede sia agliaspetti hardware, come l’applicazione dell’OBC, che a quelli informativi, come l’associazione dei varidispositivi.Strumenti. Gli operatori dovranno essere dotati di dispositivi palmari che permetteranno loro di registrare ointrodurre tutte le informazioni previste, oltre che di accedere a quelle che possono essere derivate dalsistema. In assenza di tali dispositivi, i dati relativi al trasporto potranno comunque essere registrati asistema da postazioni fisse, utilizzando le apposite finestre di inserimento dati.Trasporto merce al portoQuando tutti i dispositivi sono stati applicati e le associazioni tra loro e con container e motrice sono stateregistrate a sistema, il trasporto è pronto a partire e partirà, secondo i tempi previsti nella schedulazione.L’uscita dall’autoporto è registrata a sistema secondo le stesse logiche descritte per l’ingresso, fatto salvoche i dati di tutti i componenti del trasporto sono ora già noti.L’applicazione dei dispositivi di controllo garantisce la sicurezza del trasporto, permettendo di conoscernein qualsiasi momento la posizione e lo stato di integrità dei container: il trasporto è sicuro in quantoqualsiasi deviazione dal comportamento previsto è immediatamente segnalata e viene di conseguenzaattivato l’opportuno processo di gestione dell’emergenza. Per questo motivo parliamo di tubo virtuale: iltrasporto si trova in un tubo che lo porta sino al porto, un tubo da cui non può uscire se non agli estremi;nel caso in cui si tenti di rompere il tubo, cioè si tenti di seguire una strada che non conduca al porto,l’evento è segnalato e gestito, in modo che le uscite dal tubo siano impedite. Le uscite dal tubo possonoessere rappresentate da:  prendere una strada non prevista  aperture non previste di un container  blocco imprevisto del trasporto  segnalazione di emergenza da parte del conducente  altro che sarà determinato in fase di analisi di dettaglio delle possibili emergenzeLa rilevazione continua della posizione permetterà anche di supportare il conducente in caso di difficoltà aseguire il tragitto verso il porto.Dati in ingresso. Il trasporto parte secondo il piano schedulato di trasferimenti dei container al porto. Peruna adeguata gestione del trasporto, sono necessarie le informazioni relative al gruppo e la verifica, aintervalli definiti, della posizione e dello stato del trasporto stesso. 3-30
  • 35. Dati in uscita. Durante il viaggio, il trasporto invia al sistema i dati della propria posizione e le eventualisegnalazioni di anomalie o emergenze.Responsabile dell’attività. Il responsabile dell’attività è l’autotrasportatore che conduce il mezzo dalretroporto al porto.Il supporto del sistema permette di coadiuvare il conducente fornendogli assistenza e sicurezza lungo iltragitto.Strumenti. Gli strumenti sono quelli discussi nell’ambito delle attività già descritte in questa e nelle sezioniprecedenti: sigilli elettronici da applicare sul container, computer di bordo, sistema di orchestrazione delleinformazioni, sistema di gestione delle emergenze, sistema di pianificazione dei servizi. Tutti questicomponenti concorrono alla formazione del tubo virtuale che collega retroporto e porto rendendolipraticamente un’unica entità.Controllo ingresso in portoL’arrivo in porto conclude il viaggio del container. L’arrivo in porto è segnalato dalle autorità competenti,ma può anche essere rilevato da:  un gate che rileva il passaggio dei tag  la localizzazione GPS del sistema costantemente informata sulla posizione del trasportoA questo punto i container passano sotto la responsabilità di altri sottosistemi di slimPORT, quelli che sioccupano della gestione del piazzale.Dati in ingresso. Sono i dati relativi alla posizione dei container, sia essa rilevata attraverso la localizzazioneGPS, sia attraverso la rilevazione al gate, sia attraverso l’interfacciamento con i sistemi delle autorità chepreposte alla rilevazioni formale.Dati in uscita. Il dato in uscita è il completamento dell’attività prevista, recepito dal sistema. Ulteriori datipossono essere resi disponibili dal sottosistema agli altri sottosistemi, come per esempio i dati del trasporto(codici container, targa veicolo, molo da raggiungere, ...).Responsabile dell’attività. Dal punto di vista formale, responsabile dell’attività è la Guardia di Finanza chedeve rilevare il “Visto a entrare”.Dal punto di vista del sottosistema, il responsabile è il sottosistema stesso (o quello da cui riceve la notiziadell’ingresso in porto), che rileva il completamento del tragitto.Strumenti. A secondo di chi (persona o sottosistema) effettuerà la rilevazione, lo strumento sarà differente: 3-31
  • 36.  Guardia di Finanza: un sistema di scambio di informazioni con il sistema informativo in cui il “Visto a entrare è registrato”  gate: un sistema di scambio di informazioni tra i sottosistemi di slimPORT  GPS: la normale rilevazione di posizioneEntrata in punto francoIl trasporto entra in punto franco. Questa attività non incide direttamente sui processi gestiti da slimTRUCK.È considerata qui per mettere in evidenza la peculiarità del punto franco, al cui ingresso la merce risultaesportata, a meno di casi particolari.Scarico sul piazzaleL’attività di scarico dei container sul piazzale non è di competenze del sottosistema slimTRUCK, èconsiderata qui per completezza di descrizione del sottoprocesso e per mettere in evidenza che, nel caso incui l’utilizzo dei tag dovesse essere limitato alla sola fase di viaggio, in quest’ambito si dovrà prevedereanche la rimozione e il recupero dei tag stessi.L’attività è responsabilità dell’operatore portuale.SVAD controllo merceAnche questa attività non è oggetto dello studio di slimTRUCK, ed è di competenza delle dogane. Èconsiderata qui per completezza di descrizione del processo.Imbarco merceL’attività di imbarco della merce non è di competenze del sottosistema slimTRUCK, è considerata qui percompletezza di descrizione del sottoprocesso e per mettere in evidenza che, nel caso in cui l’utilizzo dei tagsi esaurisca nell’ambito del porto, durante questa fase si dovrà prevedere anche la rimozione e il recuperodei tag stessi.3.3.2 Il flusso in import: merce containerizzataIl flusso del processo di export dei container è illustrato nella figura che segue: 3-32
  • 37. Import – ToBe: Container Cliente Prenotazione servizi da MarketPlace Autotrapsortat Partenza ore Uscita dal punto Trasporto merce franco in autoporto Carico merce su Staff autoporto Scarico merce a Deposito container Rottura di carico camion o altro magazzino (vuoto) a piazzale container Pianificazione erogazione servizi Rilevamento accesso Deposito container Assegnazione a Container che prosegue (pieno) a piazzale motrice Staff porto Applicazione OBC Associazione sigilli/OBC/motrice Spedizioniere Svincolo in agenzia marittima Sbarco e Operatore posizionamento a (TMT) Carico container piazzale dei su camion container Invio alla dogana Marittima Agenzia del Maniifesto Merci Arrivate (MMA) Dogana/ Finanza Applicazione / Elaborazione Verifica MMA verifica dei sigilli pratica doganale elettronici di importazione e/ o di transito Figura 4 - Il flusso proposto per l’importPrenotazione servizi da MarketPlaceValgono le stesse considerazioni fatte per il caso del flusso in export, tenendo conto che il verso dellamovimentazione è opposto: la partenza di container e merci avviene dal porto e il viaggio poi prosegueverso varie destinazioni.Pianificazione erogazione serviziValgono le stesse considerazioni fatte nell’ambito della descrizione del flusso previsto in export, adeguatealle attività che riguardano il flusso di import.Sbarco e posizionamento a piazzale del containerI container arrivati via nave sono scaricati sul piazzale, in attesa di essere prelevati e trasportati verso la lorodestinazione.Questa attività, considerata qui per completezza, non concerne direttamente slimTRUCK, ma potrebbetrarre vantaggio – così come slimTRUCK stesso – dall’integrazione tra i due sistemi:  slimTRUCK può fornire il piano dei trasporti dei container, permettendo l’ottimizzazione del posizionamento dei container a piazzale  il sistema del terminalista può fornire a slimTRUCK informazioni sulla disponibilità dei container (data e posizione a piazzale), permettendo, se necessaria, la ripianificazione delle attività, di agevolarne lo svolgimento e di avviare i processi previsti a valle dell’arrivo dei container 3-33
  • 38. Invio alla dogana del Manifesto Merci Arrivate (MMA)Questa attività, di competenza dell’agente marittimo, non concerne strettamente il processo di interesseper slimTRUCK; è qui considerata per completezza di descrizione.Verifica MMAAnche questa attività, di competenza delle dogane, non concerne strettamente il processo di interesse dislimTRUCK. In questa fase, slimTRUCK potrebbe trarre vantaggio da un’integrazione con i sistemi delledogane in quanto potrebbe avere informazioni legate ad eventuali vincoli delle merci che neimpediscano/sconsiglino lo spostamento dall’area portuale.L’integrazione tra i sistemi, permetterebbe anche alle dogane di avere il controllo fornito dal slimTRUCK sustato e posizione dei container, sicché, per decongestionare l’area portuale, i container potrebbero esseretrasferiti in retroporto mantenendo il controllo sulla loro integrità e, se successivamente richiesto, riportatiin area portuale, in tempi minimi: l’integrazione tra i sistemi permetterebbe di recepire la richiestaimmediatamente e il ritorno in porto potrebbe essere subito effettuato, avendo sempre mantenuto attivisigilli e computer di bordo in modo da garantire l’integrità per tutto il tempo necessario.Applicazione/verifica dei sigilli elettroniciPer questa attività valgono le considerazioni fatte relativamente al processo proposto per l’export.In aggiunta a quanto detto là, per l’import potrebbe nascere l’esigenza del solo controllo dei sigillielettronici, nel caso in cui i container siano già sigillati nel porto di partenza.Anche in questo caso, l’attività non riguarda direttamente slimTRUCK, ma l’integrazione tra i sistemipotrebbe permettere a slimTRUCK una miglior pianificazione delle attività e quindi un’esecuzione piùefficiente dei processi previsti.Svincolo in agenzia marittimaAnche questa attività, di competenza dello spedizioniere, non concerne strettamente il processo gestito daslimTRUCK. Ripercussioni su questo processo si potrebbero avere nel caso in cui si stabilisse un livello diintegrazione tra i sistemi, sicché l’avvenuto svincolo è recepito immediatamente da slimTRUCK che puòutilizzare l’informazione nell’ambito della (ri)pianificazione dei servizi al fine di aumentare la qualità el’efficienza del processo.Carico container su camionPer questa attività valgono le stesse considerazioni fatte per il processo di export, tenendo presente cheora l’attività è svolta dal personale del porto. 3-34
  • 39. Applicazione OBC Associazione sigilli/OBC/motriceValgono le stesse considerazioni fatte per il flusso in export, tenendo conto che l’applicazione dell’OBC sirende necessaria nel caso in cui non sia attivo o non si utilizza un servizio di navetta tra porto e retroporto.Uscita dal punto francoCome nel caso dell’entrata, questa attività non incide direttamente sui processi gestiti da slimTRUCK. Èconsiderata qui per mettere in evidenza la peculiarità del punto franco, a Trieste.Trasporto merce in autoportoValgono le stesse considerazioni fatte per il percorso inverso.Rilevamento accessoValgono le stesse considerazioni fatte nel caso del processo di export.Elaborazione pratica doganale di importazione e/o di transitoIl tubo virtuale, assicurando l’integrità del trasporto, garantisce che il container arriva in autoporto nellostesso stato in cui è stato sbarcato dalla nave. In questo modo, risulta possibile spostare i controlli el’elaborazione delle pratiche doganali in retroporto.Questa attività è di competenza delle dogane, sicché slimTRUCK non può gestirla nell’ambito del processo,ma può, nel caso in cui si possa stabilire un’integrazione tra i sistemi, ricevere informazioni che permettonodi aumentare l’efficienza del processo, pianificando adeguatamente le altre attività previste. In particolare:l’informazione relativa alla necessità di effettuare un controllo e alla sua avvenuta esecuzione permette dischedulare in maniera precisa le attività a valle, attivando tutti i processi del caso.Viceversa, slimTRUCK può fornire la pianificazione (e lo stato di avanzamento) dei trasporti, in modo dapermettere anche una pianificazione dei controlli.Scarico merce a magazzinoCompletate le pratiche doganali, il container può essere instradato verso l’area in cui sono previste lesuccessive attività.Nel caso in cui il suo carico debba essere inviato a destinazione in parti, il container viene aperto e il suocontenuto scaricato a magazzino, da dove sarà poi caricato sui camion che lo porteranno a destinazione.Nel caso in cui i camion siano già presenti, il passaggio attraverso il magazzino potrà essere evitato.In questa fase, se previsto, saranno recuperati i tag e il computer di bordo.Dati in ingresso. I dati necessari allo svolgimento di questa attività sono: 3-35
  • 40.  le richieste provenienti dal MarketPlace e/o veicolate dal piano delle attività  l’esito delle pratiche doganali  la disponibilità delle risorse e dei documenti necessariDati in uscita. A valle dell’operazione di scarico, a sistema sarà registrata l’informazione che la merce è amagazzino o che è stata spostata sui camion, in tal caso si potrà avere anche l’informazione relativaall’avvenuta uscita dei camion dall’autoporto.Responsabile dell’attività. Il personale dell’autoporto.Strumenti. Dal punto di vista del sistema, l’attività in sé non richiede particolari strumenti, fatta salva lapossibilità di dichiarare a sistema l’avvenuto svuotamento del container e il carico a magazzino della merce.La dichiarazione potrà essere effettuata anche da postazioni fisse attraverso delle schede di inserimentodati.Deposito container (vuoto) a piazzaleUna volta scaricato, il container viene parcheggiato a piazzale, nell’attesa di essere trasportato versoun’altra destinazione, eventualmente con un nuovo carico stipatovi in autoporto.In questa fase, se previsto, saranno recuperati i tag e il computer di bordo.Dati in ingresso. L’informazione necessaria all’attività è quella che il container è stato vuotato.Dati in uscita. Risultato dell’attività è l’informazione che il container vuoto è disponibile in area diparcheggio.Responsabile dell’attività. L’attività è di competenza del personale dell’autoporto.Strumenti. Anche in questo caso, sono necessari strumenti per la dichiarazione del posizionamento apiazzale del container. La dichiarazione potrà essere effettuata anche da postazioni fisse attraverso delleschede di inserimento dati.Carico merce su camion o altro containerLa merce depositata a magazzino viene caricata sui camion che la porteranno a destinazione.Dati in ingresso. Le informazioni necessarie a pianificare e svolgere questa operazione sono:  la disponibilità della merce da caricare  la presenza del camion che deve portarla via  la disponibilità di risorse per effettuare l’operazione 3-36
  • 41. tutte informazioni che possono essere rese disponibili al sistema.Dati in uscita. A conclusione dell’operazione, al sistema sarà notificato l’avvenuto carico del camion econseguente scarico del magazzino.Responsabile dell’attività. L’attività è di competenza del personale dell’autoporto.Strumenti. Gli strumenti necessari sono quelli richiesti per dichiarare l’avvenuto riempimento, che sipossono ridurre a una scheda di inserimento dati su una postazione fissa.Assegnazione a motriceNel caso in cui il container debba proseguire il suo viaggio integro, sicché è stato depositato a piazzalesenza essere aperto, viene caricato su una motrice e inviato a destinazione.Dati in ingresso. Le informazioni necessarie a pianificare e svolgere questa operazione sono:  la disponibilità del container a piazzale  la presenza della motrice  la disponibilità di risorse per effettuare l’operazionetutte informazioni che possono essere rese disponibili al sistema.Dati in uscita. A valle dell’operazione potrà essere registrata a sistema l’informazione che il trasporto èstato predisposto.Responsabile dell’attività. L’attività è a carico del personale dell’autoporto.Strumenti. Gli strumenti necessari sono quelli richiesti per dichiarare l’avvenuto riempimento, che sipossono ridurre a una scheda di inserimento dati su una postazione fissa.PartenzaIl trasporto parte per la sua destinazione.Dal punto di vista della rilevazione dell’uscita, valle quanto detto a proposito dell’arrivo per il flusso diexport, fatto slavo che ora il mezzo e tutti gli altri componenti del trasporto saranno sicuramente giàregistrati a sistema.3.4 Tubo virtualeGli obiettivi del progetto prevedono la realizzazione di un cosiddetto sistema “tubo virtuale”. Si tratta di unsistema sicuro ed efficiente di trasferimento su gomma di container nella tratta Porto di Trieste-Autoportodi Fernetti allo scopo di ottimizzare il flusso delle merci e decongestionare l’area portuale, affidando 3-37
  • 42. l’espletamento di tutte le necessarie procedure doganali direttamente al retroporto. Questo “tubo virtuale”è costituito da una serie di componenti che interagiscono tra di loro:  un’area MarketPlace, a disposizione degli operatori di mercato, che ha lo scopo di offrire, vendere e richiedere servizi di stoccaggio o spostamento della merce;  funzionalità di gestione documentale che consentono di espletare online anche le pratiche doganali o altre questioni amministrative;  di un sistema HUB per l’integrazione delle informazioni e dei flussi gestionali tra operatori e l’integrazione con la vera e propria piattaforma di monitoraggio e controllo,  di un modulo di generazione/gestione dei piani di viaggio;  un sistema di tracciamento del mezzo e dei carichi su strada tramite opportuni apparati di bordo e degli strumenti/metodologie di supporto alle decisioni per la gestione dei flussi porto - retroporto (mira a garantire l’ottimizzazione degli spostamenti attraverso l’utilizzo di simulazioni dei flussi e dei movimenti).Gli obiettivi di progetto impongono necessariamente uno studio mirato alla definizione di nuovi processi ealla ridefinizione delle norme e procedure doganali. La realizzazione del “tubo virtuale” deve perciògarantire i necessari requisiti di efficienza e sicurezza in quanto, nel caso in esame, la tratta porto di Trieste-retroporto/autoporto di Fernetti deve necessariamente essere considerata come un’unica “area doganale”.A supporto delle operazioni del sistema e per consentire il dialogo di tutte le componenti vieneimplementato un sistema di comunicazione composto da una combinazione di reti wireless e sistemi dicomunicazione satellitare, opportuni sistemi di monitoraggio e di sicurezza.Tale sistema di comunicazione a supporto costituisce l’infrastruttura logico/fisica di comunicazione cheabilita il flusso informativo tra le diverse componenti del “tubo virtuale” assicurando il correttointerfacciamento tra il sistema di gestione e controllo, l’hub informativo, e i sistemi disegnalazione/tracciamento dislocati sul veicolo (sensoristica intelligente, sigilli elettronici, dispositiviautonomi per il tracking, ecc.).L’infrastruttura consente la raccolta dei dati dal campo, la diffusione di informazioni di servizio anche subase singolo utente e l’accesso alla base di dati ai soggetti preposti all’amministrazione del sistema e allagestione dei clienti/utilizzatori del sistema. Lo schema logico/funzionale dell’architettura complessiva diriferimento è riportato nella figura seguente 3-38
  • 43. Amministratori Clienti/Utilizzatori Management Layer Controllo degli Gestione della Risk Management accessi sicurezza Risk Assessment Interconnection Layer Risk Mitigation Physical Layer Security Policy Zigbee GSM/UMTS Opt/Eth LAN WLAN RFID GPS Information  Processing  Transmission Dispositivi autonomi Sensori a bordo Sigillo elettronico Dati  Storage di monitoraggio del veicolo trattati User … Web Database GIS  Access rights … Server Server Server control Figura 5 - Schema logico di riferimentoIl sistema “tubo virtuale” ha una struttura multi-layer interconnessa che rispecchia la classica pilaprotocollare ISO/OSI e realizza la comunicazione tra le differenti componenti del sistema. Il livello fisico ècostituito da una serie di interfacce di comunicazione, afferenti a standard con caratteristiche trasmissivedifferenti, che consentono di trasferire bidirezionalmente le informazioni tra i dispositivi fisici dislocati on-the-field (dispositivi autonomi di monitoraggio, sensoristica a bordo del veicolo, sigilli elettronici, ecc) e ilivelli superiori preposti all’elaborazione di tali informazioni. Il layer intermedio (interconnection layer)espleta appunto funzioni di interconnessione seamless tra le differenti interfacce presenti nel layer fisicoabilitando il livello superiore (management layer) di comunicare in maniera trasparente e attraverso lesuddette interfacce eterogenee con i dispositivi di monitoraggio e raccolta dei dati.Tale livello superiore gestisce l’intera piattaforma “tubo virtuale” garantendo l’accesso alla base dati daparte di clienti del servizio, utilizzatori e amministratori del sistema, espletando il controllo degli accessi,secondo una policy di sicurezza predefinita, e implementando un sistema di gestione dellesegnalazioni/eventi critici che possono verificarsi durante il trasferimento delle merci all’interno delpercorso individuato.In tale contesto, il sistema di comunicazione ha l’obiettivo di supportare le complesse funzionalità del “tubovirtuale” abilitando la trasmissione di dati tra le differenti componenti e attori del sistema.Attualmente, il traffico delle merci che lasciano il Porto di Trieste su gomma (o che lasciano l’autoporto diFernetti in direzione del porto di Trieste) segue il percorso stradale “quasi obbligato” di circa 26 Km,evidenziato in figura. 3-39
  • 44. Figura 6 - Percorso stradale Porto di Trieste - Autoporto di FernettiIl percorso si compone di una tratta autostradale e di una strada statale sopraelevata. La strada statale (SS202 Triestina) collega il porto di Trieste con l’entroterra carsico fino al termine del raccordo autostradaleproveniente da Sistiana. La SS202, nel tratto a 2 corsie di marcia per carreggiata, è parte della cosiddettaGrande Viabilità Triestina.Il tratto finale della GVT di 3.45 km, che si sviluppa quasi interamente in 2 gallerie (Galleria Carso, 2.848 min direzione Lisert e 2.819 m in direzione Trieste, e la Galleria Cattinara 292 m in entrambe le direzioni), èstato completato nel 2008. Questultimo tratto è stato numerato provvisoriamente come NSA314 (NuovaStrada Anas) ed è classificato in parte come strada extraurbana principale in parte come autostrada. Nelnovembre 2008 è stato aperto al traffico, completando la GVT, il tratto finale (NSA314) da Padriciano aCattinara che consente di unire con una unica strada a 4 corsie, senza soluzione di continuità, lautostradaA4 al porto di Trieste, attraverso la SS202, il RA13 e la NSA314, come riportato nella figura seguente. 3-40
  • 45. Figura 7 - Grande Viabilità Triestina (GVT)Per quanto riguarda le gallerie presenti nel tratto indicato con RA13 la situazione è la seguente:  Galleria Prosecco (879 m)  Galleria Fernetti (388 m)  Galleria Trebiciano1 (90 m)  Galleria Trebiciano2 (90 m)  Galleria Padriciano (64m)Di queste, solo le ultime 3 interessano direttamente il percorso del “tubo virtuale”. 3-41
  • 46. 3.6 Architettura di reteIn riferimento allo schema logico-funzionale del “tubo virtuale” è possibile individuare la seguentearchitettura di massima del sistema, nella quale sono stati posti in evidenza i segmenti rice-trasmissivioggetto di analisi che costituiscono il sistema di comunicazione a supporto. SISTEMA HUB GATEWAY DI Teorema T&T GSM/GPRS/UMTS PC PC GESTIONE IP (xDSL/FO) GSM/GPRS/UMTS GPS Motrice DOGANA DOGANA Container Container Computer di Operatore Postazione Tag Tag Dispositivo PC bordo Locale WLAN IEEE 802.11 b/g/n ZigBee (IEEE 802.15.4) Figura 8 - Architettura del sistema di comunicazione a supportoI segmenti rice-trasmissivi che caratterizzano il sistema di comunicazione a supporto sono i seguenti  Tag1/Tag2 - Computer di bordo (LAN)  Operatore Portuale/Doganale - Postazione Doganale Locale (LAN)  Postazione Doganale locale - Gateway T&T (WAN)  Gateway T&T - HUB Teorema (WAN)  Computer di bordo - Gateway T&T (WAN)3.6.1 Tag1/Tag2 - Computer di bordoIl computer di bordo installato nella motrice dall’operatore Portuale/Doganale e la coppia di Tag installatiuno per container trasportato costituiscono una rete locale. La rete deve garantire continuità dicomunicazione tra i tre elementi coinvolti, per ovvie ragioni di sicurezza; l’integrità della rete Tag1 - Tag2 -Computer di bordo, così come quella dei sigilli elettronici posti a controllo dei meccanismi di apertura devenecessariamente essere continuamente verificata durante tutto il tragitto Porto-Retroporto allo scopo diimpedire operazioni non autorizzate sia sui dispositivi che sui container. 3-42
  • 47. La rete LAN descritta deve necessariamente essere di tipo wireless a corto raggio, anche per limitare alminimo l’invasività delle operazioni di installazione dei dispositivi sul mezzo di trasporto e sui container e, alcontempo, la complessità percepita dall’operatore preposto a detta installazione. Il volume del traffico datigenerato all’interno della suddetta rete LAN è piuttosto limitato e il data rate minimo garantito dalcollegamento è stimabile intorno ai 100 Kbps.Sulla base dei requisiti di carattere generale si ritiene opportuno implementare tale rete in tecnologiaZigBee (basata su standard IEEE 802.15.4) nelle bande di frequenza 868.0 - 868.6 MHz (1 canale) o 2.40 -2.48 GHz (16 canali). Tale standard è caratterizzato da  una buona affidabilità delle comunicazioni (immunità alle interferenze presenti nella stessa banda di frequenze) grazie all’utilizzo di tecniche trasmissive a spettro espanso (DSSS - Direct Sequence Spread Spectrum), robuste tecniche di modulazione del segnale (BPSK, O-QPSK) e protocolli anti- collisione di tipo CSMA-CA e GTS,  una buona velocità di trasmissione dei dati (20/100/250 Kbps @ 868.0 - 868.6 MHz o 250 Kbps @ 2.40 - 2.48 GHz),  un range di comunicazione adeguato (qualche decina di metri, a seconda della potenza di trasmissione utilizzata),  un consumo energetico alquanto contenuto grazie a un duty-cycle piuttosto breve (la parte radio resta in modalità sleep a bassissimo consumo energetico per la maggior parte del tempo), potenze trasmissive minime dell’ordine dei -3 dBm (0.5 mW) e sensibilità del ricevitore intorno ai -92 dBm.Si utilizza di un sistema di bordo formato da: 1. un computer di bordo rimovibile da posizionare sulla motrice che “traina” i container, con a. un sottosistema di localizzazione GPS. b. un sottosistema di comunicazione long-range GSM/GPRS. c. un sottosistema di comunicazione short-range basato su wireless Zigbee. d. una batteria di alimentazione del dispositivo. e. un sottosistema di segnalazione luminosa a LED per l’utente. f. un pulsante di allarme a disposizione dell’utente direttamente sul computer di bordo per segnalazioni di emergenza verso la “centrale”. 2. un tag RFID con sistema di comunicazione wireless Zigbee da posizionare su ogni container trasportato.A colloquiare con il sistema di bordo, ci sono tre sistemi di terra: 1. un dispositivo portatile rugged di tipo palmare/weareable computer con 3-43
  • 48. a. un sottosistema di lettura di codici a barre. b. un sottosistema di comunicazione short-range wireless Zigbee. c. un sottosistema GPS. 2. una postazione “centrale” costituita da un modulo sw gateway delle comunicazioni long-range GSM/GPRS/UMTS, che colloquia con i sistemi di bordo, con la postazione locale e si interfaccia con il sistema HUB di Teorema engineering. 3. una postazione locale dotata di a. un sottosistema di comunicazione lan/intranet.Questa architettura viene riassunta nell’Architettura SlimTruck, dove rispetto alla terminologia utilizzata:  il sottosistema Zigbee (tag RFID + computer di bordo) di produzione Eurotech rappresenta il sottosistema di comunicazione short-range RFID, tra i tag RFID veri e propri che saranno posti sul/sui container delle merci trasportate dai camion nell’ultimo miglio, e il sistema di gestione dei tag contenuto nel computer di bordo, posto nella motrice. La rete wireless Zigbee mette in comunicazione tra loro il sottosistema Zigbee di bordo (tag RFID + computer di bordo: motrice + container) e il palmare/weareable computer a disposizione dell’operatore di autoporto/porto.  sul palmare/weareable computer, l’operatore di autoporto/porto inserisce i dati dei dispositivi installativi a bordo di motrice e container. Tali dati vengono poi trasmessi via GSM/GPRS/UMTS al modulo sw gateway delle comunicazioni long-range GSM/GPRS/UMTS, che le reinoltra via “internet” alla postazione locale.  la postazione locale riceve le info del palmare dell’operatore (triangolate attraverso il modulo sw gateway delle comunicazioni long-range GSM/GPRS/UMTS) ed effettua l’assegnazione degli identificativi del viaggio, ovvero che il sistema di bordo ad esempio n.3 è stato posizionato sul camion ad esempio con targa XXNNNYY. Questo pacchetto informativo viene reinoltrato, attraverso il modulo sw gateway, sia ai sistemi di bordo, che al sistema HUB di Teorema engineeringIl computer di bordo ha alimentazione autonoma tramite batteria ed è provvisto delle antenne necessarie asostenere le comunicazioni wireless previste. In particolare il computer di bordo comunica in localeattraverso tecnologia Zigbee (interfaccia WSN basata su protocollo 802.15.4) per le operazioni inautoporto/dogana, e comunica in remoto attraverso tecnologia GSM/GPRS/UMTS per ricevere i dati(Vestizione, eventuali segnalazioni attraverso i LED all’autista, …) e trasmettere la propria posizione (subase tempo, con intervallo MAX di trasmissione di 30 sec) ed eventuali allarmi (su base evento).Sono previsti dei LED luminosi per dare all’utente una diagnostica sul funzionamento dell’apparato esull’avvenuta conferma dell’associazione container-computer di bordo. 3-44
  • 49. Inoltre il sistema di bordo si completa con un Pulsante Allarme a disposizione dell’utente per eventualisegnalazioni di emergenza a favore della Centrale/ autorità competenti.L’unità è modulare e garantisce il futuro del progetto rispetto all’evoluzione dei sistemi di comunicazione eposizionamento (ad es: attualmente è disponibile il GPS quale sistema di posizionamento, in futuropotrebbe essere Galileo) semplicemente cambiando il modulo interessato.Principali caratteristiche tecniche del COMPUTER DI BORDO  GSM/GPRS  GPS  WSN interface (based on 802.15.4 protocol)  batteria  memoria (>1Gb)  5 LEDs di segnalazione  1 port for data access  buzzer (opzionale)  accelerometro a 3 assi  predisposizione per accendisigariCaratteristiche fisiche del case del COMPUTER DI BORDO:  case IP54  dimensioni stimate (20 x 10 x 5) cm + eventuali antenne esterne  sistema di aggancio al parabrezza  Etichetta a bar-codeCaratteristiche tecniche TAG  WSN interface (based on 802.15.4 protocol)  batteria  sensore di apertura  LEDs di segnalazioneCaratteristiche fisiche del case del TAG:  case IP54  dimensioni stimate (10 x 6,5 x 4) cm + eventuali antenne esterne  Etichetta a bar-code 3-45
  • 50. 3.6.2 Operatore Portuale/Doganale - Postazione Doganale LocaleL’operatore sul campo, all’atto dell’installazione dei dispositivi, effettua una serie di associazioni  Tag1 ID - Container1 ID - Targa del rimorchio,  Tag2 ID - Container2 ID - Targa della motrice,  Computer di bordo - Targa della motrice,  Tag1 ID - Tag2 ID - Computer di bordoche consentono di definire un gruppo o entità unica che deve essere validata dal sistema centrale primadell’inizio del trasferimento dei container all’interno del tubo virtuale. Rimorchio Motrice (Targa) (Targa) Container Container ID2 ID1 Computer di Tag ID2 Tag ID1 Bordo ID Figura 9 - Composizione del gruppoAlle informazioni appena evidenziate vengono aggiunte quelle relative alla documentazione che viaggiaassieme ai container in oggetto. Questi dati (eventualmente integrati con un time-stamp e con le generalitàe dato di localizzazione dell’operatore) devono essere comunicati alla Postazione Doganale Locale etrasferiti successivamente al sistema di gestione del “tubo virtuale” per la definitiva autorizzazione allamissione.Il collegamento LAN appena descritto deve necessariamente essere di tipo wireless a corto/medio raggioallo scopo di fornire all’operatore sul campo la massima libertà di movimento e, all’Autorità Doganale, ilmassimo grado di libertà nell’individuazione della sede più opportuna presso cui collocare la postazionelocale. Il volume del traffico dati previsto all’interno di questo collegamento è medio-basso e il data-rateminimo garantito dal collegamento è stimabile intorno ad 1 Mbps.Sulla base dei requisiti di carattere generale indicati al precedente par.2 si ritiene opportuno implementaretale rete in tecnologia IEEE 802.11b/g/n (WiFi/WiFi+) nella banda di frequenze ISM 2.4000 - 2.4835 GHz (13canali) grazie alle caratteristiche intrinseche che garantiscono  una buona copertura (anche fino a un paio di centinaia di metri, ma in genere dipende dal tipo di antenna installata sui dispositivi), 3-46
  • 51.  estrema maturità tecnologica dello standard,  velocità di trasmissione dei dati piuttosto sostenuta (11/54/600 - 4 flussi spaziali MIMO su canali da 40 MHz, modulazione 64QAM e FEC a rate 5/6 - Mbps ideali rispettivamente per lo standard IEEE 802.11b/g/n),  installazione degli apparati a basso impatto,  buona immunità alle interferenze in banda grazie all’adozione di tecniche trasmissive a spettro espanso DSSS (Direct Sequence Spread Spectrum) e OFDM (Orthogonal Frequency Division Multiplexing).3.6.3 Postazione Doganale locale - GatewayI dati raccolti dall’operatore sul campo e trasferiti alla Postazione Doganale Locale devono essere a lorovolta convogliati verso il sistema di controllo e gestione del sistema “tubo virtuale” attraverso un Gatewaypredisposto da T&T presso la propria sede. Attraverso questo link viaggiano i dati relativi al “gruppo”,corredati dalle opportune versioni elettroniche della documentazione di viaggio associata ai containerappartenenti al gruppo stesso.Le due entità in comunicazione sono fisicamente dislocate in posti lontani tra loro per cui è necessariopredisporre una rete WAN (Wide Area Network) che può assumere carattere wireless (rete radiomobileGSM/GPRS/UMTS) o wired (rete IP pubblica/privata). La scelta tecnologica è subordinata alle interfacce dicomunicazione supportate/disponibili nel Gateway di T&T e nella Postazione Doganale Locale.È comunque opportuno evidenziare che un’eventuale interfaccia di tipo radiomobile GSM/GPRS/UMTSsupportata dalla Postazione Doganale Locale, consentirebbe a quest’ultima di svincolarsi dalla necessità diconnettersi in modo wired alla rete IP pubblica dando un ampio grado di libertà alla sua collocazione fisica.Il volume di traffico dati generato dal collegamento è direttamente proporzionale al numero di operatoriportuali/doganali che agiscono contemporaneamente sul campo mentre il data-rate minimo garantito dalcollegamento è stimabile intorno ai 30-70 Kbps.Sulla base dei requisiti di carattere generale indicati al precedente par.2 si ritiene opportuno implementareil collegamento in oggetto usufruendo del servizio radiomobile cellulare in tecnologia GSM/GPRS/UMTS(previa verifica di copertura all’interno del percorso che definisce il “tubo virtuale”).3.6.4 Gateway - HUB sistema di controllo e gestione del “tubo virtuale”Il centro di controllo raccoglie le informazioni provenienti dal campo, le elabora e fornisce le necessarieautorizzazioni al trasferimento delle merci all’interno del tubo virtuale. Il sistema si occupa altresì di gestirele segnalazioni di allarme provenienti dal mezzo durante il trasferimento, e di segnalare a sua volta le 3-47
  • 52. eventuali criticità presenti lungo il percorso prestabilito, all’autista del mezzo, proponendo eventualmenteun itinerario alternativo al quale il mezzo è comunque vincolato ad attenersi.Il volume di traffico generato all’interno del collegamento in esame è direttamente proporzionale alnumero di mezzi contemporaneamente monitorati e può risultare medio-alto. I due sistemi sono, anche inquesto caso, fisicamente dislocati in posti geograficamente differenti per cui si rende necessarioimplementare una rete WAN di tipo wired (come la rete IP pubblica) in grado di supportare un data-ratepiuttosto sostenuto.Il volume di traffico dati generato all’interno del collegamento dipende sia dal numero di operatori presenticontemporaneamente sul campo che dal numero di mezzi che si occupano e si spostano all’interno del“tubo virtuale”. Il data-rate minimo garantito dal collegamento è stimabile intorno ad 1 Mbps.Sulla base dei requisiti di carattere generale indicati al precedente par.2 si ritiene opportuno implementareil collegamento attraverso tecnologie di connessione wired (doppino telefonico xDSL o fibra ottica).3.6.5 Computer di bordo - GatewayIl collegamento deve garantire il corretto svolgimento dell’attività di monitoraggio in tempo reale delveicolo lungo tutto il percorso all’interno del “tubo virtuale”. Ciò implica il trasferimento del dato dilocalizzazione, prelevato dal dispositivo GPS integrato nel computer di bordo (eventualmente corredato daldato relativo alla velocità del mezzo), nonché dei dati di integrità di gruppo (Tag1 ID - Tag2 ID - Computer dibordo ID) e di integrità dei sigilli elettronici situati sui meccanismi di apertura dei containers trasportati,verso il Gateway T&T. Parimenti, il computer di bordo deve recepire eventuali segnalazioni dicontrollo/allarme provenienti dal sistema centrale di gestione del “tubo virtuale” in modo da avvisaretempestivamente l’autista del mezzo circa le problematiche ravvisate.Il collegamento deve necessariamente assumere un carattere geografico, deve essere caratterizzato daelevata affidabilità in rice-trasmissione e, ovviamente deve essere di tipo wireless. Sulla base di taliconsiderazioni, si ritiene opportuno utilizzare la rete radiomobile GSM / GPRS / UMTS. Deve anche essereprevisto un meccanismo di back-up basato su invio / ricezione di SMS, attraverso il quale assicurarecomunque la comunicazione qualora il servizio GPRS / UMTS sia limitato o non disponibile. Nell’architetturaindividuata, il Gateway T&T assume dunque un ruolo fondamentale nel sistema di comunicazione asupporto.Il volume di traffico che caratterizza il collegamento è direttamente proporzionale al numero di mezzicontemporaneamente monitorati ossia, al numero di mezzi che si trovano contemporaneamente nel “tubovirtuale” anche se, la quantità di dati trasferiti da e verso ogni singolo mezzo risulta contenuta. Il data-rateminimo garantito dal collegamento è stimabile intorno ai 30-70 Kbps. 3-48
  • 53. Sulla base dei requisiti di carattere generale indicati al precedente par.2 si ritiene di dover necessariamenteimplementare il collegamento in oggetto usufruendo del pre-esistente servizio radiomobile cellulare intecnologia GSM / GPRS / UMTS (previa verifica di copertura all’interno del percorso che definisce il “tubovirtuale”). In questo particolare caso la scelta tecnologica è quasi obbligata; l’applicazione in oggetto ricadeinfatti nel settore della logistica avanzata (monitoraggio e tracking di mezzi di trasporto che percorronobidirezionalmente il “tubo virtuale”). La soluzione per questo tipo di servizi, largamente sperimentata eadottata, è quella che integra sistemi di navigazione satellitare (GPS / Galileo) con sistemi ditelecomunicazioni radiomobili (GSM / GPRS / UMTS).Tale combinazione tecnologica garantisce un buon livello di affidabilità del collegamento e di qualità delservizio, una copertura a carattere geografico, una velocità di trasmissione adeguata alle applicazioniindividuate e un’estrema maturità tecnologica.L’implementazione di soluzioni di collegamento alternative (ad esempio, disseminare punti di accessowireless lungo il percorso del “tubo virtuale” per garantire la tracciabilità dei mezzi) risulterebbenotevolmente invasiva e anti-economica e determinerebbe un modello complessivo di sistema dicomunicazione a supporto difficilmente esportabile. Uno dei principali obiettivi del sottosistema SlimTruckè infatti quello di fornire una soluzione di base completa e a carattere generale ossia, altamente flessibile, esvincolata dalle singole realtà applicative puntuali. 3-49
  • 54. 4. Analisi Funzionale4.1 Ambiente e strumenti di sviluppoLa realizzazione del software è stata effettuata utilizzando principalmente tecnologie di Microsoft:  L’ambiente di sviluppo scelto è Visual Studio 2010 Ultimate Edition. Si tratta dellultimo IDE creato da Microsoft, per programmatori che sviluppano per piattaforme Windows e .NET Framework 4.0. Esso permette di usare svariati linguaggi di programmazione, tra cui VB.NET, C++, C# ed altri ancora. Inoltre offre la possibilità di creare applicazioni e servizi Web ASP.NET, in C# o in VB.NET. È stato rilasciato il 12 aprile 2010.  Il motore DBMS utilizzato è SQL Server 2008 R2. Si tratta di un DBMS relazionale, meglio noto come Relational Database Management System (RDBMS), prodotto da Microsoft. Nelle prime versioni era utilizzato per basi dati medio-piccole, ma a partire dalla versione 2000 è stato utilizzato anche per la gestione di basi dati di grandi dimensioni.  Per la gestione della comunicazione tra i diversi moduli software si è utilizzato Biztalk Server 2010. Biztalk Server è l’Integration Server di Microsoft e serve per connettere tra loro sistemi, servizi e applicazioni e integrare fra loro informazioni provenienti da diverse sorgenti. Mette a disposizione dello sviluppatore un SDK come estensione dell’ambiente Visual Studio per la realizzazione di progetti utilizzando strumenti visuali.  Il sistema utilizza come host per i servizi web di supporto IIS 7.5. L’abbreviazione sta per Internet Information Services. SI tratta di un complesso di servizi server Internet per sistemi operativi Microsoft Windows. Lapplicazione server non è in grado, di per sé, di eseguire elaborazioni Server- side ma ne delega lesecuzione ad applicazioni ISAPI. Microsoft stessa fornisce una serie di applicazioni tra le quali il modulo per Active Server Pages ed ASP.NET.Per lo sviluppo è stata utilizzata la versione 4.0 di .NET Framework, ovvero l’ultima versione ad oggidisponibile. Si tratta di un framework che fornisce moltissime librerie. Da sottolineare l’utilizzo di WindowsComunication Foundation per l’implementazione dei servizi web, Entity framework per l’implementazionedel layer di accesso ai dati e delle librerie XML per la definizione di classi serializzabili che permettono lacreazione di istanze di documenti xml. EF rappresenta l’ORM di Microsoft che favorisce lintegrazione disistemi software aderenti al paradigma della programmazione orientata agli oggetti con sistemi RDBMS.Inoltre Biztalk Server 2010 supporta la realizzazione di nuove applicazioni solo utilizzando .NET Framework4.0, quindi la scelta è stata obbligata. 4-50
  • 55. 4.2 Cenni all’architettura di Biztalk ServerBiztalk Server è un prodotto Microsoft poco conosciuto orientato alle infrastrutture di tipo SOA.Microsoft BizTalk Server è un middleware (layer di gestione della logica di business) specializzato nellagestione dei processi di business e nella loro integrazione. E infatti un sistema di BPM (business processmanagement) cioè un sistema che lazienda usa per creare un layer di gestione dei flussi di business tra levarie applicazioni esistenti potendo applicare regole e parametri customizabili e monitorabili tramite unsistema di BAM (business activity monitoring). Nel mettere in comunicazione le applicazioni presenti inazienda, BizTalk Server è un EAI (Enterprise Application Integration) e anche un Message Broker poichè ingrado di convertire i vari formati nativi delle applicazioni da lui messe in comunicazioni tramite un sistemadi adattatori. BizTalk Server può funzionare come ESB per creare un infrastruttura SOA (service orientiedarchitecture) in cui far crescere una foresta di servizi interni allazienda o esterni tramite meccanismi diSaaS (Software_as_a_service) o Cloud Computing.Lo scenario, fortemente comune, vede BizTalk in unazienda che dopo aver acquistato/realizzato nel tempovari sistemi come un Mainframe IBM, SAP, Navision, applicazioni web asp.net, jsp/jsf, php, servizi SOAPvari, etc.., si trova nella situazione di dover far coesistere tutti questi sistemi in modo da avere datisincronizzati tra i vari sistemi, o ancora di più rendere possibile che una operazione complessa possarendersi fattibile su più sistemi contemporaneamente senza dover scrivere una applicazione da zeroappositamente per questa funzionalità.La soluzione a breve termine che molti realizzano è quella di scrivere piccole utility di sincronizzazione traapplicazioni varie, o tra database vari, con la necessità col tempo di manutenere sempre più di queste mini-app, cosa che ad un certo punto diventerà collo di bottiglia della soluzione.In questi casi l’impiego di BizTalk rende tutto più facile: BizTalk è una piattaforma evoluta dedicata allEAIche dispone di tutti gli adattatori possibili per dialogare nei vari modi le applicazioni necessitino. 4-51
  • 56. Figura 10 - Architettura di Biztalk ServerBiztalk Server ha un architettura basata sui concetti di pubblicazione e sottoscrizione dei messaggi ed ècostruito interamente usando xml come meccanismo di rappresentazione dei dati. I messaggi vengonoricevuti attraverso le receive port. Ogni receive port può comprendere più receive location associate ad unadapter che permette la comunicazione con un particolare tipo di entità esterna. Il messaggio ricevutoattraversa una pipeline che si occupa delle operazioni di decodifica, disassemblazione, validazione eidentificazione del partner. I messaggi possono quindi subire una trasformazione xslt secondo unaparticolare mappa ed essere infine pubblicati nella message box. La Message Box è un database ad usointerno di Biztalk. Ha un numero elevato di tabelle molte delle quali servono per mantenere messaggiricevuti. Ogni messaggio ha associati dei metadati chiamati Message Context e ogni elemento vienemantenuto da una coppia chiave/valore chiamata Context Property. Ogni messaggio che entra in messagebox si dice pubblicato. Vige una regola secondo la quale i messaggi pubblicati non possono esseremodificati.La sottoscrizione è un meccanismo attraverso il quale le porte e le orchestrazioni sono in grado di ricevere einviare messaggi. Ogni processo Biztalk in esecuzione ha qualcosa chiamato Message Agent responsabiledella ricerca di messaggi che verificano alle sottoscrizioni e instradamento di essi verso l’EPM che gestisce imessaggi e li invia dove devono andare. EPM è il broker fra Message Box e pipeline/port/adapter. Lesottoscrizioni di orchestrazione sono gestite da un sotto-servizio diverso chiamato XLANG/s. Unasottoscrizione è una collection di statement di comparazione conosciuti come predicati che comprendonoproprietà di contesto dei messaggi e i valori specifici alla sottoscrizione Microsoft. I servizi biztalk creanouna subscription nella messagebox chiamando due stored procedure:  Bts_CreateSubscription_{HostName} 4-52
  • 57.  Bts_InsertPredicate_{HostName}I sottoscrittori in possesso di una sottoscrizione valida per un determinato messaggio possono riceverlo èinviarlo alle orchestrazioni o a delle send port. Il processo di invio è simile al processo di ricezione. Imessaggi inviati ad una send port possono essere trasformati secondo una mappa e poi attraversano unapipeline di send in cui sono previste le fasi di validazione, assemblamento e codifica. Al termine l’adapterassociato alla send port provvederà a trasformare il messaggio xml nel formato compatibile in base al tipodi adapter.4.3 Definizione delle entità coinvoltePer descrivere il sistema nella sua totalità si può iniziare elencando come prima entità il nodo rappresenta ilcentro di instradamento delle comunicazioni. Si tratta dell’hub centrale(HC) oggetto di questa tesi. L’HC ècostituito da un orchestratore sviluppato con BizTalk, il quale si occupa di ricevere e veicolare i messaggiricevuti dagli altri componenti del sistema. Può essere visto dall’esterno come una facciata di servizi chepermettono a tutte le altre componenti di scambiarsi messaggi in modo sincrono o asincrono. Le variecomponenti del sistema non comunicano direttamente tra loro ma inoltrano tutte le loro richieste all’hubcentrale che si incarica di ricevere i messaggi, procedere ad una eventuale elaborazione e effettuarel’inoltro verso l’entità che le regole di business indicano come destinataria. L’hub è in grado di riceveremessaggi accedendo a file salvati su disco, interagendo con DBMS come ad esempio Sql Server,comunicando con servizi Web utilizzando il protocollo SOAP e approccio REST con tecnologie che rispettanole specifiche di interoperabilità come WCF. L’hub mantiene inoltre un database in cui archivia tutte leinformazioni contenute nei messaggi che transitano secondo una struttura consona all’utilizzo che se nevuole fare. Hub centrale (HC) Componente gestione Gateway Console emergenze (CGE) On Board Palmare Computer (OBC) Figura 11 - Componenti del sistemaL’hub riceve informazioni relative alla movimentazione delle merci dal Gateway. Si tratta di un modulosoftware che ha il compito di mantenere la comunicazione con i computer di bordo applicati ai veicoli 4-53
  • 58. preposti al trasporto dei container e di inoltrare i dati all’hub centrale. Le informazioni trattate riguardanolo stato di attività della strumentazione, la sicurezza delle merci e l’inviolabilità dei container e lecoordinate per la localizzazione geografica. Il gateway mantiene anche la comunicazione con l’operatore sulcampo che ha la possibilità di inviare le richieste di vestizione e svestizione dei gruppi attraverso unpalmare. L’operatore sul campo, mediante palmare, e i computer di bordo comunicano con il Gateway sucanale radiomobile GSM/GPRS/UMTS. Il gateway realizza quindi il collegamento fra strumentazione e hubcentrale. Tutte le comunicazioni che transitano nell’hub e sono rivolte all’OBC devono attraversare ilgateway t&t che si preoccupa di inviare le medesime applicando le politiche di retry verso l’OBC Componente Gestione Gateway t&t Hub Centrale Emergenze Sul campo HUB Centrale (Biztalk Server) Portale emergenze Gateway Spool OBC messaggi Business Rule HUB DB Engine Figura 12 - Architettura delle componentiIl sistema prevede una componente di gestione emergenze(CGE) che riceve costantemente dall’hubcentrale le informazioni trasmesse dal Gateway sullo stato dei convogli e che si riserva di inviaresegnalazioni di allarme in corrispondenza del rilevamento di situazioni potenzialmente pericolose. Il CGE hail compito di identificare e gestire le emergenze di processo. Le emergenze di processo individuate sono:  apertura del container in zona non autorizzata  mancata rilevazione del gruppo (motrice/container)  deviazione da percorso  stazionamento del veicolo  segnalazione di allarme da parte del conducentePer la rilevazione delle emergenze sono previsti due differenti processi che si attivano secondo differentimodalità:  quello di rilevazione dell’emergenza: viene eseguito a evento, quando arriva un nuovo dato da analizzare 4-54
  • 59.  quello di individuazione delle mancate rilevazioni: è eseguito in maniera continuativa, per identificare per tempo la mancanza di una rilevazione prevista Figura 13 - Architettura della componente gestione emergenze4.4 Processi interni all’hubPer quanto concerne lo sviluppo del HC sono stati individuati 3 macro processi:  processo di vestizione  processo di svestizione  processo “on-going” tra la vestizione e svestizione descritti in seguito4.4.1 Descrizione processo di vestizioneLe fasi del processo sono le seguenti: 1. L’operatore sul campo installa i tag RFID sui container e il computer di bordo sulla motrice. 2. L’operatore sul campo utilizzando il palmare acquisisce gli identificativi dei tag RFID (preservando l’ordinamento dei tag) e del computer di bordo. In seguito trasmette via GSM/GPRS/UMTS al modulo Gateway t&t tutte le informazioni relative al veicolo attrezzato (ad esempio la targa, l’identificativo del computer di bordo, l’identificativo dei tag dei container, l’identificativo del container). 3. Il Gateway t&t, attraverso una chiamata WCF, inoltra queste informazioni ad HC in modalità sincrona. 4-55
  • 60. 4. HC genera un nuovo identificativo per il Gruppo (id obc,targa motrice,id dei tag(MAC address),matricola dei container) e risponde alla chiamata precedente. 5. Il Gateway risponde al palmare con l’esito dell’operazione e contestualmente invia al OBC la vestizione. 6. L’operatore sul campo verifica dai LED di stato del computer di bordo che sia stata ricevuta la “Vestizione”, quindi dà l’OK alla motrice. Oppure eventualmente verifica dove la procedura non è andata a buon fine.4.4.2 Descrizione processo di svestizioneLe fasi del processo sono le seguenti: 1. CGE invia, attraverso una porta WCF esposta in Basic-http, l’informazione che un certo gruppo è arrivato alla fine del tragitto. 2. HC, attraverso il gateway, modifica i parametri di configurazione dell’OBC in modo tale da spegnere invio periodico dei messaggi, ma lavorare soltanto sul verificarsi di un evento (es. apertura tag). Così non spreca risorse inviando le informazioni inutili. 3. Con il palmare, l’agente dovrebbe generare la richiesta di svestizione leggendo: tag del OBC, e 1/2 tag RFID. Invia queste informazioni ed aspetta da HC la risposta che la procedura è andata a buon fine. Eventualmente potrebbero esserci degli errori( ad esempio: i tag non sono mai stati abbinati ecc.) 4. Nel caso di esito positivo della precedente, HC invia un messaggio di shutdown del OBC. 5. È rimasto da capire se lo shutdown contemporaneamente significa anche la svestizione oppure bisogna inviare un messaggio di svestizione e poi quello di shutdown.4.4.3 Descrizione processo “OnGoing”Durante il tragitto, ogni 30 secondi (configurabili), l’OBC, attraverso il gateway invia tutte le informazioniriguardo allo stato dei tag RFID ed allarmi. Inoltre, per alcuni allarmi come premuto pulsante ‘panic’, ilmessaggio può partire immediatamente. Per queste informazioni HC ha la porta WCF (net.tcp o WS-http) inascolto per i messaggi che arriveranno attraverso il gateway. Le informazioni, una volta arrivate, vengonoscritte su SQL ed inoltrate verso il CGE mediante una web service esposto dal modulo stesso.Ad ogni invio le informazioni vengono trattarle attraverso il rule engine di BizTalk per agireimmediatamente sul messaggio arrivato. 4-56
  • 61. Nella figura che segue è rappresentato il sistema nella sua totalità: Figura 14 - Sistema completo 4-57
  • 62. 4.5 Definizione dei messaggi scambiatiLa comunicazione fra l’hub centrale e le componenti esterne si distingue in due tipologie di chiamate:  Richieste sincrone: a fronte di un messaggio di richiesta di servizio viene inviato in un intervallo di tempo contenuto un messaggio di risposta. Il chiamante rimane in attesa della risposta per tutto il periodo di elaborazione.  Richieste asincrone: a fronte di un messaggio di richiesta di servizio viene eseguito un insieme di operazioni tra le quali non è prevista una richiesta al chiamante.L’hub è strutturato in modo che tutte le chiamate che non necessitano la risposta (quindi chiamateasincrone) vengano ricevute nel message box ed usando il concetto di sottoscrizione vengano elaborate.Questo comportamento permette di aggiungere o togliere facilmente parti del sistema.I messaggi che prevedono richiesta e risposta vengono definiti all’interno di un unico schema con due rootelement (es: per la richiesta dello stato al Gateway viene definito lo schema del messaggio StatusClaim alcui interno ci sono i due root element Request e Response)4.5.1 StatusDetailsContiene le informazioni sullo stato della strumentazione e dei dispositivi di sicurezza relativi ad un gruppo.Il target namespace associato al messaggio è http://Teorema.slimTruck.BT.Schemas.StatusDetails.Field Name Field Type DescriptionIsActiveGPS Bool Attivo/inattivoIsActiveGSM Bool Attivo/inattivoIsActiveZigBee Bool Attivo/inattivoIsActiveOBCBattery Bool Attivo/inattivoIsActiveFirstTagBattery Bool Attivo/inattivoIsActiveSecondTagBattery Bool Attivo/inattivoIsActiveFirstRFIDLink Bool Attivo/inattivoIsActiveSecondRFIDLink Bool Attivo/inattivoIsActiveAlarmButton Bool Attivo/inattivoIsClosedFirstContainer Bool Aperto/ChiusoIsClosedSecondContainer Bool Aperto/Chiuso4.5.2 StatusMessage (MDS)Contiene le informazioni che descrivono lo stato di un gruppo in un determinato istante temporale. Questomessaggio viene inviato dall’OBC all’hub attraverso il Gateway con una cadenza di 30 secondi 4-58
  • 63. (configurabili). Inoltre, può essere inviato a fronte degli allarmi nel momento della loro generazione (es.pulsante ‘panic’ premuto per 3 volte ecc.). Il target namespace associato al messaggio èhttp://Teorema.slimTruck.BT.Schemas.InternalStatusMessage.Field Name Field Type DescriptionOBCId String Identificativo dell’obcCorrelationId Int Campo per correlazione di messaggi relative a comunicazioni asincroneOperation Int  Invio periodico  Variazione velocità GPS (fermo/vado)  Apertura del carico  lallarme del pulsante  Variazione stato link RFID  Variazione stato GPS  Variazione stato GSM  Variazione stato ZigBee  Richiesta da centrale  Variazione stato batteria OBC  Variazione stato batteria TAG  Variazione associazione  Richiesta non poteva essere inoltrata all’OBC (da concordare con t&t)GroupId String 0 non associato Diverso da 0 significa la presenza dell’abbinamentoSendingDate Datetime Data di invio del messaggioLatitude Float Latitudine in gradi decimaliLongitude Float Longitudine in gradi decimaliXaxisSpeed Float Velocità relativa alla direzione di 4-59
  • 64. marciaYaxisSpeed Float Velocità laterale che determina la curvatura della traiettoria verso destra o verso sinistraDirection Float Direzione della traiettoria in radianti o gradi sessadecimaliStatus StatusDetails Descrizione dei flag di stato4.5.3 InternalStatusMessage (MDSInterno)E’ molto simile a MessageStatus, infatti viene constuito come una mappatura di esso. Aggiunge ai campi giàpresenti una data di ricezione e un identificativo per il messaggio. Il target namespace associato almessaggio è http://Teorema.slimTruck.BT.Schemas.StatusMessage.Field Name Field Type DescriptionOBCId String Identificativo dell’obcCorrelationId Int Campo per correlazione di messaggi relative a comunicazioni asincroneOperation Int Come in MessageStatusGroupId String 0 non associato Diverso da 0 significa la presenza dell’abbinamentoSendingDate Datetime Data di invio del messaggioLatitude Float Latitudine in gradi decimaliLongitude Float Longitudine in gradi decimaliXaxisSpeed Float Velocità relativa alla direzione di marciaYaxisSpeed Float Velocità laterale che determina la curvatura della traiettoria verso destra o verso sinistraDirection Float Direzione della traiettoria in radianti o gradi sessadecimaliStatus StatusDetails Descrizione dei flag di statoReceivingDate Datetime Data di ricezione del messaggio all’interno dell’hub 4-60
  • 65. MessageId String Identificativo del messaggio4.5.4 GroupStatusUpdateMolto simile a MessageStatus. Viene costruito come mappatura di InternalMessageStatus e viene inviatodall’hub alla componente gestione emergenze per aggiornare le informazioni sullo stato di un gruppo.Questo messaggio viene inviato a fronte della ricezione di un MessageStatus inviato dal gateway. Il targetnamespace associato al messaggio è http://Teorema.slimTruck.BT.Schemas.GroupUpdateStatus.Field Name Field Type DescriptionOBCId String Identificativo dell’obcOperation Int Come in MessageStatusGroupId String 0 non associato Diverso da 0 significa la presenza dell’abbinamentoSendingDate Datetime Data di invio del messaggioLatitude Float Latitudine in gradi decimaliLongitude Float Longitudine in gradi decimaliXaxisSpeed Float Velocità relativa alla direzione di marciaYaxisSpeed Float Velocità laterale che determina la curvatura della traiettoria verso destra o verso sinistraDirection Float Direzione della traiettoria in radianti o gradi sessadecimaliStatus StatusDetails Descrizione dei flag di statoReceivingDate Datetime Data di ricezione del messaggio all’interno dell’hubMessageId String Identificativo del messaggio4.5.5 AlarmDetailsContiene le informazioni relative ad una segnalazione di allarme. Il target namespace associato almessaggio è http://Teorema.slimTruck.BT.Schemas.AlarmDetails.Field Name Field Type DescriptionPerformedActivity String nel caso BRE abbia deciso di 4-61
  • 66. inviare email o qualcosa che il sistema è in grado autonomamente da eseguire, quindi va codificato quanto è già stato fattoScheduledActivity String azione come bisogna chiamare 113 – quindi per tutte le azioni che il sistema non è in grado da soddisfareAlarmDate DatetimeSourceSystem String  BRE  GCEStatus String  Aperta  Presa in carico  ChiusaIssueDetail String codifica dei problemi riconosciti dal sistema come: pulsante “panic” premuto 3 volte, OBC non più presente ecc. sarebbe da concordare con GCE4.5.6 AlarmOBCContiene una segnalazione di allarme e il messaggio che l’ha scatenata. Se l’allarme non è stato generatocome conseguenza di un singolo messaggio allora viene riportato il messaggio di stato più recente relativoal gruppo per cui è stata creata la segnalazione. Il target namespace associato al messaggio èhttp://Teorema.slimTruck.BT.Schemas.AlarmOBC.Field Name Field Type DescriptionMessage InternalStatusMessage Messaggio contenente lo stato del gruppoAlarmDetails AlarmDetails Dettaglio del messaggio di allarme4.5.7 AlarmIl target namespace associato al messaggio è http://Teorema.slimTruck.BT.Schemas.Alarm.Field Name Field Type Description 4-62
  • 67. GroupId StringScheduledActivity String azione come bisogna chiamare 113 – quindi per tutte le azioni che il sistema non è in grado da soddisfareStatus String  Aperta  Presa in carico  ChiusaIssueDetails String codifica dei problemi riconosciti dal sistema come: pulsante “panic” premuto 3 volte, OBC non più presente ecc. sarebbe da concordare con GCEMessageId String Identificativo del messaggio che ha originato la segnalazione4.5.8 ErrorDetailsRappresenta un dettaglio di errore. Contiene un codice di errore e una descrizione. Questo schema vieneutilizzato nelle operazioni sincrone all’interno dei messaggi di risposta. Il target namespace associato almessaggio è http://Teorema.slimTruck.BT.Schemas.ErrorDetails.Field Name Field Type DescriptionErrorCode Int o string Valore interno che rappresenta il dettaglio d’errore. Il valore 0 è inteso come operazione eseguita con successoErrorDescription String Descrizione dell’errore4.5.9 StatusClaimMessaggio utilizzato per effettuare una richiesta sincrona dalla console verso l’hub. In input vienespecificato l’identificativo di un gruppo. In output viene riportato un messaggio di stato se la richiesta vieneaccettata o un dettaglio di errore se la richiesta fallisce. Contiene due root elemet che definiscono imessaggi di richiesta e risposta. Il target namespace associato al messaggio èhttp://Teorema.slimTruck.BT.Schemas.StatusClaim.RequestGroupId string Gruppo di cui si vuole ottenere lo 4-63
  • 68. statoResponseMessage InternalStatusMessage Messaggio contenente lo stato del gruppo richiestoErrorDetails ErrorDetails Dettaglio degli errori4.5.10 TTStatusClaimMessaggio utilizzato per effettuare una richiesta sincrona dall’hub verso il gateway. In input vienespecificato l’identificativo di un gruppo e un identificativo di correlazione nel caso la risposta vengaaccettata. In output viene specificato se la richiesta è stata accettata oppure rifiutata da un valorebooleano. Contiene due root element che definiscono i messaggi di richiesta e risposta. Il targetnamespace associato al messaggio è http://Teorema.slimTruck.BT.Schemas.TTStatusClaim.ReqOBCId String OBC di cui si vuole conoscere lo statoTransactionId Int valore per la correlazione fra richiesta e rispostaRespSendingResult Bool Esito dell’operazione4.5.11 ConfigureOBCEventsMessaggio utilizzato per effettuare una richiesta sincrona dalla console verso l’hub. In input vienespecificato l’identificativo di un OBC e il valore degli eventi che si vogliono configurare. In output vienespecificato un dettaglio di errore che descrive l’esito dell’operazione. Contiene due root element chedefiniscono i messaggi di richiesta e risposta. Il target namespace associato al messaggio èhttp://Teorema.slimTruck.BT.Schemas.COnfigureOBCEvents.RequestOBCId String OBC di cui si vuole cambiare la configurazionePeriodicSending Bool Attivo/Inattivo 4-64
  • 69. StatusDetails StatusDetails Configurazione di statoResponseErrorDetails ErrorDetails Dettaglio degli errori4.5.12 TTConfigureOBCEventsMessaggio utilizzato per effettuare una richiesta sincrona dall’hub verso il gateway. In input vienespecificato l’identificativo di un OBC e il valore degli eventi che si vogliono configurare. In output vienespecificato un dettaglio di errore che descrive l’esito dell’operazione. Contiene due root element chedefiniscono i messaggi di richiesta e risposta. Il target namespace associato al messaggio èhttp://Teorema.slimTruck.BT.Schemas.TTCOnfigureOBCEvents.ReqOBCId String OBC di cui si vuole cambiare la configurazionePeriodicSending Bool Attivo/InattivoStatusDetails StatusDetails Configurazione di statoRespErrorDetails ErrorDetails Dettaglio degli errori4.5.13 GetOBCEventsMessaggio utilizzato per effettuare una richiesta sincrona dalla console verso l’hub. In input vienespecificato l’identificativo di un OBC. In output viene riportata la configurazione degli eventi correntidell’obc oppure un dettaglio di errore se la richiesta fallisce. Contiene due root element che definiscono imessaggi di richiesta e risposta. Il target namespace associato al messaggio èhttp://Teorema.slimTruck.BT.Schemas.GetOBCEvents.RequestOBCId String OBC di cui si vuole ottenere la configurazioneResponsePeriodicSending Bool Attivo/Inattivo 4-65
  • 70. StatusDetails StatusDetails Stato dell’obc per cui stata fatta la richiestaErrorDetails ErrorDetails Dettaglio degli errori4.5.14 TTGetOBCEventsIl target namespace associato al messaggio è http://Teorema.slimTruck.BT.Schemas.TTGetOBCEvents.ReqOBCId String OBC di cui si vuole ottenere la configurazioneRespPeriodicSending Bool Attivo/InattivoStatusDetails StatusDetails Stato dell’obc per cui stata fatta la richiestaErrorDetails ErrorDetails Dettaglio degli errori4.5.15 GetGroupIdMessaggio utilizzato per effettuare una richiesta sincrona dalla console verso l’hub. In input vienespecificato l’identificativo di un OBC. In output viene riportato l’identificativo del gruppo associato all’OBC eun dettaglio di errore che descrive l’esito dell’operazione. Contiene due root element che definiscono imessaggi di richiesta e risposta. Il target namespace associato al messaggio èhttp://Teorema.slimTruck.BT.Schemas.GetGroupId.RequestOBCId String Identificative dell’OBC di cui si vuole ottenere il gruppoResponseGroupId String Identificativo del gruppo associato all’obc della richiestaErrorDetails ErrorDetails Dettaglio degli errori4.5.16 TTGetGroupIdIl target namespace associato al messaggio è http://Teorema.slimTruck.BT.Schemas.TTGetGroupId. 4-66
  • 71. ReqOBCId String Identificative dell’OBC di cui si vuole ottenere il gruppoTransactionId Int Identificativo per la correlazione fra la richiesta e il messaggio di stato inviato dal gatewayRespSendingResult Bool Esito del’operazione4.5.17 SetGroupIdMessaggio utilizzato per effettuare una richiesta sincrona dalla console verso l’hub. In input vienespecificato l’identificativo di un OBC e il valore del gruppo a cui si vuole associarlo. In output vienespecificato un dettaglio di errore che descrive l’esito dell’operazione. Contiene due root element chedefiniscono i messaggi di richiesta e risposta. Il target namespace associato al messaggio èhttp://Teorema.slimTruck.BT.Schemas.SetGroupId.RequestOBCId String Identificativo dell’obcGroupId String Identificativo del gruppoResponseErrorDetails ErrorDetails Dettaglio degli errori4.5.18 TTSetGroupIdIl target namespace associato al messaggio è http://Teorema.slimTruck.BT.Schemas.TTSetGroupId.ReqOBCId String Identificativo dell’obcGroupId String Identificativo del gruppoRespSendingResult Bool Esito del’operazione 4-67
  • 72. 4.5.19 DestinationArrivalNoticeMessaggio utilizzato per effettuare una richiesta sincrona dalla componente di gestione emergenze versol’hub. In input viene specificato l’identificativo di un gruppo per segnalare che è si trova all’interno di unazona sicura. In output viene specificato un dettaglio di errore che descrive l’esito dell’operazione. Contienedue root element che definiscono i messaggi di richiesta e risposta. Il target namespace associato almessaggio è http://Teorema.slimTruck.BT.Schemas.DestinationArrivalNotice.ReqGroupId String Identificativo del gruppoRespErrorDetails ErrorDetails Dettaglio degli errori4.5.20 ShutdownOBCMessaggio utilizzato per effettuare una richiesta sincrona dalla console verso l’hub. In input vienespecificato l’identificativo di un OBC e un valore booleano che indica se l’obc deve essere resettatocancellando l’associazione al gruppo. In output viene specificato un dettaglio di errore che descrive l’esitodell’operazione di shutdown. Contiene due root element che definiscono i messaggi di richiesta e risposta.Il target namespace associato al messaggio è http://Teorema.slimTruck.BT.Schemas.ShutdownOBC.RequestOBCId String Identificativo dell’obcDisassembleFlag Bool Valore booleano che indica se lo spegnimento comprende il reset dell’obc(true) oppure no(false)ResponseErrorDetails ErrorDetails Dettaglio degli errori4.5.21 TTShutdownOBCIl target namespace associato al messaggio è http://Teorema.slimTruck.BT.Schemas.TTShutdownOBC.ReqOBCId String Identificativo dell’obcDisassembleFlag Bool Valore booleano che indica se lo 4-68
  • 73. spegnimento comprende il reset dell’obc(true) oppure no(false)RespSendingResult Bool Esito del’operazione4.5.22 DisassembleMessaggio utilizzato per effettuare una richiesta sincrona dal gateway verso l’hub. In input viene specificatol’identificativo di un OBC e di uno o due tag RFID. In output viene specificato un dettaglio di errore chedescrive se l’operazione di svestizione è andata a buon fine. Contiene due root element che definiscono imessaggi di richiesta e risposta. Il target namespace associato al messaggio èhttp://Teorema.slimTruck.BT.Schemas.Disassemble.RequestOBCId String Identificativo dell’obcFirstTagId String Identificativo del primo tagSecondTagId String Identificativo del secondo tag. OpzionaleResponseErrorDetails ErrorDetails Dettaglio degli errori4.5.23 AssembleMessaggio utilizzato per effettuare una richiesta sincrona dal gateway verso l’hub. In input vengonospecificati gli identificativi dei componenti per una richiesta di vestizione. In output viene riportato undettaglio di errore che descrive se l’operazione è andata a buon fine e in caso di successo specifical’identificativo del gruppo creato. Contiene due root element che definiscono i messaggi di richiesta erisposta. Il target namespace associato al messaggio è http://Teorema.slimTruck.BT.Schemas.Assemble.RequestOBCId String Identificativo dell’obcFirstTagId String Identificativo del primo tagSecondTagId String Identificativo del secondo tag. Opzionale 4-69
  • 74. FirstContainerIdentifier String Identificativo del primo containerSecondContainerIdentifier String Identificativo del secondo container. OpzionaleTruckLicensePlate String Targa della motriceResponseGroupId String Identificativo del gruppo creatoErrorDetails ErrorDetails Dettaglio degli errori 4-70
  • 75. 4.6 Funzionalità offerte4.6.1 Ricezione messaggio di stato OBC Gateway t&t HUB Centrale DB GCE (WS) Messaggio di stato (MDS) MDS MDSInterno TTAggiornaStatoTrasporto Figura 15 - Flusso dei messaggi per la ricezione del messaggio di statoL’OBC invia un messaggio di stato (nel formato compatto) verso il Gateway. Una volta ricevuto, il gatewaylo passa a HC attraverso la porta WCF (net.tcp o WS-http binding dipendentemente dal fatto chel’architettura di Biztalk si appoggi su IIS per la comunicazione o esponga i servizi direttamente attraversoBiztalk host). Nella Receive location che accetta il messaggio MDS bisogna aggiungere la mappa che lotrasforma in MDSInterno valorizzando i 2 campi aggiuntivi con il timestamp del elaborazione e GUID cheidentificherà in seguito questo messaggio.Sono presenti 2 porte Send che vengono sollecitate configurando i Filtri nelle porte Send; una per scrivere ilmessaggio sul DB (tabella StatusMessage) ed un altro per informare la CGE. Il web service esposto da CGEsarebbe opportuno che sia di tipologia one-way. In questo modo si potrebbe facilmente creare la mappache trasforma il messaggio MDSInterno in quello che si aspetta WS della CGE (GroupStatusUpdate). Lostesso vale per la stored procedure che avrebbe scritto i dati su SQL.Se dovesse essere necessario analizzare il messaggio attraverso Business Rules Engine (BRE), allora bisognaaggiungere un’orchestrazione con la porta Receive di tipo “Direct bound” e ascoltare per la stessa tipologiadel messaggio che arriva (MDSInterno). Una volta entrata nell’orchestrazione si potrebbe inviare alleapposite regole di business che avrebbero preso in esame le proprietà del messaggio variandone ilcontenuto, oppure aggiungendo i nodi XML all’interno del messaggio stesso per essere post-elaboratidall’orchestrazione.Nel caso le regole di business decidano di, per esempio, inviare l’email a fronte dell’emergenza, allorabisogna inviare sulla porta configurata come “direct bound” messaggio AlarmOBC opportunamente creato. 4-71
  • 76. 4.6.2 Richiesta di stato OBC Console centrale HUB Centrale Gateway t&t OBC RichiestaStatoRequest TTRichiestaStatoReq TTCfgEvtOBCReq TTRichiestaStatoResp Messaggio di stato (MDS) MDS (con Trans ID specifico) RichiestaStatoResponse Figura 16 - Flusso dei messaggi per la richiesta di stato allon board computerOrchestrazione: OBCStatusRetrieve (two-way)Metodo esposto OBCStatusRetrieveMessaggio Input StatusClaimRequestMessaggio Output StatusClaimResponseAll’operatore è permesso di richiedere, attraverso la console applicativa, lo stato di un particolare IDgruppo in modalità sincrona. Questa necessità può essere soddisfatta creando un’orchestrazione two-wayche espone questa funzione (OBCStatusRetrieve). Dal DB attraverso la stored procedure si recupera l’ID delOBC associato al ID gruppo d’interesse e si crea la richiesta TTStatusClaimReq per la successiva chiamata alGateway. Il colloquio con il modulo Gateway diventa sincrono in quanto chiamando l’apposito WCF ritornamessaggio TTStatusClaimResp con esito booleano (true se ha preso in carico la richiesta, false se non riescead inviare il messaggio al gruppo). Questo servizio ha in input ID dell’OBC d’interesse e transaction ID (int)creato da biztalk. Si propone di tenere i transaction ID su DB e “staccare” ogni volta uno nuovo attraverso lastored procedure che dovrebbe ogni volta incrementarlo di 1. Nel caso il servizio del Gateway risponda conesito negativo, allora l’orchestrazione risponde subito al chiamante inviando un codice d’errore coneventuale descrizione.Qualora il servizio risponda con esito positivo alla chiamata, allora bisogna creare la correlazione usandotransaction ID (generato ed inviato prima) ed aspettare un messaggio di tipo MDS che arrivi in modoasincrono. Quando arriva il messaggio con transaction ID aspettato l’orchestrazione continua e risponde al 4-72
  • 77. chiamante con lo stato del OBC. Sarebbe da prevedere un timeout (mediante shape Listen) che qualora ilmessaggio non si presenti entro una certo numero di secondi, allora l’orchestrazione risponde con esitonegativo al chiamante.4.6.3 Segnalazione allarme da parte di CGE GCE (WS) HUB Centrale DB Gateway t&t OBC SegnalazioneAllarme AllarmeOBC Notifica OBC (LED) Accendi LED Figura 17 - Flusso dei messaggi per la segnalazione di un allarmeOrchestrazione: AlarmNotice(one-way)Metodo esposto AlarmNoticeMessaggio Input AlarmCGE a facoltà decide di inviare l’allarme riscontrato. L’orchestrazione prende in esame questo messaggio,recupera attraverso la stored procedure dal DB messaggio (MDSInternal) relativo all’ID gruppo segnalato,impacchetta entrambi e li invia al BRE che può decidere quale azione intraprendere a fronte dell’allarmeriscontrato (eventualmente può decidere di non segnalarlo sulla console). Nel caso BRE decide di segnalarel’allarme, allora lo trasforma nel AlarmOBC e lo invia nella porta di tipo “Direct bound”.4.6.4 Scrittura dell’allarme su SQLQuesta funzionalità permette il salvataggio del messaggio AlarmOBC sulla tabella Alarm. Realizzataattraverso una porta Send che contiene la mappa da AlarmOBC verso un messaggio simile a esso cheavrebbe invocato la stored procedure per salvare i dati sulla tabella. Questa porta dovrebbe sollecitarsiapplicando il filtro sulla tipologia di messaggio AlarmOBC presente nel MessageBox di BizTalk. 4-73
  • 78. 4.6.5 Configurazione eventi OBC Orchestrazione padre Orchestrazione: OrchConfiguraEventiOBC Gateway t&t OBC ConfiguraEventiOBCRequest TTConfiguraEventiOBCReq TTCfgEvtOBCReq TTCfgEvtOBCResp TTConfiguraEventiOBCResp ConfiguraEventiOBCResponse Figura 18 - Flusso dei messaggi per la configurazione degli eventi sullon board computerOrchestrazione: ConfigureOBCEvents (interna)Metodo esposto ConfigureOBCEventsMessaggio Input ConfigureOBCEventsRequestMessaggio Output ConfigureOBCEventsResponseQuesta orchestrazione è interna e non espone la funzione attraverso la porta. È stata intesa per essereutilizzata quando il trasporto arriva alla destinazione.Questa funzione permette di configurare il comportamento dell’OBC riguardo agli eventi per i quali avrebbeinviato il suo messaggio di stato verso l’HC. A fronte della ricezione del messaggioConfigureOBCEventsRequest viene rimappato in TTConfigureOBCEventsReq ed invito al gatewayaspettando la risposta sincrona. Ritorna l’esito e la configurazione al chiamante. 4-74
  • 79. 4.6.6 Get eventi configurati sull’OBC X HUB Centrale Gateway t&t GetEventiOBCRequest TTGetEventiOBCReq TTCGetEventiOBCResp GetEventiOBCResponse Figura 19 - Flusso dei messaggi per ottenere la configurazione degli eventi dellon board computerOrchestrazione: GetOBCEvents (two-way)Metodo esposto GetOBCEventsMessaggio Input GetOBCEventsRequestMessaggio Output GetOBCEventsResponseQuesta funzione permette di ritornare l’attuale configurazione degli eventi per i quali l’OBC avrebbe inviatosuo messaggio di stato verso l’HC. A fronte della ricezione del messaggio GetOBCEventsRequest lo rimappain TTGetOBCEventsReq e invia al gateway aspettando la risposta sincrona. Ritorna l’esito e laconfigurazione al chiamante. 4-75
  • 80. 4.6.7 Get ID gruppo Console centrale HUB Centrale Gateway t&t OBC GetIDGruppoRequest TTGetIDGruppoReq TTGetIDGrpReq TTGetIDGruppoResp Messaggio di stato (MDS) MDS (con Trans ID specifico) GetIDGruppoResponse Figura 20 - Flusso dei messaggi per ottenere lidentificativo del gruppo associato ad un obcOrchestrazione: GetGroupId (two-way)Metodo esposto GetGroupIdMessaggio Input GetGroupIdRequestMessaggio Output GetGroupIdResponseQuesta funzione permette di ritornare l’attuale ID gruppo associato all’OBC. A fronte della ricezione delmessaggio GetGroupIdRequest lo rimappa in TTGetGroupIdReq previo stacco del nuovo Transaction ID dalDB e lo invia al gateway aspettando la risposta sincrona nel formato del messaggio TTGetGroupIdResp. Insostanza questa risposta conterrà l’esito dell’operazione di invio richiesta verso l’OBC da parte del Gateway.Nel caso il servizio del CGE risponde con esito negativo, allora l’orchestrazione ritorna subito al chiamanteinviando un codice d’errore con eventuale descrizione.Qualora il servizio risponda con esito positivo alla chiamata, allora bisogna creare la correlazione usandotransaction ID (generato ed inviato prima) ed aspettare un messaggio di tipo MDS che arrivi in modoasincrono. Quando arriva il messaggio con transaction ID aspettato l’orchestrazione continua e risponde alchiamante con lo stato dell’OBC. Sarebbe da prevedere un timeout (mediante shape Listen) che qualora ilmessaggio non si presenti entro un certo numero di secondi, allora l’orchestrazione risponde con esitonegativo al chiamante. 4-76
  • 81. 4.6.8 Set ID gruppo Orchestrazione: Set ID Orchestrazione padre Gateway t&t OBC Gruppo SetIDGruppoRequest TTSetIDGruppoReq TTSetIDGrpReq TTSetIDGruppoResp SetIDGruppoResponse Figura 21 - Flusso dei messaggi per configurare lidentificativo di un gruppoOrchestrazione: SetGroupId (interna)Messaggio Input SetGroupIdRequestMessaggio Output SetGroupIdResponseQuesta orchestrazione è interna e non espone la funzione attraverso la porta. È stata intesa per essereutilizzata durante il processo della svestizione (settando ID gruppo a 0).A fronte della ricezione del messaggio SetGroupIdRequest lo rimappa in TTSetGroupIdReq e lo invia algateway aspettando la risposta sincrona nel formato del messaggio TTSetGroupIdResp. La risposta delGateway conterrà l’esito dell’operazione d’invio richiesta verso l’OBC.La risposta, indicata prima, verrà rimappata nel SetGroupIdResponse e ritornata al chiamante. 4-77
  • 82. 4.6.9 Trasporto arrivato in destinazione Orchestrazione: OrchArrivoInDe Orchestrazione: OrchConfiguraz GCE DB stinazione ioneEventiOBC ArrivoInDestinazioneRequest ConfiguraEventiOBCRequest ConfiguraEventiOBCResponse Set stato gruppo: arrivato Figura 22 - Flusso dei messaggi per notificare larrivo in destinazione di un gruppoOrchestrazione: DestinationArrivalNotice (two-way)Metodo esposto DestinationArrivalNoticeMessaggio Input DestinationArrivalNoticeRequestMessaggio Output DestinationArrivalNoticeResponseQuesta funzione dovrebbe essere chiamata da parte del CGE lavorando sulla posizione GPS. Una volta che iltrasporto è all’interno del perimetro descritto, invia la richiesta DestinationArrivalNoticeRequest.Dal DB recuperiamo ID dell’OBC associato all’ID del gruppo indicato, creiamo la richiesta del tipoConfigureOBCEventsRequest opportunamente decidendo di spegnere l’invio periodico e chiamiamol’orchestrazione ConfigureOBCEvents per configurare eventi dell’OBC.Nel caso Gateway ci risponde con esito positivo, allora, attraverso la stored procedure si cambia lo stato delgruppo nella tabella Gruppo a ‘Arrivato’.Si risponde al chiamante con l’esito dell’operazione ritornato dall’orchestrazione ConfigureOBCEvents. 4-78
  • 83. 4.6.10 Shutdown OBC Orchestrazione: Shutdown Orchestrazione padre Gateway t&t OBC OBC ShutdownOBCRequest TTShutdownOBCReq TTShutdownReq TTShutdownOBCResp ShutdownOBCResponse Figura 23 - Flusso dei messaggi per spegnere lobcOrchestrazione: ShutdownOBC (interna)Messaggio Input ShutdownOBCRequestMessaggio Output ShutdownOBCResponseQuesta orchestrazione è interna e non espone la funzione attraverso la porta. È stata intesa per essereutilizzata durante il processo della svestizione. Lo scopo della funzione e quello di eventualmente svestire ilgruppo dell’OBC e spegnere l’OBC stesso.A fronte della ricezione del messaggio ShutdownOBCRequest lo rimappa in TTShutdownOBCReq e lo inviaal gateway aspettando la risposta sincrona nel formato del messaggio TTShutdownOBCResp. La risposta delGateway conterrà l’esito dell’operazione d’invio richiesta verso l’OBC.La risposta, indicata prima, verrà rimappata nel ShutdownOBCResponse e ritornata al chiamante. 4-79
  • 84. 4.6.11 Svestizione del gruppo Orchestrazione: OrchSetIDGrupp Orchestrazione: OrchShutdownOB palmare Gateway t&t HC DB o C OpSvestizione SvestizioneRequest SetIDGruppoRequest SetIDGruppoResponse ShutdownOBCRequest ShutdownOBCResponse Set stato gruppo: sciolto SvestizioneResponse OpSvestizioneResp Figura 24 - Flusso dei messaggi per la svestizione di un gruppoOrchestrazione: Disassembling(two-way)Metodo esposto DisassemblingMessaggio Input DisassembleRequestMessaggio Output DisassembleResponseQuesta funzione viene invocata da parte del operatore sul campo (palmare) inviando il codice OBC e 1/2tag presenti e chiedendo, attraverso il Gateway, la svestizione.Se l’ID del gruppo è presente sul DB e si trova nello stato ‘Arrivato’, allora si può procedere conl’esecuzione, altrimenti si risponde subito al chiamante con un errore. La chiamata a SQL ritorna anche l’iddel gruppo di interesse.In questo momento ancora non è stato deciso se prima bisogna impostare ID gruppo a 0 invocandol’orchestrazione SetGroupId e poi si chiamerà l’orchestrazione ShutdownOBC con flag di svestizioneimpostato a false, oppure si chiamerà soltanto l’orchestrazione ShutdownOBC con flag di svestizioneimpostato a true.Nel caso dell’esito positivo si imposta lo stato del gruppo indicato sulla tabella Gruppo a ‘Sciolto’.Si risponde al chiamante rimappando l’esito ritornato dall’orchestrazione ShutdownOBC. 4-80
  • 85. 4.6.12 Vestizione Orchestrazione: OrchSetIDGrupp Orchestrazione: OrchShutdownOB palmare Gateway t&t HC DB o C OpSvestizione SvestizioneRequest SetIDGruppoRequest SetIDGruppoResponse ShutdownOBCRequest ShutdownOBCResponse Set stato gruppo: sciolto SvestizioneResponse OpSvestizioneResp Figura 25 - Flusso dei messaggi per la vestizione di un gruppoOrchestrazione: Assembling(two-way)Metodo esposto AssemblingMessaggio Input AssembleRequestMessaggio Output AssembleResponseQuesta funzione viene invocata da parte del operatore sul campo (palmare) inviando il codice OBC e 1/2tag presenti, inserendo la targa della motrice e di 1/2 container trasportati e chiedendo, attraversoGateway, la vestizione - creazione di un nuovo gruppo.L’orchestrazione s’innesca a fronte di arrivo del messaggio AssembleRequest. Viene subito creato un nuovoID gruppo (potrebbe essere GUID o qualche altra funzione che ritorna la stringa random) e, mediante lastored procedure, lo salva sulla tabella Gruppo con lo stato ‘Abbinato’.Si verifica che i tag non siano già impegnati e che l’OBC sia libero e si risponde al chiamante con l’esitopositivo ed ID Gruppo assegnato. 4-81
  • 86. 5. Disegno dei dati5.1 EntitàL’hub centrale mantiene un proprio database in cui vengono salvate tutte le informazioni contenute neimessaggi che transitano da un entità ad un altra. Le informazioni vengono strutturate in modo chel’operatore abbia la possibilità attraverso una console di supervisionare la movimentazione delle mercimonitorando lo stato delle segnalazioni in arrivo dalla componente emergenze e interrogando il gatewayper ottenere informazioni sullo stato dei convogli.Le entità coinvolte non sono molte ma si prevede una mole di dati molto elevata in quanto verrannoarchiviati tutti i messaggi di interesse in transito nell’hub.Le entità individuate sono:  Gruppo: individua le componenti di un convoglio creato con l’operazione di vestizione. L’associazione coinvolge la motrice su cui viene installato un on board computer e uno/due container a cui sono stati applicati dei tag RFID di chiusura. Ogni gruppo mantiene informazioni sullo stato in cui si trova(abbinato, arrivato a destinazione, sciolto). E’ identificato da un codice univoco alfanumerico.  On board computer: individua un computer di bordo. È identificato da un codice univoco alfanumerico.  Tag RFID: individua un tag RFID utilizzato come sigillo del container. È identificato da un codice univoco alfanumerico.  Messaggio di stato: rappresenta messaggio ricevuto dal Gateway. Contiene le coordinate geografiche di un convoglio la sua direzione e velocità sui due assi x e y, e alcuni flag che descrivono lo stato della strumentazione e dei sigilli applicati ai container in un particolare istante. E’ identificato da un codice univoco alfanumerico  Motivo di invio: rappresenta una motivazione per l’invio di un mesaggio di stato. E’ identificata da un intero ed è accompagnata da una descrizione. Le motivazioni di invio previste sono: o Invio periodico o Variazione velocità GPS (fermo/vado) o Apertura del carico o lallarme del pulsante o Variazione stato link RFID o Variazione stato GPS 5-82
  • 87. o Variazione stato GSM o Variazione stato ZigBee o Richiesta da centrale o Variazione stato batteria OBC o Variazione stato batteria TAG o Variazione associazione o Richiesta non poteva essere inoltrata all’OBC  Allarme: rappresenta una segnalazione di allarme inviata dalla componente di gestione emergenze oppure generata dal business rules engine come esito dell’analisi dei messaggi in arrivo dal gateway. Contiene una codifica dell’azione eseguita automaticamente dal sistema, se esiste, una descrizione delle azioni previste per gestire la situazione di allarme, l’istante in cui è stata generato l’allarme e una codifica del problema riscontrato  Correlazione: rappresenta un associazione fra messaggi. Sono previste delle situazioni in cui dall’hub escono richieste di servizio sotto forma di messaggi verso il gateway. Il gateway risponde subito confermando o negando la richiesta. Se la richiesta viene confermata l’hub rimane in attesa di un messaggio che conterrà le informazioni richieste. Per poter però distinguere il messaggio atteso dal resto del traffico in transito sull’hub, si da la possibilità di specificare nei messaggi di stato un codice identificativo che permette di effettuare l’associazione. Questo codice viene creato di volta in volta e salvato per garantirne l’univocità.5.2 TabelleOgni entità individuata, nel modello relazionale si traduce in una tabella. Sono riportate di seguito ledescrizioni di tutte le tabelle in cui sono indicati i nomi dei campi, il tipo di dati contenuti e una descrizionedel significato del valore contenuto.L’entità Gruppo si traduce in una tabella chiamata GroupSet con i seguenti campi:GroupSetId Uniqueidentifier, PK Identificatore del gruppo. Chiave primaria della tabellaOBCId Int, FK Identificatore dell’obc. Chiave esterna sulla tabella OBCFirstRFIDId Int, FK Identificatore del tag applicato al primo container. Chiave esterna sulla tabella Tag 5-83
  • 88. SecondRFIDId Int, FK, NULL Identificatore del tag applicato al secondo container. Chiave esterna sulla tabella Tag. Il campo è opzionale.FirstContainerIdentifier Nvarchar(100) Identificatore del primo container.SecondContainerIdentifier Nvarchar(100), NULL Identificatore del secondo container.TruckLicencePlate Nvarchar(100) Targa della motriceStatus Nvarchar(100) Stato del gruppo. Può essere ‘ABBINATO’, ‘ARRIVATO’ o ‘SCIOLTO’AssembleDate Datetime Data in cui viene creata l’associazioneDisassembleDate Datetime, NULL Data in cui il gruppo passa allo stato SCIOLTOL’entità messaggio di stato si traduce nella definizione della tabella StatusMessage con la seguentestruttura:StatusMessageId Uniqueidentifier, PK Identificativo del messaggio. Chiave primaria della tabellaOBCId Int, FK Identificativo dell’obc. Chiave esterna sulla tabella OBCGroupId Uniqueidentifier, FK, NULL Identificativo del gruppo. Chiave esterna sulla tabella GroupSetCorrelationId Int, NULL Identificativo della correlazione. Chave esterna sulla tabella CorrelationOperationDetailId Int, FK Identificativo della motivazione di invio. Chiave esterna sulla tabella OperationDetailSendingDate Datetime Data e ora in cui il gateway invia il messaggio all’hubLatitude Float Latitudine espressa in gradi decimaliLongitude Float Longitudine espressa in gradi decimaliXAxisSpeed Float Velocità di spostamento sull’asse delle ascisse.YAxisSpeed Float Velocità di spostamento sull’asse delle 5-84
  • 89. ordinate.Direction Float E’ la misura dell’orientamento del veicolo. Il formato utilizzato per indicare la direzione è l’azimut. L’azimuth indica la direzione in gradi dal nord, 0° nord, 90° est, 180°sud, e 270° ovest.IsActiveGPS Bit Attivo / DisattivoIsActiveGSM Bit Attivo / DisattivoIsActiveZigBee Bit Attivo / DisattivoIsActiveOBCBattery Bit Attivo / DisattivoIsActiveFirstTagBattery Bit Attivo / DisattivoIsActiveSecondTagBattery bit, NULL Attivo / DisattivoIsActiveFirstRFID Bit Attivo / DisattivoIsActiveSecondRFID Bit Attivo / DisattivoIsActiveAlarmButton Bit Premuto / Non premutoIsClosedFirstContainer Bit Chiuso / ApertoIsClosedSecondContainer bit, NULL Chiuso / ApertoReceivingDate Datetime Data e ora in cui l’hub riceve il messaggio dal gateway.L’entità allarme si traduce nella definizione della tabella Alarm con la seguente struttura:AlarmId Bigint, PK Identificatore della segnalazione. Chiave primaria della tabella.GroupId Uniqueidentifier, FK Identificatore del gruppo. Chiave esterna sulla tabella GroupSet.PerformedActivity Nvarchar(1000), NULL Codifica dell’azione eseguita automaticamente dal sistemaScheduledActivity Nvarchar(1000), NULL Codifica dell’azione che deve essere eseguitaAlarmDate Datetime Data e ora in cui è stata generata la segnalazione 5-85
  • 90. SourceSystem Nvarchar(100) Sistema che ha originato la segnalzione(BRE o CGE)IssueDetail Nvarchar(1000) Codifica del problema riscontratoStatus Nvarchar(100) Stato della segnalazione di allarme. Può essere ‘APERTA’, ‘PRESA IN CARICO’ o ‘CHIUSA’L’entità “motivazione di invio” si traduce nella definizione della tabella OperationDetail con la seguentestruttura:OperationDetailId Int, PK Identificatore del motivo di invio. Chiave primaria della tabellaCode Int Codice della motivazione condiviso con le altre componenti del sistemaDescription Nvarchar(100), NULL Descrizione della motivazione di invioL’entità “On Board Computer” si traduce nella definizione della tabella OBC con la seguente struttura:OBCId Int, PK Identificatore dell’ on-board-computer. Chiave primaria della tabellaCode Int Codice dell’OBC condiviso con le altre componenti del sistemaStatus Nvarchar(100) Stato del dispositivo. Può assumere i valori ‘ATTIVO’ o ‘DISMESSO’L’entità Tag RFID si traduce nella definizione della tabella Tag con la seguente struttura:TagId Int, PK Identificatore del motivo di invio. Chiave primaria della tabellaCode Int Codice assegnatoStatus Nvarchar(100) Stato del dispositivo. Può assumere i 5-86
  • 91. valori ‘ATTIVO’ o ‘DISMESSO’L’entità “Correlazione” si traduce nella definizione della tabella Correlation con la seguente struttura:CorrelationId Int, PK Identificatore del motivo di invio. Chiave primaria della tabellaOperation Nvarchar(100) Operazione per la quale è stato necessario creare un identificativo di correlazioneCreationDate Nvarchar(100) Data in cui è stato creato l’identificativo di correlazione.5.3 Schema fisicoNella figura che segue è riportato lo schema fisico del database:. 5-87
  • 92. StatusMessage Id OBCId GroupId Correlation Id CorrelationId Operation OperationDetailId CreationDate SendingDate Latitude Longitude XAxisSpeed OBC YAxisSpeed OperationDetail Id Direction Id Identifier IsActiveGPS Code Status IsActiveGSM Description IsActiveZigBee IsActiveOBCBattery IsActiveFirstTagBattery IsActiveSecondTagBattery IsActiveFirstRFID IsActiveSecondRFID IsActiveAlarmButton IsClosedFirstContainer IsClosedSecondContainer ReceivingDate GroupSet Alarm Id Id OBCId Tag GroupId Id FirstRFIDId PerformedActivity MacAddress SecondRFIDId ScheduledActivity FirstContainerIdentifier Status AlarmDate SecondContainerIdentifier SourceSystem TruckLicensePlate IssueDetail Status Status AssembleDate DisassembleDate Figura 26 - Schema fisico dei dati5.4 ConsiderazioniLe tabelle descritte ad esclusione di GroupSet e StatusMessage utilizzano come chiave un campo interno into bigint autoincrementante che ne garantisce l’univocità. Le due tabelle escluse utilizzano invece un campodi tipo uniqueidentifier. E’ un valore di 128 bit e si esprime comunemente con valori esadecimali divisi ingruppi separati da un trattino(-)  Gruppo 1 (8 caratteri) 5-88
  • 93.  Gruppo 2 (4 caratteri)  Gruppo 3 (4 caratteri)  Due elementi iniziali del gruppo 4 (4 caratteri)  Sei elementi rimanenti del gruppo 4 (12 caratteri) Questo tipo di chiave non è performante in termini di prestazioniLa best practice sarebbe di avere un indice cluster piccolo perché viene utilizzato internamente in ogniindice non cluster presente sulla tabella. Oltre al problema della dimensione c’è il problema della nonsequenzialità dei valori generati con la funzione newid() definita dal linguaggio T-SQL o da un’equivalentefunzione del framework utilizzato. Questa caratteristica crea uno stress maggiore a carico dell’indice chedovendo mantenere ordinati i valori al suo interno, deve fare un lavoro maggiore. Ciò provoca una maggiornecessità di effettuare dei page-split per poter accogliere i dati nell’ordine corretto.Questa scelta di usare un GUID come primary key non è performante ma è giustificata dal fatto che ènecessario avere un valore che sia univoco anche tra database diversi che possono essere isolati e nonconnessi tra loro. In particolare, sia il gateway che la componente gestione emergenze mantengono unproprio database in cui salvano le informazioni relative ai gruppi.Al database si accede solo attraverso stored procedure. In questo modo la logica di inserimento modifica ecancellazione dei dati viene gestita internamente al database dal motore DBMS.5.5 Stored ProcedureLe operazioni di creazione, lettura, aggiornamento e rimozione(CRUD) sulle tabelle del database vengonoeseguite definendo apposite stored procedure.Nome Parametri DescrizioneAlarmCreate  @GroupId uniqueidentifier Crea una nuova riga nella tabella  @PerformedActivity nvarchar(100) Alarm utilizzando i valori dei  @ScheduledActivity nvarchar(1000) paramtetri della sp.  @SourceSystem nvarchar(100)  @IssueDetail nvarchar(1000)  @Status nvarchar(100)AlarmSubscriptionRead  @AlarmSubscriptionCode Restituisce in un documento xml nvarchar(100) tutti i valori dei campi relativi all’indice @AlarmSubscriptionCode. 5-89
  • 94. CorrelationCreate  @Operation nvarchar(100) Crea una nuova riga nella tabella CorrelationGroupSetCreate  @GroupId uniqueidentifier Crea una nuova riga nella tabella  @OBCCode nvarchar(100) GroupSet. Prima dell’’inserimento  @RFID1Mac nvarchar(100) vengono effettuati dei controlli  @RFID2Mac nvarchar(100) sulla disponibilità di tutti i  @Contianer1Identifier nvarchar(100) componenti.  @Container2Identifier nvarchar(100)  @TLP nvarchar(100)GroupSetReadOBC  @GroupId uniqueidentifier Restituisce in un documento xml l’identificativo dell’OBC associato alla chiave @GroupIdGroupSetReadStatus  @OBCCode nvarchar(100) Restituisce in un documento xml  @FirstTagId nvarchar(100) il valore dello stato del gruppo  @SecondTagId nvarchar(100) relativo alla chiave @IdMessaggioGroupSetUpdateStatus  @GroupId uniqueidentifier Aggiorna lo stato del gruppo  @Status nvarchar(100) @GroupId con il valore @StatusStatusMessageCreate  @MessageId uniqueidentifier Crea una nuova riga nella tabella  @OBCCode nvarchar(100) StatusMessage utilizzando i valori  @GroupId uniqueidentifier dei parametri della sp.  @CorrelationId int  @OperationDetailCode int  @SendingDate datetime  @Latitude float  @Longitude float  @XaxisSpeed float  @YaxisSpeed float  @Direction float  @GPS bit  @GSM bit  @ZigBee bit  @OBCBattery bit  @FirstTagBattery bit  @SecondTagBattery bit 5-90
  • 95.  @FirstRFID bit  @SecondRFID bit  @AlarmButton bit  @FirstContainer bit  @SecondContainer bit  @ReceivingDate datetimeStatusMessageRead  @MessageId uniqueidentifier Restituisce in un documento xml  @GroupId uniqueidentifier tutti i valori dei campi relativi alla chiave @IdMessaggio5.6 Database di supportoSi è reso necessario introdurre una seconda base dati di supporto a cui hanno accesso i moduli softwareche si occupano della simulazione della componente gestione emergenze e del gateway. Questo secondodatabase contiene i dati relativi ai computer di bordo, alla lista dei tag RFID applicati ai container, allemotrici, ai percorsi che si vogliono simulare e ai gruppi creati e sciolti attraverso le fasi di vestizione esvestizione. Questo database di supporto contiene informazioni simili a quelle mantenute dal databaseinterno all’hub e si rende necessario per salvare i dati usati per la simulazione.Le entità individuate sono:  Convoglio: corrisponde ad un gruppo definito nella sezione precedente. Rappresenta un’associazione fra Onboard computer, tag, motrice e container.  On board computer: rappresenta un OBC e contiene le coordinate con la posizione ottenuta tramite GPS, dei flag che definiscono lo stato di attività dell’apparecchio e un flag che definisce se è attivo l’invio periodico dei messaggi di stato  Tag RFID: rappresenta un sigillo RFID e contiene dei flag che descrivono lo stato di attività del dispositivo e nel momento in cui è attivo se si trova in stato di chiusura.  Motrice: rappresenta la motrice su cui viene installato un OBC e il suo unico attributo è la targa con cui è stato immatricolata.  Percorso: è un insieme di punti che descrivono un percorso a cui viene assegnato un nome.  Nodo del percorso: definisce da due coordinate, una di latitudine e una di longitudine e un intero che rappresenta la posizione all’interno del percorso. 5-91
  • 96. La fase di disegno concettuale può includere prospettive orientate ai dati, ai processi ed al comportamento,e il DBMS reale utilizzato per implementare il disegno potrebbe essere basato su uno dei tanti modelli logicidei dati (relazionale, gerarchico, reticolare, object-oriented, ecc.).La progettazione concettuale di questo db è stata condotta definendo le proprietà delle entità coinvoltesecondo un modello orientato agli oggetti. La scelta è giustificata dalla volontà di sfruttare in fase disviluppo le funzionalità offerte dagli O/RM in termini di generazione automatica dello schema fisico apartire da un modello ad oggetti delle entità. Questo tipo di approccio è chiamato model first.L Object-Relational Mapping (ORM) è una tecnica di programmazione che favorisce lintegrazione di sistemisoftware aderenti al paradigma della programmazione orientata agli oggetti con sistemi RDBMS. Conl’ausilio di ORM è possibile definire separatamente il modello concettuale degli oggetti e il modello dipersistenza dei dati e di interporre tra essi un ulteriore livello di trasformazione per definire il mapping tra idue modelli. Figura 27 - Object Relational MappingIl disaccoppiamento prodotto permette potenzialmente di definire un modello concettualeindipendentemente dalla concreta persistenza dei dati. Per la fase di sviluppo è stato scelto l’utilizzo diEntity Framework 4 che va oltre le capacità tipiche di un O/RM permettendo la generazione di un modellofisico dei dati a partire da un modello concettuale che definisce le entità come classi .NET. Lo schemaconcettuale orientato agli oggetti è riportato in figura. 5-92
  • 97. Figura 28 - Schema concettuale delle entitàIn fase di sviluppo partendo dallo schema delle entità è stato generato lo schema fisico dei dati secondo ilmodello relazionale utilizzando la funzione Generate database from model di Entity framework. Questafunzione genera uno script di data definition language(DDL) contenente gli statement di creazione delletabelle, definizione delle chiavi primarie ed esterne e degli indici. 5-93
  • 98. OnBoardComputerSet TruckSet Id OnBoardComputerId TractorSet Latitude TractorId Id Longitude Container1 LicensePlate Direction Container2 XAxisSpeed RfidTagId YAxisSpeed RfidTagId1 IsActiveGPS Id TruckInfoSet IsActiveGSM Status Id IsActiveBattery AssembleDate OBC IsActiveZigbee Operation IsActiveAlarmButton GroupId Code SendingDate PeriodicSending Latitude RfidTagSet Longitude Id XAxisSpeed MacAddress YAxisSpeed IsActiveBattery Direction IsActiveLink IsActiveGPS IsLocked IsActiveGSM IsActiveZigBee IsActiveOBCBattery PathVertexSet IsActiveFirstTagBattery Id IsActiveSecondTagBattery OrderIndex IsActiveFirstRfidLink Latitude IsActiveSecondRfidLink Longitude IsActiveAlarmButtonPathSet PathId IsClosedFirstContainer Id IsClosedSecondContainer Description ReceivingDate MessageId Figura 29 - Schema fisico dei dati 5-94
  • 99. 6. Implementazione6.1 Descrizione delle SolutionsLo sviluppo di questo hub di comunicazione si concretizza con la realizzazione di due soluzioni separate.La prima soluzione contiene i progetti Biztalk che servono a definire i messaggi scambiati nellacomunicazione, le mappe per la trasformazione dei messaggi, le orchestrazioni e i relativi processi dibusiness e alcune librerie di supporto. Il nome scelto per questa solution è Teorema.slimTruck.BT.I progetti definiti all’interno sono:  Teorema.slimTruck.BT.DataContracts: è una Class Library che contiene un solo file .cs creato con il tool xsd.exe. Questo tool è messo a disposizione da Visual Studio 2010 e permette di generare automaticamente classi C# a partire dagli xml schemas dei messaggi. Le classi generate sono descritte da attributi necessari alla serializzazione xml.  Teorema.slimTruck.BT.Helpers: è una Class Library e contiene alcune classi di supporto per la gestione dei codici di errore, per la generazione di messaggi xml a partire dalle classi definite nel progetto Data Contracts e per la definizione di oggetti utilizzati all’interno del business rules engine di biztalk.  Teorema.slimTruck.BT.Maps: è un progetto Biztalk e definisce le mappe che vengono utilizzate per eseguire trasformazioni di messaggi a livello di porta di receive oppure di send. Vengono utilizzate per creare sottoscrizioni che eseguono il routing dei messaggi senza instanziare orchestrazioni ma sfruttando solo le context property dei messaggi.  Teorema.slimTruck.BT.Orchestration.CGE: è un progetto Biztalk che contiene le orchestrazioni che vengono attivate da richieste provenienti dalla componente di gestione emergenze.  Teorema.slimTruck.BT.Orchestration.Process: è un progetto Biztalk che contiene le orchestrazioni attivate da richieste provenienti dalla console, oppure orchestrazioni interne che non hanno binding a porte fisiche ma vengono attivate da chiamate effettuate all’interno di altre orchestrazioni.  Teorema.slimTruck.BT.Orchestration.TT: è un progetto Biztalk che contiene le orchestrazioni attivate da richieste provenienti dal gateway.  Teorema.slimTruck.BT.Schemas: è un progetto di tipo Biztalk. Contiene la definizione degli xml schemas (.xsd) che rappresentano i messaggi scambiati fra l’hub e le altre componenti. Gli schemas sono suddivisi in directory in base al contesto in cui vengono utilizzati e in particolare in base alle componenti coinvolte. 6-95
  • 100. La seconda solution contiene i progetti necessari alla creazione dell’interfaccia e alla simulazione dellecomponenti gateway e gestione emergenze. Questa solution contiene gli strati di accesso ai dati per ildatabase interno all’hub e per il database di supporto, gli strati che definiscono le logiche di business, lelibrary con i contratti dei dati e dei servizi esposti verso l’hub, l’implementazione dei servizi consumatidall’hub e le references ai servizi pubblicati invece dall’hub. Il nome scelto per la solution èTeorema.slimTruck.Console. I progetti definiti all’interno sono:  Teorema.slimTruck.Console.DAL: rappresenta il livello di accesso ai dati per il database interno all’hub. Definisce un data model utilizzando Entity framework 4.0 e un implementazioni delle operazioni CRUD per le tabelle necessarie.  Teorema.slimTruck.Console.Managers: rappresenta il livello di business logic. Definisce delle classi con metodi static che permettono di effettuare operazioni controllate sui dati comunicando con il livello di accesso ai dati.  Teorema.slimTruck.Console.ManagerServices: questo progetto definisce delle classi manager che gestiscono la comunicazione fra console e i web service esposti dall’hub.  Teorema.slimTruck.Console.Presentation: rappresenta il livello di presentazione. Si tratta di un progetto di tipo Windows Form e definisce l’interfaccia dell’applicazione.  Teorema.slimTruck.Console.Support.Contracts:  Teorema.slimTruck.Console.Support.DAL: rappresenta il livello di accesso ai dati per il database di supporto. Definisce un data model utilizzando Entity framework 4.0 e un implementazione delle operazioni CRUD per le tabelle necessarie.  Teorema.slimTruck.Console.Support.Entities: definisce le entità di base che non sono riferite ai dati e non sono quindi state definite all’interno dei livelli di accesso ai dati.  Teorema.slimTruck.Console.Support.Helpers: questo progetto contiene delle utility per la gestione delle date e per la trasformazione degli angoli nelle operazioni di calcolo delle distanze fra coordinate geografiche durante la fase di simulazione di movimento dei convogli.  Teorema.slimTruck.Console.Support.Managers: rappresenta il livello di business logic per i progetti di supporto necessari alla simulazione delle componenti gateway e gestione emergenze. Definisce delle classi con metodi static che permettono di effettuare operazioni controllate sui dati comunicando con il livello di accesso ai dati.  Teorema.slimTruck.Console.Support.ManagerServices: questo progetto definisce delle classi manager che permettono al gateway e alla componente gestione emergenze di consumare i servizi pubblicati dall’hub. 6-96
  • 101.  Teorema.slimTruck.Console.Support.Services: questo progetto contiene l’implementazione dei servizi esposti dal gatway e da CGE. L’implementazione si riferisce ai contratti definiti nel progetto Contracts.  Teorema.slimTruck.Console.Support.WebModel: Questo progetto contiene unapplicazione web creata sfruttando i dynamic data che permette di creare un interfaccia completa per accedere a tutte le operazioni CRUD specificando il riferimento ad un data model6.2 Hub di comunicazione6.2.1 Definizione degli schemasLa struttura dei messaggi utilizzati per la comunicazione viene definita utilizzando xml schemas(.xsd). E’ ilfondamento di tutti gli scenari e lo scambio di messaggi con Biztalk Server. Si tratta di un metodo perdefinire la struttura di documenti xml utilizzando tag xml associati ad un particolare namespace:http://www.w3.org/2001/XMLSchema. Al namespace viene in genere associato il prefisso xs.Le principali funzioni di xml schema sono:  Definire gli elementi (tag) che possono apparire in un documento  Definire gli attributi che possono apparire in un elemento  Definire quali elementi devono essere inseriti in altri elementi (da ora in avanti li chiameremo child)  Definire il numero degli elementi child  Definire quando un elemento devessere vuoto o può contenere testo, elementi, oppure entrambi  Definire il tipo per ogni elemento e per gli attributi (intero, stringa, ecc, ma anche tipi personalizzati)  Definire i valori di default o fissi per elementi ed attributiL’esempio più semplice di xml schema definito in questa solution è relativo al messaggio ErrorDetails: 6-97
  • 102. <?xml version="1.0" encoding="utf-16"?> <xs:schema xmlns="http://Teorema.slimTruck.BT.Schemas.ErrorDetails" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" targetNamespace="http://Teorema.slimTruck.BT.Schemas.ErrorDetails" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="ErrorDetails"> <xs:complexType> <xs:sequence> <xs:element name="ErrorCode" type="xs:int" /> <xs:element name="ErrorDescription" type="xs:string" /> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>Questa porzione di codice descrive uno schema in cui il root element si chiama ErrorDetails e contiene dueelementi figli:  ErrorCode di tipo int  ErrorDescription di tipo stringIl namespace associato allo schema è http://Teorema.slimTruck.BT.Schemas.ErrorDetails. Inamespace sono dei raggruppatori che permettono ad elementi e attributi di schemi diversi di avere glistessi nomi:  Forniscono nomi univoci per elementi e attributi  Prevengono il conflitto di nomi con altri schemas  Possono essere utilizzati per generazione di codice  La combinazione namespace#root di uno schema deve essere unicaOgni tag all’interno di un documento xml può essere associato ad un particolare namespace inserendol’attributo xmlns=”[valore]” oppure preponendo al tag il prefisso associato al namespace in fase didefinizione. Anche se in teoria è possibile utilizzare qualsiasi identificatore per un namespace, è opportunoutilizzare nomi univoci che evitino a loro volta omonimie. I namespace vengono quindi identificati tramiteURI. Il namespace associato ad un documento viene definito all’interno di un xml schema con l’attributotargetNamespace dell’element xs:schema.Lo schema appena definito rappresenta un dettaglio di errore. Viene utilizzato come riferimento all’internodi altri schemas così che in caso di necessità è sufficiente apportare le modifiche solo a questo schema perpropagarle a tutti gli altri. Ci sono tre modi per importare uno schema esistente:  Include: include fisicamente la definizione dello schema 6-98
  • 103.  Import: include lo statement <Imports>. In questo modo namespace e xsd object structure sono utilizzabili in sola lettura.  Redefine: simile a import ma permette di sovrascrivere oggetti e struttura dei datiUn esempio di schema che definisce il riferimento al dettaglio di errore è Assemble.xsd. <?xml version="1.0" encoding="utf-16" ?> - <xs:schema xmlns="http://Teorema.slimTruck.BT.Schemas.Assemble" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" xmlns:err="http://Teorema.slimTruck.BT.Schemas.ErrorDetails" targetNamespace="http://Teorema.slimTruck.BT.Schemas.Assemble" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:import schemaLocation="..RequestsErrorDetails.xsd" namespace="http://Teorema.slimTruck.BT.Schemas.ErrorDetails" /> - <xs:annotation> - <xs:appinfo> - <b:references> <b:reference targetNamespace="http://Teorema.slimTruck.BT.Schemas.ErrorDetails" /> </b:references> </xs:appinfo> </xs:annotation> - <xs:element name="Req"> - <xs:complexType> - <xs:sequence> <xs:element name="OBCId" type="xs:string" /> <xs:element name="FirstTagId" type="xs:string" /> <xs:element minOccurs="0" name="SecondTagId" type="xs:string" /> <xs:element name="FirstContainerIdentifier" type="xs:string" /> <xs:element minOccurs="0" name="SecondContainerIdentifier" type="xs:string" /> <xs:element name="TruckLicensePlate" type="xs:string" /> </xs:sequence> </xs:complexType> </xs:element> - <xs:element name="Resp"> - <xs:annotation> - <xs:appinfo> - <b:properties> <b:property distinguished="true" xpath="/*[local-name()=Resp and namespace-uri()= http://Teorema.slimTruck.BT.Schemas.Assemble]/*[local-name()=ErrorDetails and namespace-uri()=http://Teorema.slimTruck.BT.Schemas.ErrorDetails]/*[local- name()=ErrorCode and namespace-uri()=]" /> </b:properties> </xs:appinfo> </xs:annotation> - <xs:complexType> - <xs:sequence> <xs:element minOccurs="0" name="GroupId" type="xs:string" /> <xs:element ref="err:ErrorDetails" /> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> 6-99
  • 104. Il target namespace di questo schema è http://Teorema.slimTruck.BT.Schemas.Assemble. Per convenzionein questo progetto i namespace di tutti gli schemas sono creati secondo la struttura:http://[NomeAzienda].[NomeProgetto].BT.Schemas.[NomeSchema]Questo schema definisce due root element:  Req: descrive la struttura del messaggio di richiesta di vestizione  Resp: descrive la struttura del messaggio di rispostaIl messaggio di risposta è composto da un element di tipo string che contiene l’identificativo del gruppocreato se la richiesta di vestizione va a buon fine, e un secondo element che viene definito comeriferimento all’elemento err:ErrorDetails. Affinche questo riferimento sia valido deve essere presentenell’elemento <xs:schema ...> la definizione di un namespace con prefisso err: e un child element<xs:Import ... /> che indica la locazione fisica dello schema che descrive quel namespace.Si può inoltre osservare la presenza dell’element <b:property distinguished="true" ...> in cui vienespecificato con un espressione Xpath un elemento all’interno dello schema. Questo element serve adefinire un distinguished field. Si tratta di una particolarità di Biztalk infatti il namespace di riferimento èhttp://schemas.microsoft.com/BizTalk/2003. Sono delle speciali proprietà di contesto che possono essereaccedute direttamente dall’expression editor all’interno di un orchestrazione. Non possono essere usateper il routing dei messaggi ma solo all’interno di un orchestrazione. Quando si ha a che fare con messaggi digrandi dimensioni possono far risparmiare risorse in quanto il motore carica una sola volta i dati quandoviene fatto il parse del documento, invece di dover usare ogni volta espressioni Xpath. Possono averequalunque lunghezza a differenza della promoted property e sono più performanti perchè non vengonoresi persistenti nella MessageBox. I distinguished fields vengono acceduti all’interno di un orchestrazioneattraverso un riferimento alla struttura del messaggio che lo contiene:[MessageName].[RecordName].[ChildRecordName].DistinguishedFieldLa promozione delle proprietà di uno schema si può fare in due modi, utilizzando:  Distinguished field: appena descritti  Promoted Property: sono il modo più comune per abilitare il context base routing. Sono disponibili non solo all’interno delle orchestrazioni ma anche da pipeline, adapter e message bus. Permettono al message engine di instradare i messaggi guardando solo all’interno del message context. Le promoted property definite in un property schema possono avere uno di due tipi base: o Message-Data property schema: il valore delle proprietà viene dal payload del messaggio. Le proprietà definite in property schema derivano da questo tipo. L’orchestration design 6-100
  • 105. engine(ODX) esamina le proprietà per verificare se il namespace e il nome delle proprietà corrispondono con una proprietà promossa. Se non viene trovata corrispondenza l’ODX non permette di vederle. o Message-Context property schema: Non hanno valori provenienti dal payload. Contengono spesso dati relativi al trasporto del messaggio e possono avere informazioni di configurazione necessarie alle sottoscrizioni. Vengono in genere promosse dagli adapter o dalla pipeline. Possono essere lette da ODX indipendentemente dal namespacePromuovere proprietà alla cieca è inefficiente e costoso in termini di performance e scalabilità. Elementi daconsiderare prima di promuovere una proprietà sono:  Property size: limitata a 255 caratteri  Performance: tutti i campi promossi vengono esplicitamente inseriti in una tabella di database per renderli disponibili alle stored procedure per la risoluzione delle sottoscrizioni  Valori null: le null properties non vengono rese persistenti nel contesto. Se si imposta una proprietà al valore null questo non esisterà più perchè non si può vedere nella console MMC.Un esempio di schema in cui è stata definita una promoted property è TTStatusClaim: 6-101
  • 106. <?xml version="1.0" encoding="utf-16" ?> - <xs:schema xmlns="http://Teorema.slimTruck.BT.Schemas.TTStatusClaim" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" xmlns:ns0="https://Teorema.slimTruck.BT.Schemas.PropertySchema" targetNamespace="http://Teorema.slimTruck.BT.Schemas.TTStatusClaim" xmlns:xs="http://www.w3.org/2001/XMLSchema"> - <xs:annotation> - <xs:appinfo> - <b:imports xmlns:b="http://schemas.microsoft.com/BizTalk/2003"> <b:namespace prefix="ns0" uri=https://Teorema.slimTruck.BT.Schemas.PropertySchema location="..PropertySchema.xsd" /> </b:imports> </xs:appinfo> </xs:annotation> - <xs:element name="Req"> - <xs:annotation> - <xs:appinfo> - <b:properties> <b:property name="ns0:CorrelationId" xpath="/*[local-name()=Req and namespace- uri()=http://Teorema.slimTruck.BT.Schemas.TTStatusClaim]/*[local- name()=TransactionId and namespace-uri()=]" /> </b:properties> </xs:appinfo> </xs:annotation> - <xs:complexType> - <xs:sequence> <xs:element name="OBCId" type="xs:string" /> <xs:element name="TransactionId" type="xs:int" /> </xs:sequence> </xs:complexType> </xs:element> - <xs:element name="Resp"> - <xs:annotation> - <xs:appinfo> - <b:properties> <b:property distinguished="true" xpath="/*[local-name()=Resp and namespace- uri()=http://Teorema.slimTruck.BT.Schemas.TTStatusClaim]/*[local- name()=SendingResult and namespace-uri()=]" /> </b:properties> </xs:appinfo> </xs:annotation> - <xs:complexType> - <xs:sequence> <xs:element name="SendingResult" type="xs:boolean" /> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>La definizione di questo schema comprende delle annotazioni inserite nell’element <Annotations> cheservono a inserire il riferimento al namespace Biztalk per l’utilizzo delle promoted property e al namespacedel Property Schema in cui è definito il field in cui viene eseguita la promozione. In questo caso ilnamespace del property schema utilizzato è https://Teorema.slimTruck.BT.Schemas.PropertySchema. 6-102
  • 107. La promozione è definita dall’element <b:property …> in cui è specificato il nome del field nel propertyschema in cui eseguire la promozione "ns0:CorrelationId" e la posizione del field da promuovere attraversoun espressioni Xpath: "/*[local-name()=Req and namespace-uri()=http://Teorema.slimTruck.BT.Schemas.TTStatusClaim]/*[local-name()=TransactionId and namespace-uri()=]" .Le promoted property in Biztalk sono molto importanti. Sono l’informazione chiave che determina qualimessaggi vengono consegnati ai sistemi di sottoscrizione o ai processi. Sono il metadata che Biztalk usa pereseguire il routing dei messaggi. Il termine comunemente usato per descrivere proprietà promosse di unmessaggio è Message Context. Il message context include:  Instance-specific data field: sono proprietà di pertinenza di uno specifico messaggio, che vengono popolate con i valori contenuti all’interno dello stesso.  Exchange-specific data field: possono essere determinate senza leggere il contenuto all’interno del messaggioPer promuovere un XML record il suo content-type deve essere impostato al valore Simple Content eindipendente dal tipo di elemento, che sia un element oppure un attribute o un record, la sua lunghezzamassima è di 255 caratteri.L’utilizzo delle promoted property semplifica la programmazione e da beneficio alle prestazioni perchèpossono essere consultate direttamente senza il costo in termini di apertura del messaggio.Non è opportuno inserire la definizione di tutti gli schemas ma è sufficiente dire che sono tutti definiti comevariante dei tre appena descritti.All’interno del progetto gli schemas sono stati raggruppati in directory separate distinguendoli in base alleentità coinvolte al momento dello scambio dei messaggi. Si contano 5 directory:  BO: è acronimo di “business object” e contiene gli schemas dei messaggi con un solo root element che non possono essere associati ad una singola entità  CGE: è acronimo di “componente gestione emergenze” e contiene gli schemi dei messaggi utilizzati dalla gestione emergenze per inviare segnalazioni all’hub centrale  Request: contiene gli schemi dei messaggi utilizzati dalla console per inviare richieste di servizio all’hub centrale  SQL: contiene gli schemi utilizzati dall’hub centrale per comunicare con il motore DBMS di SQL Server ed accedere alle stored procedure.  TT: contiene gli schemi utilizzati per la comunicazione fra gateway t&t e hub centrale 6-103
  • 108. Per completare la descrizione degli schemi è necessario accennare al metodo di creazione degli schemiinseriti nella directory SQL. E’ stato utilizzato un wizard di Visual Studio a cui si accede con il comando Add-> Add Generated Items -> Add Adapter Metadata che permette di creare attraverso una procedura guidatagli schemi per comunicare con SQL Server. Per prima cosa il wizard chiede all’utente il tipo di adapterutilizzato e il nome del server e del database principale di Biztalk. In questo caso l’unico adapter disponibileè SQL. Esistono altri tipi di adapter per cui è possibile eseguire questa procedura di creazione degli schemasma devono essere installati separatamente: si fa riferimento all’adapter pack 2.0 che contiene WCF-LOB(line of business) adapter che dalla versione 2010 sostituiscono i vecchi adapter per SQL, Oracle, dBase,Sap, etc. Questi adapter utilizzano un approccio basato su WCF per la comunicazione. Permettono unapersonalizzazione più elevata e più dettagliata riguardo la struttura degli schemi che si vogliono generare.Utilizzando l’adapter SQL si generano degli schemas con un root element in cui i parametri vengonospecificati come attributi e non come child element.Dopo aver scelto il server e l’adapter SQL, viene chiesto di definire una stringa di connessione verso il DBMSe di individuare il target namespace da assegnare allo schema. Le altre informazioni chieste sono il tipo diporta, send o receive, e di conseguenza il nome dei root element per la request e la response. Nel caso siscelga di usare lo schema con una porta di receive viene chiesto solo il nome del root element per laresponse. Infine il wizard chiede se si vuole usare uno statement di tipo “Select” oppure se si vuole eseguireuna stored procedure. In questo caso l’accesso al database avviene solo tramite stored procedure, è quindisufficiente scegliere di volta in volta il nome della SP desiderata.Per poter utilizzare il wizard le stored procedure che prevedono la restituzione di dati devono utilizzare ilformato xml. Per trasformare il risultato di una query in xml utilizzando il linguaggio T-SQL si deve inserire altermine dello statement di select l’opzione FOR XML RAW. Con questa opzione ogni riga restituita dallaquery viene trasformata in un xml element che ha l’identificatore generico row. Specificando anchel’opzione XMLDATA all’inizio del messaggio viene inserito, in-line, un XDR schema che descrive la strutturadel documento. Se si omette questo ultima opzione il wizard non riesce a riconoscere la struttura ecostruisce uno schema con un element chiamato row associato al data-type anytype.6.2.2 Definizione delle mappeLa fase successiva alla creazione degli schemas è la definizione delle mappe di trasformazione dei messaggi.Le mappe vengono utilizzate in due circostanze:  All’interno di un’orchestrazione  Nella definizione delle porte sia di receive che di send per eseguire trasformazione dei messaggi in arrivo oppure da inviare. 6-104
  • 109. Le mappe utilizzate nelle porte coinvolte in operazioni di context base routing sono state definiteall’interno del progetto Teorema.slimTruck.BT.Maps. Queste mappe sono quindi utilizzate solo nelmeccanismo di sottoscrizione/pubblicazione e non all’interno di orchestration. Sono state definite in unprogetto a se stante perchè hanno uno scope separato da quello dei processi di business definiti tramiteorchestrazioni e il loro deploy può essere indipendente.Biztalk mette a disposizione un designer per la creazione delle mappe. Il designer permette di scegliere glischemi di origine e destinazione, che vengono mostrati all’utente come alberi che si possono espandere eraggruppare. Tra gli element dei due schemi è possibile creare dei collegamenti per definire i valori assuntidai campi nello schema di destinazione. Oltre al semplice collegamento sono disponibili nella Toolbox deifunctoids ovvero delle funzioni di trasformazioni già pronte che possono essere applicate ai singoli campi.Nella toolbox i functoids sono divisi in categorie:  Advanced: funzioni generiche: o Scripting: permette di eseguire codice C# scrivendo un metodo in-line oppure eseguendo una chiamata all’esterno ed indicando un assembly, una classe e un metodo. Il numero di parametri del metodo chiamato deve coincidere con il numero di input del functoid e l’assembly deve essere presente in GAC. o Value Mapping: permette di eseguire una sorta di IF..THEN..ELSE. Si definisce una condizione che deve essere valutata e in base al risultato si esegue una fra due operazioni  Conversion: conversioni da carattere ad ASCII e cambiamenti di base fra notazioni binarie, decimali, esadecimali e ottali.  Cumulative: somme, medie di valori, calcolo di minimi e massimi all’interno di un set.  Database: interazione con i dbms.  Date/Time: data e ora corrente.  Logical: operatori logici And, Or, Not, uguaglianza, disuguaglianza, etc.  Mathematical: operazioni matematiche di somma, sottrazione, moltiplicazione, divisione, arrotondamento, etc.  Scientific: operatori trigonometrici, logaritmi, etc  String: manipolazione di stringhe( concatenate, find, trim, uppercase, lowercase, etc)Un esempio di mappa definita in questo progetto è quella usata per trasformare il messaggio inviato dalgateway all’hub contenente le informazioni sullo stato di un gruppo. Viene trasformato il messaggioStatusMessage in InternalStatusMessage. 6-105
  • 110. Figura 30 - Mappa di trasformazione MapStatusMessage2InternalStatusMessage.mapSono stati utilizzati molti link diretti ad eccezione di due functoid di script e un datetime. Uno script serveper controllare ed eventualmente modificare il formato della data. Effettua una chiamata al metodoFormatDate della classe Mapper nell’assembly Teorema.simTruck.BT.Helpers. L’altro script invece definisceun metodo in-line senza parametri di input che restituisce un nuovo guid utilizzando il metodoSystem.Guid.NewGuid().La mappa appena descritta effettua la trasformazione da un messaggio di input a uno di output. E’ possibileperò individuare messaggi multipli in input così come in output. All’interno del progetto ci sono delleistanze di mappa che utilizzano messaggi multipli in ingresso. Una di queste è la mappa utilizzata per lacreazione della richiesta di sollecito all’invio del messaggio di stato inviata dall’hub verso il gateway. Ilmessaggio creato è TTStatusClaim#Req a partire da due messaggi di risposta ottenuti interrogando il db:  SQLCorrelationCreate#Resp: contiene un codice identificativo univoco inserito nella richiesta al gateway per effettuare la correlazione tra la richiesta stessa e la risposta che arriverà all’hub dal gateway dopo aver contattato il computer di bordo. 6-106
  • 111.  SQLGroupReadOBC#Resp: contiene l’identificativo del computer di borso che deve essere contattato dal gateway per assolvere alla richiesta. L’identificativo è ottenuto dal db specificando come parametro di input un identificativo di gruppo.La mappa si presenta come segue: Figura 31 - Mappa di trasformazione Map_SQLCorrelationCreate2TTStatusMessageClaimReq.mapUna particolarità che sembra d’obbligo segnalare è che questo tipo di mappa non può essere creato conl’operazione Add -> New Item dal progetto della solution perchè non viene data la possibilità di selezionareschemi in ingresso multipli. L’unico modo per creare una mappa di questo tipo è aprire un orchestrazioneesistente o eventualmente creare una nuova orchestrazione, selezionare dalla Toolbox lo strumentoTransform e utilizzare il wizard di creazione. In questo modo si possono scegliere sia per l’origine sia per ladestinazione più schemi.6.2.3 Definizione delle classiLa definizione della struttura dei messaggi con xml schema non è risultata sufficiente, ma si è resonecessario avere una rappresentazione di tali schemas secondo il modello ad oggetti. La necessitàimmediata è di riuscire a creare delle istanze di documenti xml che rispettano le strutture degli schemasdefiniti usando codice c#. Queste istanze vengono utilizzate all’interno delle orchestrazioni per la creazione 6-107
  • 112. di messaggi all’interno di shape di tipo Message Assignment. La definizione delle classi è stata portata atermine utilizzando il tool xsd.exe di Visual Studio 2010 che consente di generare classi Common LanguageRuntime o XML Schema da file XDR, XML e XSD o da classi di un assembly di runtime. Esistono due versionidel tool che permettono la generazioni delle classi secondo il framework 2.0 oppure 4.0. Il tool è statoutilizzando da riga d comando dalla console di Visual Studio. Il comando eseguito è stato: "C:Program Files (x86)Microsoft SDKsWindowsv7.0ABinNETFX 4.0 Toolsxsd.exe" /c /edb /n:Teorema.slimTruck.BT.DataContracts ..Teorema.slimTruck.BT.SchemasRequestsErrorDetails.xsd ..Teorema.slimTruck.BT.SchemasBOInternalStatusMessage.xsd ..Teorema.slimTruck.BT.SchemasBOStatusDetails.xsd ..Teorema.slimTruck.BT.SchemasBOAlarmDetails.xsd ..Teorema.slimTruck.BT.SchemasRequestsStatusClaim.xsd ..Teorema.slimTruck.BT.SchemasRequestsShutdownOBC.xsd ..Teorema.slimTruck.BT.SchemasRequestsSetGroupId.xsd ..Teorema.slimTruck.BT.SchemasRequestsGetOBCEvents.xsd ..Teorema.slimTruck.BT.SchemasRequestsGetGroupId.xsd ..Teorema.slimTruck.BT.SchemasRequestsConfigureOBCEvents.xsd ..Teorema.slimTruck.BT.SchemasTTAssemble.xsd ..Teorema.slimTruck.BT.SchemasTTDisassemble.xsd ..Teorema.slimTruck.BT.SchemasCGEDestinationArrivalNotice.xsd ..Teorema.slimTruck.BT.SchemasSQLSQLAlarmSubscriptionRead.xsdLa prima riga punta all’eseguibile xsd.exe specificando il percorso assoluto all’interno del file system. Leopzioni del comando utilizzate sono:  /c: Genera classi che corrispondono allo schema specificato. Per leggere dati XML nelloggetto, utilizzare il metodo System.Xml.Serialization.XmlSerializer.Deserializer.  /ebd: Implementa linterfaccia INotifyPropertyChanged su tutti i tipi generati per consentire lassociazione dati.  /n:Teorema.slimTruck.BT.DataContracts: Specifica lo spazio dei nomi del runtime per i tipi generati. Lo spazio dei nomi predefinito è Schemas.Le righe successive indicano il percorso degli schemi di cui si vogliono generare le classi. Il percorso èrelativo alla posizione di esecuzione del comando. Il comando è stato eseguito all’interno della directory delprogetto DataContracts.Lo schema ErrorDetails ad esempio da origine all’omonima classe definita come segue: 6-108
  • 113. [System.CodeDom.Compiler.GeneratedCodeAttribute("xsd", "4.0.30319.1")] [System.SerializableAttribute()] [System.Diagnostics.DebuggerStepThroughAttribute()] [System.ComponentModel.DesignerCategoryAttribute("code")] [System.Xml.Serialization.XmlTypeAttribute(AnonymousType=true, Namespace="http://Teorema.slimTruck.BT.Schemas.ErrorDetails")] [System.Xml.Serialization.XmlRootAttribute( Namespace="http://Teorema.slimTruck.BT.Schemas.ErrorDetails", IsNullable=false)] public partial class ErrorDetails { private int errorCodeField; private string errorDescriptionField; /// <remarks/> [System.Xml.Serialization.XmlElementAttribute( Form=System.Xml.Schema.XmlSchemaForm.Unqualified)] public int ErrorCode { get { return this.errorCodeField; } set { this.errorCodeField = value; } } /// <remarks/> [System.Xml.Serialization.XmlElementAttribute( Form=System.Xml.Schema.XmlSchemaForm.Unqualified)] public string ErrorDescription { get { return this.errorDescriptionField; } set { this.errorDescriptionField = value; } } }A partire dalla classe appena descritta è possibile creare un’istanza dell’oggetto ErrorDetails serializzabilesecondo le direttive descritte dagli attributi. Nell’estratto che segue è riportato il codice per la creazione diun istanza dell’oggetto AssembleResp che contiene un istanza di ErrorDetails: static AssembleResp GenerateAssembleResp(int errCode, string errMessage) { AssembleResp ar = new AssembleResp() { ErrorDetails = new ErrorDetails() { ErrorCode = errCode, ErrorDescription = errMessage } }; return ar; } 6-109
  • 114. La definizione delle istanze sfrutta le Object Initialization Expressions disponibili a partire dal .NETframework 3.0. L’istanza AssembleResp può essere serializzata in uno stream e utilizzata per creare undocumento xml che in C# si realizza instanziando un oggetto della classe System.Xml.XmlDocument. Laprocedura di serializzazione è riportata di seguito: private static string ToXml(object o) { XmlSerializer serializer = new XmlSerializer(o.GetType()); System.Text.StringBuilder s = new System.Text.StringBuilder(); using (TextWriter writer = new StringWriter(s)) { serializer.Serialize(writer, o); writer.Close(); return s.ToString(); } }Lo stream usato per la serializzazione è TextWriter definito nello spazio dei nomi System.IO. Questo streamviene infine usato come parametro di input per la creazione di un documento xml con la seguente riga dicodice: XmlDocument xmlDoc = new XmlDocument(); xmlDoc.LoadXml(ToXml(GenerateAssembleResp(errCode,errMessage)));In alternativa alla creazione di un istanza di XmlDocument esiste la possibilità di convertire il flusso xml inun istanza della classe Microsoft.XLANGS.BaseTypes.XLANGMessage. Per eseguire la conversione in XLANGmessage si usa il comando [XLANGmessageInstance][Index].RetrieveAs(typeof([ClassName]))dove :  XLANGmessageInstance: rappresenta un istanza della classe Microsoft.XLANGS.BaseTypes.XLANGMessage  Class Name: rappresenta il nome della classe generata con lo strumento xsd.exeBisogna comunque segnalare che questa prassi può causare dei problemi. Quando si dichiara un messaggioin un orchestrazione viene chiesto di specificare il tipo di messaggio:  .NET class  Multipart  Schema 6-110
  • 115.  Web message typeUsando xsd.exe si dispone sia della .NET class sia dello schema. Se si aggiunge ad un orchestrazione unavariabile di tipo .NET e poi si fa il deploy vengono caricati sia l’assembly contenente lo schema sial’assembly contenente la classe e nella tabella bt_DocumentSpec all’interno del database di Management dibiztalk ci saranno due righe con lo stesso message type riferite ad assembly diversi.Se si cerca di inviare un istanza di un documento ad una receive location associata alla porta logica diricezione dell’orchestrazione si ottiene l’errore di duplicazione dei message type. In fase di deploy nonviene eseguito il check quindi l’errore si presenta a runtime.Il codice appena descritto viene usato per ottenere un documento simile al seguente: <ns0:Resp xmlns:ns0="http://Teorema.slimTruck.BT.Schemas.Assemble"> <GroupId>GroupId</GroupId> <ns1:ErrorDetails xmlns:ns1="http://Teorema.slimTruck.BT.Schemas.ErrorDetails"> <ErrorCode xmlns=”” >10</ErrorCode> <ErrorDescription xmlns=””>ErrorDescription</ErrorDescription> </ns1:ErrorDetails> </ns0:Resp>Si può osservare che il dettaglio di errore ha un root element chiamato ErrorDetails i due child elementdefiniti dalla classe. Per il root element viene specificato il namespace a cui è associato il prefisso ns1,mentre i child element non vengono qualificati e presentano l’attributo xmlns=””. Le tre opzioni per laqualificazione degli element sono:  Qualified: specifica il namespace di appartenenza dell’element  Unqualified: specifica un namespace vuoto xmlns=””  None: non specifica l’attributo namespaceLa scelta del tipo di qualificazione ha provocato dei problemi nella fase iniziale. Il problema è nato dal fattoche il tipo di qualificazione nella definizione delle classi e nella definizione degli schemas xsd deve esserecoerente, pena il mancato riconoscimento degli element da parte dei web services che utilizzano questischemas per comunicare. La definizione degli xsd prevede una proprietà ElementFormDefault che serve perscegliere il tipo di qualificazione assegnata allo schema. La proprietà prevede come valore di defaultUnqualified, ed è stato proprio questo il valore scelto. La scelta del valore Qualified è stata scartata perchènel caso di schemi con più child element annidati ognuno riporterebbe il proprio namespace. La presenzadel namespace fa si che nel momento della definizione di un espressione Xpath per l’identificazione di unparticolare element all’interno del documento l’espressione assuma una lunghezza troppo elevata. Latocodice si specificano gli attributi: 6-111
  • 116. [System.Xml.Serialization.XmlRootAttribute( Namespace="http://Teorema.slimTruck.BT.Schemas.ErrorDetails", IsNullable=false)] e [System.Xml.Serialization.XmlElementAttribute( Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]Il primo attributo viene associate allo statement di definizione della classe e indica che il root element èrappresentato dalla classe, da cui prende il nome. Eventualmente è possibile rendere il nome del rootelement diverso dal nome della classe specificando nell’attributo la proprietà ElementName.Il secondo attributo viene applicato alle proprietà della classe. Anche in questo caso il nome dell’elementviene considerato uguale al nome della proprietà a meno che non venga specificato un ElementName.Questo attributo permette di definire il tipo di qualificazione. In tutte le proprietà definite all’interno delDataContracts il valore scelto è Unqualified. Inizialmente era stato scelto il valore None, per generare unxml più pulito, privo nei child element dell’attributo xmlns=””. Questa scelta si è rivelata errata in quanto imessaggi xml generati instanziando le classi di DataContracts non venivano riconosciuti correttamentedall’XLANG Engine di Biztalk. Biztalk utilizza i documenti .xsd per validare i messaggi xml in arrivo e secondogli schemas tutti gli element dei messaggi devono essere di tipo Unqualified.6.2.4 Business Rules EngineBiztalk Server 2010 ha un motore decisionale in cui si possono definire policy da richiamare all’interno delleorchestrazioni. Si chiama Business Rules Engine ed e formato da molti componenti:  Business rule composer: utilizzato per identificare sorgenti per i facts, definizione e versioning di business policies e busineess rules  Business rule store: contiene le definizioni di business policies e facts.  In-memory cache: contiene i risultati della valutazione delle condizioni associate alle business rules  Business rule framework: usato dagli sviluppatori di applicazioni o orchestrazioni per richiamare business policies e eseguire business rules  Business rule update service: monitora il business rule store per gli aggiornamenti pubblicati di policies e rulesUna regola consiste in una condizione e in un set di azioni. Se la condizione viene valutata vera allora leazioni vengono eseguite. Un rule engine offre maggiori flessibilità rispetto a semplici tabelle di database ofile di configurazione. Esso permette di isolare le condizioni come anche le action dal flussodell’applicazione. 6-112
  • 117. Un vocabulary è una collezione di definizioni che consistono in nomi(alias) per indicare i facts usati nellerules e nelle action. Queste definizioni rendono le regole più semplici da comprendere. E’ un modo perastrarre i facts dalla loro implementazione. Esistono tipi diversi di facts:  Valori o range di valori  .NET classes  XML documents  Datatable o columnsI facts contengono dei campi chiamati Slot nel gergo dei rules engine. Se una business rule cerca diaccedere ad uno slot di fact e non lo trova lancia un eccezione.Questo motore decisionale è stato utilizzato per analizzare i messaggi di stato ricevuti dal gateway e peranalizzare le segnalazioni di allarme ricevute dalla componente di gestione emergenze. Utilizzando businessrule composer sono stati creati due vocabulary:  StatusMessageCheck  AlarmNoticeCheckche definiscono i messaggi coinvolti nell’analisi, e un oggetto .NET restiuito come risultato dell’analisi.I fact rappresentano un element all’interno di uno schema o una proprietà di un oggetto .NET. Al momentodella definizione si può decidere di usarlo in lettura oppure in scrittura. I fact associati all’operazione Getvengono usati per definire le condizioni all’interno delle regole, mentre quelli associati all’operazione Setvengono usati per definire le azioni corrispondenti ad una condizione verificata.Sono anche state definite due policies:  StatusMessagePolicy  AlarmNoticePolicyche utilizzano i vocabularies precedenti per scrivere le regole di business. Una regola è costituita unacondizione scritta usando operatori logici e da un certo numero di azioni che vengono eseguite se lacondizione è verificata.Le policies create per poter essere utilizzate devono essere pubblicate e depolyate. All’interno del progettoci sono due orchestrazioni che effettuano chiamate al business rule engine:  AlarmNotice  StatusMessageAnalisys 6-113
  • 118. Le policy create con Business rule composer vengono richiamate all’interno di un orchestrazione inserendouno shape Call Rule. Questo shape prevede la scelta di una policy e la configurazione dei parametri di inpute output.6.2.5 Definizione delle orchestrazioniLe orchestrazioni sono serie ordinate di operazioni o transazioni che implementano un processo dibusiness. Per interagire con le entità esterne si possono usare porte di send e receive. Si possono eseguiretransazioni in parallelo, applicare regole di business, chiamare logiche complesse definite con codice gestito.NET o chiamare e attivare orchestrazioni. Le orchestrazioni possono essere sfruttate per:  Correlare messaggi  Eseguire business rules con BRE  Gestire e definire l’ambito di una transazioneNon devono essere usate invece per:  Eseguire routing dei messaggi tra le porte  Attuare semplici trasformazioni dei messaggi  Effettuare chiamate remote a sistema attraverso espressioni  Definire complesse regole e policies(per questo esiste il business rules engine)La motivazione è che la gestione di un orchestrazione è costosa in termini di accesso alla messagebox perrendere persistente lo stato. Al contrario le sottoscrizioni eseguono direttamente stored proceduresimplementate sul db e non prevedono l’apertura dei messaggi ma eseguo solo context base routingutilizzando le context property.Attivazione delle orchestrazioniSi possono distinguere due tipi di orchestrazione in base alla modalità di attivazione. Comunementel’attivazione di un orchestrazione viene associata ad una porta di receive che viene posizionata all’inizio delflusso. In questa porta la proprietà Activate viene impostata al valore true e sta a significare che per ognimessaggio ricevuto verrà creata un’istanza di questa orchestrazione. La maggior parte delle orchestrazionidefinite sono di questo tipo ad eccezione di:  Teorema.slimTruck.BT.Orchestration.Process.ShutdownOBC  Teorema.slimTruck.BT.Orchestration.Process.SetGroupIdentifier  Teorema.slimTruck.BT.Orchestration.Process.ConfigureOBCEvents 6-114
  • 119. Queste tre orchestrazioni non iniziano con uno shape di receive e non si attivano alla ricezione di unmessaggio. Vengono attivate attraverso una chiamata all’interno di unaltra orchestrazione. La chiamata adun orchestrazione si può effettuare utilizzando:  shape Call Orchestration: effettua la chiamata in modo sincrono ovvero attende la completa esecuzione dell’orchestrazione chiamata prima di continuare l’esecuzione del flusso chiamante.  shape Start Orchestration: effettua la chiamata in modo asincrono ovvero avvia l’orchestrazione e continua subito con l’esecuzione dell’orchestrazione padre.Quando si effettua una chiamata ad un orchestrazione possono essere scambiati dei parametri in input e inoutput. Questi parametri vengono definiti nell’orchestrazione figlia all’interno della finestra OrchestrationView. La finestra contiene una gerarchia di elementi:  Orchestration Parameters  Ports  Messages  Variables  Correlations SetOgni parametro può essere di tipo porta, messaggio, variabile o correlation e deve specificare se ladirezione è ingresso(In) o uscita (Out). Per rendere più comprensibile la descrizione nella figura che segue èriportato uno screenshot delle finestre: 6-115
  • 120. Figura 32 - Finestra Orchestrazion ViewIn queste due finestre si possono configurare le proprietà degli elementi definiti all’internodell’orchestrazione e i parametri. Il flusso del processo viene invece mostrato in un’altra finestra e sipresenta come un workflow con un punto di partenza e un punto di arrivo. 6-116
  • 121. Figura 33 - Orchestrazione ShutDownOBC.odxL’orchestrazione mostrata si chiama ShutDownOBC e viene chiamata all’interno dell’orchestrazioneDisassemble. Il suo compito è di trasformare il messaggio ricevuto in input inoltrare la richiesta e restituireun messaggio di output opportunamente creato.Si può vedere in questa orchestrazione l’impiego degli shape Transform e Message Assignment utilizzatirispettivamente per trasformare un messaggio da uno schema sorgente ad uno schema destinatariomediante una mappa e per creare un messaggio con codice gestito. Entrambi gli shape devono essereinseriti all’interno di uno shape padre di tipo Construct Message che definisce il tipo di messaggio creato.Le restanti due orchestrazioni che prevedono l’attivazione su chiamata hanno una struttura molto simile aquesta e non vengono descritte in dettaglio. Le uniche differenze stanno nella definizione dei messaggiscambiati e nel tipo delle porte utilizzate per l’inoltro delle richieste.Definizione delle porte logicheLe orchestrazioni comunicano con le entità esterne attraverso delle porte. Sono delle porte logiche chevengono associate attraverso l’operazione di binding alle porte fisiche dopo aver eseguito il deploydell’applicazione. Nella finestra dell’orchestration designer ci sono due aree riservate alla definizione delleporte in cui facendo click con il pulsante destro del mouse si apre il menu contestuale che permette dicreare una nuova porta manualmente o utilizzando una procedura guidata. 6-117
  • 122. La creazione di una porta consiste nella scelta di un nome identificativo e di un port type. Un port type èindividuato da un nome e contiene un insieme di operazioni di tipo one-way oppure sollicit-response.Il wizard continua chiedendo di scegliere se la nuova porta viene utilizzata per l’invio o per la ricezione dimessaggi e quale tipo di associazione con la porta fisica si vuole utilizzare:  Specifica ora  Specifica dopo  Direct o Auto-correlazione o MessageboxIl tipo “Specifica dopo” indica che l’associazione viene creata dopo il deploy all’interno della console diamministrazione. Il tipo “Direct” invece indica che i messaggi vengono inviati direttamente alla Messageboxoppure ad una porta di un’altra orchestrazione in cui è impostata la correlazione. Questi messaggi nonvengono inviati ad una entità esterna ma rimangono all’interno di Biztalk.Le porte così create vengono collegate, a seconda del tipo, agli shape di Send e Receive all’interno delflusso dell’orchestrazione. I tipi dei messaggi delle porte e degli shape collegati devono coincidere perchél’associazione risulti corretta.Può accadere che un certo tipo di messaggio debba essere inviato o ricevuto in orchestrazioni diverse. Perquesto può essere utili definire un port-type comune e poi riutilizzarlo la dove si rende necessario. Quandosi definisce un port type non viene chiesto di scegliere se la porta associata sarà di invio o ricezione ma sichiede solo di definire le operazioni disponibili e gli schema associati ai messaggi di richiesta eeventualmente di risposta.Come esempio si può considerare il port-type creato in questa applicazione per comunicare con SQL Server. 6-118
  • 123. Figura 34 - Orchestrazione StatusMessageClaim.odxNella finestra di Orchestration View si può vedere la definizione del port-type che si chiamaPortType_SQLSlimTruckHub. Contiene un’operazione per ogni stored procedure del db con cui si puòinteragire e affinchè la porta funzioni correttamente i nomi delle operazioni devono coincidere con il nomedella stored procedure associata. Ogni operazione al suo interno definisce gli schemi utilizzati per imessaggi di request e response. Nella finestra che contiene l’orchestrazione si può vedere sul lato sinistrocome viene visualizzata una porta logica che implementa port-type creato. Una considerazione importanteriguarda l’utilizzo delle operazioni: ogni porta logica può utilizzare una sola operazione alla volta. Questacondizione è giustificata dal fatto che nel momento dell’associazione fra porta logica e porta fisica,quest’ultima deve identificare il tipo di adapter e il namespace del messaggio utilizzato. Ne consegue che lachiamata di due stored procedure diverse necessita di due porte fisiche diverse. Non potendo associare dueporte fisiche alla stessa porta logica un’orchestrazione che deve usare due operazioni definite all’internodello stesso port-type deve definire due porte logiche distinte.Le porte con binding di tipo Direct si presentano esattamente allo stesso modo. La differenza sta nelleinformazioni di configurazione. Si deve impostare il valore della proprietà “Binding” con il valore Direct e laproprietà “Partner Orchestration” con il valore MessageBox oppure Self-Correlating come si vede nellafigura che segue. 6-119
  • 124. Figura 35 – Proprietà di una porta con binding di tipo DirectUn esempio di binding di tipo Direct si vede nella configurazione della la porta utilizzata per inviare allamessage box messaggi di tipo AlarmOBC. Questo tipo di messaggio viene prodotto in seguito alla ricezionedi una segnalazione di allarme da parte della gestione emergenze all’interno dell’orchestrazioneAlarmNotice. Figura 36 - Orchestrazione AlarmNotice.odxUtilizzo degli scopeLe orchestrazioni si presentano allo sviluppatore come una sequenza di operazioni definite attraverso deglishape. Ci si trova di fronte ad un metodo di programmazione visuale particolare. I principali costrutti sonopresenti anche se resi disponibili sotto forma di shape. Ad esempio il costrutto if-then-else è rappresentatodallo shape Decide che prevede una diramazione del flusso e la scelta di un percorso in base al valore di unacondizione. Questo shape è qualcosa più di un semplice costrutto if perché permette di definire molti ramidi esecuzione fornendo la funzionalità tipica del costrutto switch-case. 6-120
  • 125. Uno shape importante è lo Scope. E’ una struttura per raggruppare azioni ed è usato principalmente perl’esecuzione di transazioni e gestione di eccezioni. Ha un body e può avere appesi un qualsiasi numero diblocchi per la cattura di errori. Può anche avere un blocco di compensazione opzionale, usato per annullarele operazioni eseguite in caso di rollback in scope transazionali.Sincronizzando uno scope un programmatore si assicura che i dati condivisi accessibili da uno scope nonsaranno sovrascritti da una o più azioni parallele all’interno dell’orchestrazione. Si distinguono scopetransazionali di tipo Atomic, transazionali di tipo Long Running e non transazionali. Gli scope Atomic sonosempre sincroni e garantiscono tutte le proprietà ACID tipiche del modello transazionale  Atomicità  Consistenza  Isolamento  DurabilitàGli scope di tipo Long Running invece sono adatti all’esecuzione di operazioni che prevedono periodi diattesa e non causano il blocco delle risorse. Garantiscono solo la consistenza dei dati e la loro durevolezza.In questo progetto sono stati usati principalmente scope non transazionali perché l’unica funzionalitàrichiesta è stata le gestione delle eccezioni. Figura 37 - Blocco per la cattura delle eccezioni allinterno di uno Scope 6-121
  • 126. Le eccezioni possono essere lanciate a runtime utilizzando lo shape Throw. Per poterlo fare è necessariodefinire una classe personalizzata che estende la classe System.Exception: [Serializable] public class OrchestrationException:Exception { public OrchestrationException(){} public OrchestrationException(string msgParam) : base(msgParam) { } protected OrchestrationException( SerializationInfo info, StreamingContext context): base(info, context) { } }Lo shape Throw lancia un’eccezione rappresentata da un’istanza della classe OrchestrationException.L’eccezione viene catturata da un blocco di Exception Handler posto al termine dello scope in cui vienespecificato l’Object Type dell’eccezione attesa. Il funzionamento della struttura descritta è simile a quellodello statement try-catch tipico dei linguaggi di programmazione ad oggetti tradizionali.Correlazione di messaggiCome accennato in precedenza le porte utilizzate per inviare e ricevere messaggi all’interno delleorchestrazioni possono essere di tipo unidirezionale o bidirezionale. Le porte bidirezionali hanno uncomportamento sincrono in quanto l’invio di un messaggio di richiesta presuppone l’attesa di un unmessaggio di risposta. Per effettuare richieste a servizi esterni in modo asincrono si deve invece ricorrerealla correlazione. All’interno dell’orchestrazione si prevede l’invio di una richiesta che contiene unidentificativo per la correlazione. L’entità esterna inserirà l’identificativo ricevuto nel messaggio di rispostain modo che l’orchestrazione riesca a riconoscere quello corretto. La correlazione è il processo diassociazione di un messaggio in arrivo con l’appropriata istanza di orchestrazione. In ogni istante possonoessere attive tante istanze della stessa orchestrazione e ognuna deve essere in grado di riconoscere ilmessaggio che sta aspettando. 6-122
  • 127. Figura 38 - Configurazione della correlazione fra messaggiNella figura sono mostrate le informazioni di configurazione necessarie per creare una correlazione. Percreare una correlazione all’interno di un’orchestrazione si deve prima di tutto definire un Correlation Type.Si tratta di una lista di proprietà:  Data properties  Context propertiesUn correlation-type può essere usato in più di un correlation set. Questo avviene se si ha la necessità dieffettuare la correlazione su valori diversi perché ogni correlation set può essere inizializzato una sola volta.Il correlation-type creato nell’orchestrazione in figura si chiama CorrelationType_TransactionId e vieneutilizzato dal correlation set Correlation_TransactionId. Per creare la correlazione si deve a questo puntoconfigurare l’inizializzazione impostando la proprietà “Inizializing Correlation Set” dello shape di send con ilnome delle correlation set creato in precedenza. Allo shape che inizializza deve seguire uno shape chesegue la correlazione. E’ presente, infatti, come si vede in figura, uno shape di tipo Receive in cui laproprietà Following Correlation Set è configurata con il nome del correlation set.ConsiderazioniL’uso delle orchestrazioni mette a disposizione oltre a quelle descritte nei paragrafi precedenti anche moltealtre funzionalità. A partire dall’utilizzo esteso degli scope a fini transazionali, alla creazione di catene dicorrelazioni chiamate Correlation Convoy in serie e parallelo, alla creazione di loop e blocchi dicompensazione. Sono state comunque descritte tutte le funzionalità più importanti utilizzate all’interno diquesto progetto in modo da fornire gli strumenti necessari alla comprensione delle strutture delleorchestrazioni create. 6-123
  • 128. 6.2.6 Deploy della solutionLa parte di sviluppo in Visual Studio a questo punto è stata sospesa. Fino a qui sono stati definiti gli schemasche descrivono la struttura dei messaggi, le mappe per eseguire trasformazioni da un tipo di messaggioall’atro, le classi per creare messaggi xml da codice e le orchestrazioni che realizzano i processi di businessdell’applicazione. Non tutto il routing viene però eseguito tramite orchestrazione. Al contrario una regolaalla base dello sviluppo con Biztalk è di non utilizzare orchestrazioni per definire logica di instradamento.La creazione di un applicazione con Biztalk Server prevede una fase in cui vengono definiti schemas, mappe,orchestrazioni, policies e una seconda fase in cui viene eseguito il deploy dei progetti creati. Il deploy rendedisponibili gli artifact definiti alla console salvando tutte le informazioni nei database interni di Biztalk e inparticolare nel database di management.Per eseguire il deploy bisogna prima configurare correttamente le proprietà dei progetti in Visual Studio:In particolare bisogna indicare un Application Name che indica il nome dell’applicazione Biztalk in cui vieneeseguito il deploy del progetto, il nome del database di management di Biztalk e il nome del server in cui sitrova. Inserendo il carattere “.” Come nome del server si fa riferimento all’istanza di SQL Server locale.Un’altra operazione necessaria ai fini del deploy è la firma dell’assembly. Nella sezione Signing si valorizzala checkbox Sign the Assembly e si indica il percorso di un file di strong name (.snk). 6-124
  • 129. Uno strong name consiste nell’identità di un assembly rappresentata dal suo nome, version number,culture information più una chiave pubblica e una firma digitale. Viene generato a partire dal manifest di unassembly, che in ordine contiene i nomi e gli hash di tutti i file che costituiscono l’assembly, usando lacorrispondente chiave privata. Ci si aspetta che assembly con lo stesso strong name siano identici.Si può garantire che un assembly è globalmente unico firmandolo con uno string name. In particolare glistrong name soddisfano i seguenti requisiti:  Garantiscono l’unicità dei nomi rilasciando una coppia di chiavi unica. Nessuno può generare lo stesso nome di assembly perchè un assembly generato con una chiave privata ha un nome diverso da quello generato con un’altra chiave privata  Proteggono il version lineage . Uno strong name assicura che nessuno può produrre la versione seguente di un assembly. L’utente può essere sicuro che la versione di un assembly che sta caricando è stata pubblicata dalla stessa entità della versione con cui è stata eseguita la compilazione dell’applicazione.  Forniscono un controllo forte sull’integrità. Superare il check di sicurezza di .NET framework garantisce che il contenuto dell’assembly non è stato modificato dopo la compilazione.Quando si considera un riferimento ad un assembly ci si aspetta di avere alcuni benefici, trai i qualiversioning e naming protection. Se un assembly con strong name contiene un riferimento ad un assemblycon un nome semplice allora tutto il beneficio viene perso. Ecco perchè assembly con strong name possonoreferenziare solo altri assembly con strong name.Portata a termine la configurazione della solution si può eseguire il deploy dei progetti utilizzando ilcomando deploy disponibile dal context menu della solution. Se il deploy va a buon fine allora si può aprirela console amministrativa di Biztalk Server 2010 e constatare la creazione della nuova applicazione. Perl’applicazione relativa all’hub di comunicazione è stato scelto il nome Teorema.slimTruck. 6-125
  • 130. Come previsto nella console si può individuare l’applicazione Teorema.slimTruck di cui è stato eseguito ildeploy. All’interno dell’applicazione ci sono molti artifact che verranno spiegati singolarmente. Partendodal basso si incontrano le Resources. Qui vengono elencati gli strong name degli assembly utilizzatispecificandone il tipo. Si possono distinguere tre tipi diversi:  System.Biztalk.Assembly: sono class library e non vengono aggiunte all’applicazione durante la fase di deploy. Vengono aggiunte manualmente, individuando l’assembly all’interno del file system. Questi assembly per poter essere utilizzati dall’applicazione devono essere caricati nella globally assembly cache(GAC)  System.Biztalk.BiztalkAssembly: sono biztalk projects che vengono aggiunti durante la fase di deploy dell’applicazione da Visual Studio  System.Biztalk.WebDirectory: sono directory virtuali gestite da Internet Information Server e vengono create con la pubblicazione dei servizi web esposti dall’hub. Questa parte verrà descritta con maggiore dettaglio nel paragrafo Pubblicazione dei servizi web.L’immagine precedente mostra l’elenco completo delle risorse dell’applicazione. In realtà con l’operazionedi deploy le uniche risorse aggiunte sono quelle di tipo BiztalkAssembly.Gli altri artifact che è opportuno descrivere in questa sezione sono:  Orchestrations: contiene l’elenco delle orchestrazioni definite negli assembly per cui è stato eseguito il deploy. Ogni orchestrazione viene descritta da uno stato, dal nome dell’host a cui è stata associata e dall’assembly in cui è definita. Dal menu contestuale inoltre si può accedere alle proprietà di ogni orchestrazione ed eseguire il binding fra le porte fisiche definite all’interno 6-126
  • 131. dell’orchestrazione e le porte fisiche definite come artifact dell’applicazione. Un orchestrazione si dice Unbound fino a quando non viene completato il binding delle porte e non può passare allo stato Enlist.  Schemas: contiene l’elenco degli schema presenti negli assembly per cui è stato eseguito il deploy. Ogni riga dell’elenco definisce un tipo di messaggio indicando da: o Nome o Strong name dell’Assembly o Target namespace o Root element o Schema type (Property o Document) o Applicazione  Maps: contiene l’elenco delle mappe presenti negli assembly per cui è stato eseguito il deploy. Ogni riga dell’elenco definisce una mappa indicando: o Nome o Strong name dell’Assembly o Schema di origine o Schema di destinazione o Applicazione  Pipelines: non sono state definite pipeline personalizzate. Sono state utilizzate ai fini del progetto solo le pipeline di default definite nell’applicazione Biztalk.System: o PassthruTransmit o PassthruTransmit o XMLReceive o XMLReceive6.2.7 Reference e pubblicazione di servizi webBiztalk nel pacchetto di instalazione base prevede 9 WCF adapter ognuno dei quali consiste di send ereceive adapter, ad eccezione di WCF-CustomIsolated. I WCF receive adapter sono:  Isolated WCF adapter: ospitati in web application  In-process WCF adapter: ospitati all’interno dell’host di processo di biztalkEcco l’elenco degli adapter:  WCF-BasicHttp: consente massima compatibilità con .asmx. E’ il binding WCF più performante.  WCF-WSHttp: fornisce supporto alle specifiche WS-* inclusi: o WS-Security 6-127
  • 132. o WS-Atomic Transaction o WS-Addressing  WCFNetNamedPipe: permette comunicazione binaria. Utile per analizzare service request. Utile per validare business rules con BRE  WCF-NetTcp: codifica binaria. Orientato alla comunicazione intranet per un uso WCF to WCF  WCF-Custom e WCF-CustomIsolated: usati per avere il pieno controllo del comportamento dell’endpoint  WCF-NetMsmq: microsoft message queingEsistono due tools forniti insieme a Biztalk server per aiutare nella fase di pubblicazione e consumo diservizi web. Il wizard per il consumo di un servizio si può eseguire all’interno dell’orchestration designer eassolve le operazioni di:  Creazione dei port type  Creazione dei message type  Creazione dei file contenenti le informazioni di binding per la configurazione delle porteIl wizard prevede quattro step attraverso i quali si indicano i riferimenti del servizio per il download delWSDL e degli XSD necessari. Ai fini di questo progetto però il wizard non è stato utilizzato perchè il concettodi consumo di servizio che si vuole applicare è diverso. Si dispone già degli schemi xsd che infatti sonodefiniti nel progetto Schemas e non esiste un endpoint del servizio da cui ottenere informazioni perchè ilservizio ancora non esiste perchè la competenza dello sviluppo è affidata ad un’altra azienda.In queste circostanze l’obbiettivo che ci si è posti è stato di creare un servizio che simula l’implementazionedi quello reale. Il servizio deve quindi essere in grado di ricevere i messaggi dall’hub e di inviare risposte chel’hub sia in grado di interpretare correttamente rispettando gli schema già definiti. L’implementazione delservizio è contenuta nella solution relativa alla console e ai servizi di supporto e verrà quindi vista inseguito. L’unica operazione necessaria è stata quindi la creazione e configurazione delle porte fisichedescritta nel paragrafo che segue.Per quanto riguarda la pubblicazione dei servizi invece è stato usata la procedura guidata Biztalk WCFService Publishing Wizard che si compone di pochi passi. Inizialmente si sceglie il tipo di endpoint che sivuole pubblicare. L’opzione scelta è stata quella di creare un MEX endpoint che si attiene alle specificheWS-MetadataExchange ed espone sia il WSDL del servizio, sia gli schemas xsd di supporto per le chiamate.Nello step successivo si ha la possibilità di scegliere se si vuole pubblicare un Orchestrazione oppure unSchema. L’opzione scelta è stata di pubblicare uno Schema perchè in questo modo il servizio continua adessere valido fino a che non vengono apportate modifiche agli schemas xsd coinvolti. Se si esegue invece la 6-128
  • 133. pubblicazione di un orchestrazione la validità del servizio e condizionata alla non modificadell’orchestrazione. Se l’orchestrazione ha necessità di essere aggiornata lo schema deve essereripubblicato con tutte le conseguenze del caso(il client deve aggiornare il reference al servizio). Nei passiche seguono si chiede di individuare l’assembly contenente lo schema che si vuole pubblicare e si possonocambiare i nomi del servizio e della sua descrizione oltre al nome e al tipo dei web methods che il servizioespone. In questa fase è necessario tenere in considerazione che operazioni one-way e two-way nonpossono condividere la stessa porta fisica pena il malfunzionamento dell’operazione one-way. Bisognaquindi valutare di separare le operazioni in base al tipo in servizi distinti.Infine il wizard chiede di inserire un namespace per il servizio e un address per l’endpoint. Con questeultime informazioni la procedura termina e viene eseguita la creazione di un endpoint in IIS accessibile perconsumare l’applicazione.I servizi pubblicati secondo la procedura appena descritta sono:GroupManagementServiceTipo Two-wayBinding WSHttpNamespace http://Teorema.slimTruck.BT.Services.HubGroupManagementAddress http://localhost/HubGroupManagementMethods  Assemble  DisassembleGroupUpdateServiceTipo One-wayBinding WSHttpNamespace http://Teorema.slimTruck.BT.Services.HubGroupUpdateAddress http://localhost/HubGroupManagementMethods  UpdateGroupStatusAlarmMonitoringServiceTipo One-wayBinding BasicHttpNamespace http://Teorema.slimTruck.BT.Services.HubAlarmMonitoringAddress http://localhost/HubAlarmMonitoringMethods  CreateAlarmPositionMonitoringService 6-129
  • 134. Tipo Two-wayBinding BasicHttpNamespace http://Teorema.slimTruck.BT.Services.HubPositonMonitoringAddress http://localhost/HubPositonMonitoringMethods  NotifySafeLocationConsoleServiceTipo Two-wayBinding WSHttpNamespace http://Teorema.slimTruck.BT.Services.HubConsoleAddress http://localhost/HubConsoleMethods  GetStatus  GetObcEvents  GetGroupId6.2.8 Porte fisiche e bindingCome anticipato nel paragrafo precedente le orchestrazioni devono essere configurate eseguendo dueoperazioni:  Associazione dell’orchestrazione ad un host  Binding fra porte logiche e porte fisichePrima di poter scegliere un host è necessario fare qualche considerazione sugli host. Un Host è uncontenitore logico che permette di suddividere la gestione della componente di messagistica in gruppi chepossono essere distribuiti su più processi in memoria e su più macchine. Spesso un host è usato perseparare adapter, orchestration e porte per essere eseguiti su macchine separate. Questa proceduraprende il nome di load balancing.Un Host Instances è un’istanza di un particolare Host. L’istanza è un servizio chiamato BTSNTSvc.exe.Questo processo fornisce al motore Biztalk un posto dove eseguire e permette di eseguire l’instanziamentodi host diversi sulla macchina. Ogni host instance finisce per essere un istanza di BTSNTSvc.exe. L’hostinstance esiste per garantire ai sottoservizi di Biztalk un posto dove eseguire.Biztalk distingue fra:  host in-process  Isolated host 6-130
  • 135. Gli isolated host devono essere eseguiti sotto un altro processo. I tools di amministrazione di Biztalk nonsono in grado di determinare lo stato degli isolated hosts. Per questi hosts si crea in genere un accountspecifico con permessi minimi in quanto ricevono messaggi da sorgenti non sicure.Gli host in-process invece devono essere eseguiti sotto un account che è all’interno del Windows groupdell’in-process host e non mantengono un contesto sicuro all’interno della messagebox.Spesso gli isolated Host eseguono solo un istanza dell’Endpoint Manager e sono responsabili della ricezionedal suo protocollo di trasporto e dell’invio dei messaggi dalla messagebox attraverso l’EPM. Oltre che ad IISgli isolated host possono essere associati a servizi Windows. Gli isolated process non richiedono uninterprocess comunication(IPC) tra EPM e il servizio Windows che li ospita. L’unico vero IPC tra isolated hoste messagebox è un servizio database molto spesso ospitato su un altra macchina.I sotto-servizi della host instance sono:  Caching: fa il cache di informazioni: ad esempio assembly caricati, informazioni sulla configurazione degli adapter.  EPM: responsabile dell’esecuzione di pipeline e trasformazioni Biztalk. E’ posto tra il message agent e l’adapter framework.  Tracking: muove informazioni dalla messagebox verso il database di tracking  XLANG/s: host engine per le orchestrazioni  MSMQT: adapter service che serve per rimpiazzare MSMQ nelle interazioni con Biztalk server. E’ stato deprecatoNell’installazione utilizzata ai fini di questo progetto sono previsti solo due host:  BiztalkServerApplication di tipo in-process: host a cui vengono associate le orchestrazioni  BiztalkServerIsolatedHost di tipo Isolated: host a cui vengono associate le receive port di tipo WCFPer completare la configurazione delle orchestrazioni ed eseguire quindi il binding delle porte è necessariodefinire le porte fisiche. Le porte fisiche si dividono in porte di receive e porte di send. Le porte di receivedefinite dall’applicazione sono quelle associate ai servizi web ospitati in IIS descritti al paragrafoprecedente.Le porte di send utilizzate sono di due tipi: SQL e WCF. Quelle usate per la comunicazione con SQL Serversono state create insieme alla generazione degli schema utilizzando la funzione Add Adapter Metadata diVisual Studio. Le porte di tipo WCF usate per la comunicazione con i servizi web esposti dal Gateway e dallagetione emergenze invece devono essere definite manualmente. 6-131
  • 136. Di seguito è riportata come esempio la configurazione della porta send di tipo SQL utilizzata per ottenereun messaggio di stato a partire dall’identificativo del gruppo: Figura 39 - Configurazione di una porta di tipo SQLSi è cercato di scegliere i nomi delle porte in modo che forniscano le informazioni più importanti sulla loroconfigurazione. In particolare, le prime due lettere indicano se si tratta di una porta di send(SP) direceive(RP) o di una receive location(RL), di seguito un’abbreviazione del nome dell’adapter e unadescrizione dell’operazione associata. Il nome della porta, la cui configurazione è riportata in figura èSP_SQLStatusMessageRead. La configurazione dell’adapter SQL prevede l’inserimento di una stringa diconnessione al database, del target namespace del documento coinvolto e il nome del root element delmessaggio di response.Tra i parametri di configurazione della porta si possono scegliere le pipeline di send e receive nel caso laporta sia di tipo request-response. Nella maggior parte dei casi la pipeline di send è di tipo Passthru inquanto non sono richieste validazioni mentre la pipeline di receive è di tipo XMLReceive per consentire aBiztalk di individuare il messageType del documento.Per quanto riguarda la configurazione delle porte WCF, la procedura di configurazione è simile eccetto perquanto riguarda la parte generale. Cambia la configurazione della parte riguardante l’adapter: 6-132
  • 137. Figura 40 - Configurazione di una porta di tipo WCFNella figura sono mostrate le due schede più importanti. Nella tab Generale viene inserito l’indirizzo alquale è disponibile il servizio: http://localhost:1087/GatewayOperationsl’endpoint identity che in questo caso ha il valore localhost e alcune informazioni da inserire nell’headerdella busta SOAP. Nel caso di un servizio che espone una sola operazione è sufficiente indicare Il suoindirizzo. Se invece, come in questo caso, il servizio espone più operazioni bisogna definire un mapping fral’Operation Name definito nel context property del messaggio e l’Action comunicato al servizio. Il mappingdefinito per questa porta è il seguente: <BtsActionMapping xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <Operation Name="ConfigureObcEvents" Action="http://Teorema.slimTruck.BT.Services/GatewayService/ConfigureObcEvents" /> <Operation Name="GetGroupId" Action="http://Teorema.slimTruck.BT.Services/GatewayService/GetGroupId" /> <Operation Name="SetGroupId" Action="http://Teorema.slimTruck.BT.Services/GatewayService/SetGroupId" /> <Operation Name="GetObcEvents" Action="http://Teorema.slimTruck.BT.Services/GatewayService/GetObcEvents" /> <Operation Name="ShutdownObc" Action="http://Teorema.slimTruck.BT.Services/GatewayService/ShutdownObc" /> <Operation Name="GetStatus" Action="http://Teorema.slimTruck.BT.Services/GatewayService/GetStatus" /> 6-133
  • 138. </BtsActionMapping>Nella tab Messages si offre la possibilità di specificare il body del messaggio WCF in uscita. Si può sceglieredi farlo coincidere con il body del messaggio Biztalk oppure definire un template. Lo stesso vale per imessaggi in entrata. Si può scegliere se il body rappresenta:  Envelope: l’interno contenuto del messaggio soap <soap:Envelope>  Body: solo il contenuto del element <soap:Body>  Path: un percorso all’interno del bodyQueste operzioni possono essere utili in situazioni particolari per permettere l’interoperabilità. Non èpresente una scheda che permette di scegliere il tipo di binding perchè è implicito nel tipo di adapterscelto. L’adapter scelto per questa porta è WCF-WSHttp.Le porte fisiche così create devono essere associate alle porte logiche delle orchestrazioni per completare ilbinding. Questa operazione si esegue accedendo nella finestra proprietà delle orchestrazioni alla sezioneBindings: Figura 41 - Configurazione del binding di una orchestrazioneNella figura si può notare come le porte di receive siano separate dalle porte di send. L’associazione vieneeseguita agendo su dei controlli combobox che mostrano per ognuna dei due datagrid l’elenco delle portedisponibili. 6-134
  • 139. Quando un orchestrazione è configurata correttamente scompare dalla descrizione del suo stato la dicituraUnbound e l’orchestrazione può passare agli stati Enlist e Start. Sia per le porte che per le orchestrazioniviene distinto lo stato Enlist da Start.Gli artifact nello stato Unenlisted non hanno sottoscrizioni nella message box, mentre quelli nello statoEnlisted sono pronti a eseguire il processing dei messaggi ma non c’è modo per il message engine di inviarlia loro. Porte e orchestrazioni Enlisted ma non Started hanno accodati nella messagebox tutti i messaggi cherendono valide le sottoscrizioni in attesa di essere avviate. Quando una porta è Enlisted il message agentcrea sottoscrizioni per ogni tipo di messaggio la cui context property TransportID corrisponde alTransportID della porta. Per le orchestrazioni esso crea la sottoscrizione basandosi sul MessageType delmessaggio inviato alla porta all’interno dell’orchestrazione. Fare il binding di una porta logica con una portafisica forza l’EPM a scrivere informazioni su quel binding nel database di management.Le porte fisiche descritte finora erano finalizzate all’associazione con una porta logica all’interno di unorchestrazioni. Esistono porte che non necessitano di associazione ma che definiscono direttamente unasottoscrizione tramite la definizione di un filtro: Figura 42 - Definizione di una sottoscrizioneLa definizione del filtro può essere completata dalla sezione Filters della finestra Properità della porta. Inquesto caso di vuole che la porta di send invii solo i messaggi che verificano il MessageTypehttp://Teorema.slimTruck.BT.Schemas.AlarmOBC#Alarm. 6-135
  • 140. Quando tutte le porte e le orchestrazioni e le porte di send sono nello stato Started e le porte di Receivesono nello stato Enabled l’applicazione è completamente avviata.6.2.9 Export dell’applicazione e installazioneLo sviluppo di un applicazione Biztalk segue un comune deployment cycle che si articola in 5 passi:  Deploy degli assembly della solution usando Visual Studio. Serve per eseguire il deploy nell’ambiente di sviluppo o In GAC o Nel database di configurazione  Aggiunta degli artifact dalla console di amministrazione o Creazione di binding files o Aggiunta di script o Aggiunta di altri artifact( ad esempio certificati)  Esportazione dell’applicazione in MSI  Importazione e installazione dell’MSI file nell’ambiente target  Starting dell’applicazione e verifica del corretto funzionamentoLa fase di esportazione di un applicazione consiste nel prendere tutti gli artifact ad essa relativi eimpacchettarli in un MSI file. La funzione di esportazione si trova nel menu contestuale dell’applicazionenella console di amministrazione. Si possono eseguire tre tipi di esportazione:  MSI  Bindings  PoiliciesIl file MSI così esportato può essere distribuito per l’installazione nell’ambiente target. L’operazione sisvolge in due fasi. Per prima cosa si deve eseguire l’importazione dell’applicazione dalla console diamministrazione. In questo modo si ottiene il salvataggio delle informazioni relative all’applicazione neldatabase di management e di tutti i relativi artifact. Questa operazione non è però sufficiente. E’ necessarioeseguire l’installazione dell’MSI per caricare nella GAC gli assembly definiti come risorse e per la creazionedelle eventuali directory virtuali e degli endpoint nel web server che fa da host per i servizi esposti. Leapplicazioni web create non devono fare riferimento all’application pool di default ma ad un applicationpool definito appositamente. La configurazione richiesta prevede la scelta di .NET framework 4 e lamodifica della proprietà Identity con le credenziali dell’utente individuato come proprietario dell’isolatedhost di Biztalk. Inoltre è necessario separare le applicazioni in base al binding utilizzato. In questo caso sono 6-136
  • 141. stati usati due tipi di binding e devono essere creati due application pool. Ad uno verranno associati i serviziche usano WSHttp e all’altro quelli che usano BasicHttp.6.3 Console e servizi di supporto6.3.1 Accesso ai datiUn approccio di progettazione comune e consolidato quando si compila unapplicazione o un servizioconsiste nel dividere lapplicazione o il servizio in tre parti: un modello di dominio, un modello logico e unmodello fisico. Il modello di dominio definisce le entità e le relazioni nel sistema da modellare. Il modellologico per un database relazionale normalizza le entità e le relazioni in tabelle con vincoli di chiave esterna.Il modello fisico gestisce le funzionalità di un determinato motore dei dati specificando dettaglisullarchiviazione come il partizionamento e lindicizzazione.Il modello fisico viene ridefinito dagli amministratori del database per migliorare le prestazioni, ma iprogrammatori che scrivono il codice delle applicazioni tendono a utilizzare solo il modello logico scrivendoquery SQL e chiamando stored procedure. I modelli di dominio vengono in genere utilizzati comestrumento per lacquisizione e la comunicazione dei requisiti di unapplicazione, spesso come diagrammiinerti visualizzati e discussi nelle fasi iniziali di un progetto e quindi abbandonati. Molti team di svilupposaltano la fase di creazione di un modello concettuale e partono direttamente dallindicazione di tabelle,colonne e chiavi in un database relazionale.Entity Framework favorisce la realizzazione dei modelli in quanto consente agli sviluppatori di eseguirequery su entità e relazioni del modello di dominio (denominato modello concettuale in Entity Framework)basandosi al tempo stesso su Entity Framework per convertire le operazioni in comandi specifici delloriginedati. Le applicazioni non sono quindi più vincolate a dipendenze hard-coded su una determinata originedati. Il modello concettuale, il modello di archiviazione e i mapping tra i due vengono espressi in schemibasati su XML e definiti in file con estensioni corrispondenti:  Il linguaggio CSDL (Conceptual Schema Definition Language) definisce il modello concettuale. CSDL è limplementazione di Entity Framework di Entity Data Model. Lestensione del file è csdl.  Il linguaggio SSDL (Store Schema Definition Language) definisce il modello di archiviazione, chiamato anche modello logico. Lestensione del file è ssdl.  Il linguaggio MSL (Mapping Specification Language) definisce i mapping tra il modello di archiviazione e il modello concettuale. Lestensione del file è msl.Il modello di archiviazione e i mapping possono essere modificati in base alle esigenze senza che sianecessario modificare il modello concettuale, le classi di dati o il codice dellapplicazione. Poiché i modelli di 6-137
  • 142. archiviazione sono specifici del provider, è possibile utilizzare un modello concettuale coerente in varieorigini dati.Questi file del modello e di mapping vengono utilizzati da Entity Framework per trasformare operazioni dicreazione, lettura, aggiornamento ed eliminazione di entità e relazioni del modello concettuale inoperazioni equivalenti nellorigine dati. Entity Framework supporta anche il mapping di entità del modelloconcettuale a stored procedure dellorigine dati. Per ulteriori informazioni, vedere Specifiche CSDL, SSDL eMSL.I livelli di accesso ai dati in questa solution sono rappresentati dai progetti:  Teorema.slimTruck.Console.DAL: definisce un Entity Data Model associato al db interno a Biztalk. Definisce solo l’entità allarme per ottenere le istanze delle emergenze da mostrare all’operatore  Teorema.slimTruck.Console.Support.DAL: definisce in Entity Data Model associato al db di supporto. Definisce le entità: o OnBoardComputer: contiene le informazioni sugli obc o Path: definisce i percorsi disponibili. o PathVertex: contiene coppie di coordiante geografiche associate a percorsi o RfidTag: contiene le informazioni sui tag rfid o Tractor: contiene le informazioni sulle motrici o Truck: contiene le informazioni sui gruppi o TruckInfo: contiene i messaggi di stato ricevuti dalla componente gestione emergenzeUn Entity Data Model definisce prima di tutto delle informazioni di configurazione contenute nel fileApp.config:<connectionStrings> <add name="GatewayModelContainer" connectionString="metadata=res://*/GatewayModel.csdl|res://*/GatewayModel.ssdl|res:// */GatewayModel.msl;provider=System.Data.SqlClient;provider connection string=&quot;Data Source=.;Initial Catalog=slimTruckGateway;Integrated Security=True;MultipleActiveResultSets=True&quot;" providerName="System.Data.EntityClient" /> </connectionStrings>Il nome del modello è GatewayModelContainer e il provider per la connessione al database èSystem.Data.SqlClient. La stringa di connessione contiene il nome del server, che in questo caso è indicatodal carattere “.”(punto) e significa server locale mentre il nome scelto per il database è slimTruckGateway. 6-138
  • 143. Per ogni entità è stata definita una classe che ha lo stesso nome dell’entità seguito dal prefisso SQL([NomeEntità]SQL). Questa classe implementa le operazioni Create, Read/Get e Update per quell’entità. Diseguito è riporta il codice relativo all’entità OnBoardComputer: 6-139
  • 144. public static OnBoardComputer Create(OnBoardComputer obc){ OnBoardComputer result = null; using (GatewayModelContainer model = new GatewayModelContainer()) { try{ model.OnBoardComputerSet.AddObject(obc); model.SaveChanges(); result = model.OnBoardComputerSet.Where(o => o.Id == obc.Id).First(); } catch (ArgumentNullException) { } catch (System.InvalidOperationException) { } } return result; } public static List<OnBoardComputer> GetAll() { List<OnBoardComputer> result = new List<OnBoardComputer>(); using (GatewayModelContainer model = new GatewayModelContainer()){ try{ result = model.OnBoardComputerSet .OrderBy(o=>o.Code).ToList(); } catch (ArgumentNullException) { } catch (System.InvalidOperationException) { } } return result; } public static OnBoardComputer Get(string code){ OnBoardComputer obc=null; using (GatewayModelContainer model = new GatewayModelContainer()){ try{ obc=model.OnBoardComputerSet.Where(o => o.Code == code).First(); } catch(ArgumentNullException){} catch (System.InvalidOperationException) { } } return obc; } public static bool Update(OnBoardComputer obcParam){ using (GatewayModelContainer model = new GatewayModelContainer()){ try{ model.Attach(obcParam); model.ObjectStateManager.ChangeObjectState( obcParam, System.Data.EntityState.Modified); model.SaveChanges(); return true; } catch (ArgumentNullException) { } catch (InvalidOperationException) { } catch (OptimisticConcurrencyException) { } } return false; }Per le altre entità il codice è molto simile. Si può notare che tutte le operazioni vengono eseguite da metodistatic e quindi viene creata per ogni operazione un istanza del modello. Questo metodo di utilizzo del data 6-140
  • 145. model è poco convenzionale perché non sfrutta le funzionalità di entity framework di rilevazione dellemodifiche sulle entità. Se un entità contiene solo tipi primitivi allora non ci sono considerazioni di rilievo,mentre le operazioni diventano più complesse quando una classe definisce membri che utilizzano cometipo un’altra entità. Per quanto riguarda l’operazione di inserimento bisogna tenere conto che il metodoAddObject definito nella classe ObjectSet non è in grado di capire se l’entità annidata esiste già oppure no,e come comportamento standard ne esegue la creazione. Questo comportamento non è corretto sel’instanza dell’entità annidata è già stata resa persistente nel db. In questo caso prima di eseguire il metodoAddObject è necessario segnalare quali entità esistono già utilizzando il metodo Attach sull’istanza delmodello. Ad esempio il codice per la creazione di Truck si presenta come segue: model.OnBoardComputerSet.Attach(truck.OnBoardComputer); model.TractorSet.Attach(truck.Tractor); model.RfidTagSet.Attach(truck.RfidTag1); if (truck.RfidTag2 != null) model.RfidTagSet.Attach(truck.RfidTag2); model.TruckSet.AddObject(truck); model.SaveChanges(); result = model.TruckSet .Include("OnBoardComputer") .Include("RFIDTag1") .Include("RFIDTag2") .Include("Tractor") .Where(t => t.Id == truck.Id).First();Prima di aggiungere il nuovo gruppo al modello sono stati eseguiti gli attach di tutte le entità contenute. Sipuò anche osservare che in fase di lettura del gruppo è stato utilizzato il metodo Include per ogni entitàcontenuta all’interno del gruppo. Senza eseguire Include la navigazione all’interno delle entità di un grupponon è possibile dopo la restituzione con lo statement return.6.3.2 Servizi pubblicatiNella solution relativa alla console sono stati definiti alcuni progetti necessari alla simulazione dellecomponenti gateway e gestione emergenze. Questi progetti si distinguono dagli altri riportando nel nome ilprefisso Support. E’ necessario creare questa parte di simulazione per verificare il funzionamento dell’Hub el’effettiva presenza di tutte le funzionalità individuate nella fase di analisi. Le due componenti simulateavranno il doppio ruolo di:  Ricevere richieste dall’Hub che rispettano il formato dei messaggi definiti nella fase di analisi e rispondere utilizzando messaggi altrettanto validi sia dal punto di vista sintattico che semantico. I messaggi di risposta devono essere strutturati correttamente e devono contenere informazioni correlate ai valori dei parametri delle richieste. Le risposte non devono essere generate in modo aleatorio al momento di ricezione della richiesta. 6-141
  • 146.  Attivarsi in corrispondenza al verificarsi degli eventi previsti in fase di analisi e inviare le informazioni all’hub utilizzando messaggi che rispettano la struttura concordata.In entrambi i casi le richieste possono seguire sia il paradigma Solicit-Response, prevedendo che ognirichiesta sia seguita da una risposta, sia One-Way, prevedendo che l’operazione si concluda con l’inviodella richiesta senza attesa di riscontro da parte del servizio.Il compito di listening per l’attesa di richieste è stato realizzato esponendo dei web service creati con WCFche l’hub può consumare. La gestione degli eventi esterni e il conseguente invio all’hub di informazioni sirimanda invece ai paragrafi successivi in cui viene descritto l’algoritmo per la generazione di coordinategeografiche attraverso la simulazione dello spostamento dei veicoli sul territorio e le funzionalità messe adisposizione dall’interfaccia del sistema.L’architettura di WCF si basa sui servizi ed in particolare sui messaggi che questi servizi permettono discambiare. A grandi linee i componenti fondamentali di WCF sono quindi il messaggio, il mittente ed ildestinatario.A questi componenti si affiancano i corrispondenti Layer che ospitano tutte le funzionalità e le classinecessarie alla gestione di ciascun momento della comunicazione. I layer sono:  Contracts Layer  Service Model Layer  Messaging Layer  Hosting LayerQuesta separazione di WCF in layer consente di mantenere ben separati i vari strati preposti alla gestionedella comunicazione tra il servizio ed i suoi client.Non vi è un solo tipo di contratto in WCF ma vi sono cinque tipologie ben definite di possibili contratti cheun servizio WCF può esporre ai suoi client:  Service Contract  Data Contract  Message Contract  Fault Contract  Callback ContractIl Service Contract è il contratto tipico di un servizio WCF che definisce le funzionalità del servizio, iparametri da passare e da ricevere e le modalità di fruizione. 6-142
  • 147. I parametri definiti in un Service Contract sono rappresentati dai tipi semplici del .NET Framework, quindinel momento in cui questi tipi semplici non sono più sufficienti per gli scopi del servizio e si ha la necessitàdi utilizzare tipi custom più complessi, allora è possibile realizzare un Data Contract, che definisce appunto itipi custom che si intende utilizzare per lo scambio di dati da e verso il servizio.Se oltre alle informazioni strettamente necessarie alla specifica operazione che il servizio deve compiere, siha anche la necessità di scambiare dati accessori che quindi non fanno parte della singola funzionalità maservono al contesto di esecuzione del servizio, allora si possono implementare un Message Contract chepermette appunto di gestire informazioni generiche relative al servizio in se e non alla specifica operazione.Quando abbiamo la necessità di gestire le eccezioni, possiamo invece far uso di un Fault Contract perdefinire anche in caso di errori, quale convenzione utilizzare per comunicarlo al client. Questo tipo dicontratto non è obbligatorio ma ci consente comunque di mantenere un maggior controllo sul nostroservizio.Infine un Callback Contract è un contratto molto particolare che, implementato sul client invece che sulserver, permette in un preciso momento di invertire i ruoli e consentire quindi al server di contattare ilclient per comunicargli informazioni particolari.E’ stato creato un web service per ognuna delle due componenti. Il servizio relativo al Gateway espone treoperazioni:  Riconoscimento dell’identificativo del gruppo attualmente associato ad un obc.  Recupero delle informazioni sullo stato attuale di un gruppo  Recupero delle informazioni relative alla configurazione attuale degli eventi associati ad un obcTutte e tre le operazioni descritte sono di tipo Solicit-Response e vengono esposte utilizzando un binding ditipo WSHttp che permette una comunicazione meno veloce rispetto al binding BasicHttp ma supporta lespecifiche WS-Security nel caso si voglia introdurre un meccanismo di autenticazione del client e del server.Il servizio relativo alla componente di gestione emergenze espone una sola operazione:  Ricezione delle informazioni che descrivono lo stato dei gruppo attualmente in movimento lungo il percorso fra porto e retroporto.L’operazione esposta è di tipo One-way e utilizza BasicHttp binding. Questa scelta è giustificata dallanecessità di un elevato grado di interoperabilità. Il dettaglio del servizio esposto dalla componente digestione emergenze non sono ancora stati resi noti. L’unica informazione disponibile è che lo scambio dimessaggi utilizza il protocollo SOAP. BasicHttp è tra tutti, il binding WCF che meglio si adatta alle necessità 6-143
  • 148. di interoperabilità con servizi sviluppati con tecnologie poco recenti o di altri partner. BasicHttp utilizzahttp come protocollo di trasporto e Text come meccanismo di codifica secondo la versione di messaggiSOAP1.1.La creazione dei web services consiste in:  definizione dei contratti dei dati  definizione dei contratti dei servizi  implementazione dei serviziOgni componente è definito all’interno di un progetto di tipo Class Library separato dagli altri. I contrattidei dati e dei servizi sono definiti all’interno del progetto Teorema.slimTruck.Console.Support.Contracts.Questo progetto contiene la definizione di tutte le classi che rappresentano i messaggi scambiati con l’Hubottenuta utilizzando il tool Xsd.exe secondo lo stesso procedimento visto in precedenza per la creazione deidata contract nella solution relativa all’hub. Le definizioni delle classi sono corredate di tutti gli attributinecessari alla serializzazione xml.In questo caso sono state create delle ulteriori classi che rappresentano i contratti dei dati utilizzati dalservizio. Viene riportata di seguito, come esempio, la definizione delle classi relative ai messaggi di richiestae risposta dello stato dei gruppi da parte dell’hub: 6-144
  • 149. [System.Diagnostics.DebuggerStepThroughAttribute()] [System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")] [System.ComponentModel.EditorBrowsableAttribute( System.ComponentModel.EditorBrowsableState.Advanced)] [System.ServiceModel.MessageContractAttribute(IsWrapped = false)] public partial class TTStatusClaimRequest { [System.ServiceModel.MessageBodyMemberAttribute(Name = "Req", Namespace = "http://Teorema.slimTruck.BT.Schemas.TTStatusClaim", Order = 0)] public Teorema.slimTruck.Console.Support.Contracts.Req5 req; public TTStatusClaimRequest() { } public TTStatusClaimRequest(Teorema.slimTruck.Console.Support.Contracts.Req5 req) { this.req = req; } } [System.Diagnostics.DebuggerStepThroughAttribute()] [System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")] [System.ComponentModel.EditorBrowsableAttribute( System.ComponentModel.EditorBrowsableState.Advanced)] [System.ServiceModel.MessageContractAttribute(IsWrapped = false)] public partial class TTStatusClaimResponse { [System.ServiceModel.MessageBodyMemberAttribute(Name = "Resp", Namespace = "http://Teorema.slimTruck.BT.Schemas.TTStatusClaim", Order = 0)] public Teorema.slimTruck.Console.Support.Contracts.Resp5 resp; public TTStatusClaimResponse() { } public TTStatusClaimResponse(Teorema.slimTruck.Console.Support.Contracts.Resp5 resp) { this.resp = resp; } }Alle classi viene applicato l’attributo MessageContract definito nel namespace System.ServiceModel,mentre alle proprietà viene applicato l’attributo MessageBodyMember.Utilizzando message contract si può eseguire una personalizzazione della struttura dei messaggi indicandoquali informazioni devono essere inserite nell’header e quali nel body della busta SOAP. Sono stati utilizzatigli attributi di message contract perché il servizio non utilizza il metodo di serializzazione di defaultDataContractSerializer ma utilizza invece XmlSerializer.I contratti di servizio sono definiti dalle due interfacce IGatewayService e IEmergencyService. Alladefinizione dell’interfaccia viene applicato l’attributo ServiceContract per identificare il servizio e le sueproprietà come il nome e il namespace. Alla definizione dei metodi vengono applicati gli attributi 6-145
  • 150. OperationContract per identificare l’operazione e XMLSerializerFormat per specificare il tipo diserializzatore utilizzato. [ServiceContract(Name="GatewayService", Namespace = "http://Teorema.slimTruck.BT.Services")] public interface IGatewayService { [OperationContract] [System.ServiceModel.XmlSerializerFormatAttribute(SupportFaults = true)] TTConfigureOBCEventsResponse ConfigureObcEvents(TTConfigureOBCEventsRequest request); [OperationContract] [System.ServiceModel.XmlSerializerFormatAttribute(SupportFaults = true)] TTGetGroupIdResponse GetGroupId(TTGetGroupIdRequest request); [OperationContract] [System.ServiceModel.XmlSerializerFormatAttribute(SupportFaults = true)] TTSetGroupIDResponse SetGroupId(TTSetGroupIDRequest request); [OperationContract] [System.ServiceModel.XmlSerializerFormatAttribute(SupportFaults = true)] TTGetOBCEventsResponse GetObcEvents(TTGetOBCEventsRequest request); [OperationContract] [System.ServiceModel.XmlSerializerFormatAttribute(SupportFaults = true)] TTShutdownOBCResponse ShutdownObc(TTShutdownOBCRequest request); [OperationContract] [System.ServiceModel.XmlSerializerFormatAttribute(SupportFaults = true)] TTStatusClaimResponse GetStatus(TTStatusClaimRequest request); } [ServiceContract(Name = "EmergencyService", Namespace = "http://Teorema.slimTruck.BT.Services")] public interface IEmergencyService { [OperationContract] [System.ServiceModel.XmlSerializerFormatAttribute(SupportFaults = true)] void GroupUpdateStatus(GroupStatusUpdateMessage message); }All’interno del progetto Teorema.slimTruck.Console.Support.Services è invece definita l’implementazionedei due servizi. Contiene due classi GatewayService e EmergencyService che implementano le interfacce deirelativi contratti e definiscono la logica delle operazioni del servizio.6.3.3 Simulazione dei percorsiLo sviluppo della componente Gateway prevede l’implementazione di un meccanismo di generazione dicoordinate geografiche deterministico. E’ necessario per simulare in modo verosimile il movimento deigruppi lungo percorsi scelti a priori. E’ stato individuato un unico percorso tra le aree del porto e del 6-146
  • 151. retroporto di Fernetti e di questo percorso sono state individuate coppie di coordinate geografichesufficienti a descriverlo in modo sommario. Le coppie di coordinate vengono salvate nel database disupporto, associate ad un percorso e numerate con un interno progressivo che ne determina l’ordine.L’idea di base è quella di scegliere un percorso e una velocità di crociera, e calcolare ad intervalli costanti ditempo la posizione all’interno del percorso utilizzando la legge oraria del moto uniforme: x = x0 + vtPer prima cosa è stata creata un’estensione della classe Path e PathVertex in cui definire i metodi necessarial calcolo della distanza fra coordinate geografiche e al calcolo della posizione all’interno di un percorso. Leclassi Path e PathVertex sono definite nell’Entity Data Model del database di supporto come partial class.I metodi necessari al calcolo delle distanze sono:  DistanceTo: definito nella classe PathVertex. Restituisce un valore double che rappresenta la distanza in Km da un punto che viene indicato come parametro.  DirectionTo: definito nella classe PathVertex. Restituisce un valore double che rappresenta l’angolo in gradi decimali della direzione verso un punto indicato come parametro.  PointAtDistance: definito nella classe PathVertex. Restituisce una nuova istanza di PathVertex che contiene le coordinate del punto che si trova a valori di distanza e direzione dal punto corrente indicati come parametro.Siano definiti due punti A(φ1, λ1) e B(φ2, λ2), in cui la prima coordinata rappresenta la latitudine e la secondala longitudine. Definita Δλ la differenza di longitudine, la distanza angolare tra i due punti considerati (A,B)vale: {√[ ] [ ] } { }che fornisce la distanza in radianti. Basta moltiplicare il risultato Δσ per il raggio della Terra(6372.795477598 Km) per ottenere la distanza in Km.Per determinare la direzione θ dal punto iniziale tra due punti della terra, viene utilizzata la seguenteformula: ( ) ( ) ( ) | | 6-147
  • 152. ( )Per determinare il punto di destinazione, conoscendo il punto iniziale (φ1,λ1) la direzione θ e la distanza d,viene utilizzata la seguente formula: ( ) ( )Queste funzioni sono state implementate utilizzando i metodi statici della classe System.Math.L’implementazione vera del meccanismo di simulazione di spostamento è contenuto nella classePathSimulator. I parametri chiesti dal costruttore di PathSimulator sono:  Istanza della classe Truck  Istanza della classe Path  Velocità del veicoloIl costruttore si limita a copiare i riferimenti degli oggetti passati in istanze definite internamente allo scopedella classe.La classe PathSimulator prevede il metodo Init() senza parametri per effettuare il reset dello stato dell’obc edei tag rfid ponendo tutti i flag al valore di corretta attività(tutti i flag valgono true eccetto quello relativoalla pressione del pulsante). Oltre al reset della strumentazione viene creata un collection di tipochiave/valore in cui viene calcolata per ogni vertice del percorso la distanza dall’origine. La chiave èrappresentata dall’ordine del vertice all’interno del percorso. Questa collection definita comeDictionary<int,double> e definita all’interno della classe Path.Un’istanza della classe PathSimulator su cui è stato eseguito il metodo Init() rappresenta logicamente ungruppo pronto ad essere avviato. L’avvio corrisponde all’esecuzione del metodo Start(). Il metodo Start()esegue un loop che usa come condizione una proprietà booleana inizializzata al valore true e conmodificatore pubblico. All’interno del loop viene eseguito il metodo Sleep della classe Thread che generauna sospensione dell’esecuzione per 30 secondi configurabili. Dopo di che si calcola lo spostamento teoricodurante il periodo di attesa e lo si somma alla distanza già percorsa dall’origine. Con lo spostamento totale 6-148
  • 153. si calcola la posizione all’interno del percorso e si aggiornano i valori di latitudine e longitudine dell’obcoltre alla direzione e alla velocità sui due assi.Di seguito è riportato il codice delle parti più significative della classe PathSimulator: public void Init() { if ((PathSelected != null) && (TruckInstance != null)) { PathSelected.UpdateVertexDistances(); PathVertex initialVertex = PathSelected.GetFirst(); if (TruckManager.Reset( TruckInstance, initialVertex.Latitude, initialVertex.Longitude)) IsInitialized = true; } } 6-149
  • 154. public void StartTruck(){if (IsInitialized){ isWalking = true; isActive = true; double currentDistance = 0; PathVertex currentVertex = null; PathVertex previousVertex = PathSelected.GetFirst(); Thread.Sleep(new TimeSpan(0, 0, secondTimeInterval)); while (isActive){ if (isWalking) { currentDistance += TruckSpeed / 3600 * (secondTimeInterval); int c=PathSelected.PathVertex.Max(v=>v.OrderIndex); if (currentDistance < PathSelected.Distances[c]) { currentVertex=PathSelected.PointInPath(currentDistance); TruckInstance = TruckManager.Get(TruckInstance.Id); TruckInstance.OnBoardComputer.Latitude = currentVertex.Latitude; TruckInstance.OnBoardComputer.Longitude = currentVertex.Longitude; double direction=previousVertex.DirectionTo(currentVertex); TruckInstance.OnBoardComputer.Direction = direction; TruckInstance.OnBoardComputer.XAxisSpeed = Math.Abs(TruckSpeed * Math.Cos(Utility.Deg2Rad(direction))); TruckInstance.OnBoardComputer.YAxisSpeed = Math.Abs(TruckSpeed * Math.Sin(Utility.Deg2Rad(direction))); TruckManager.Update(TruckInstance); previousVertex = currentVertex; } else { currentVertex = PathSelected.PathVertex.OrderByDescending(v=>v.OrderIndex).First(); if (previousVertex != currentVertex) { TruckInstance = TruckManager.Get(TruckInstance.Id); TruckInstance.OnBoardComputer.Latitude = currentVertex.Latitude; TruckInstance.OnBoardComputer.Longitude = currentVertex.Longitude; TruckInstance.OnBoardComputer.Direction = previousVertex.DirectionTo(currentVertex); TruckManager.Update(TruckInstance); previousVertex = currentVertex; } } Teorema.slimTruck.Console.Support.ManagerServices.GroupUpdateRef.Message message= ManagerServices.GroupUpdateRef.Message.Parse(TruckInstance, 1101, null); Gateway2HubManager.UpdateGroupStatus(message); } Thread.Sleep(new TimeSpan(0, 0, secondTimeInterval)); }}} 6-150
  • 155. 6.3.4 InterfacciaDescrizioneLa seconda parte della fase di sviluppo consiste nella realizzazione di un interfaccia grafica per verificare ilfunzionamento del sistema e la presenza di tutte le funzionalità richieste in fase di analisi. L’interfacciaconsiste in un progetto di tipo Windows Form chiamato Teorema.slimTruck.Console.Presentation in cuisono definite alcune classi che ereditano da:  System.Windows.Forms.Form  System.Windows.Forms.UserControlLa struttura dell’interfaccia è abbastanza semplice. All’avvio viene mostrata una schermata da cui siscelgono le componenti che si vogliono visualizzare: Figura 43 - Schermata iniziale dellapplicazioneSono previsti in tutto tre pannelli, ognuno riferito ad una delle componenti collegate all’hub:  Pannello Console: contiene le informazioni che devono essere mostrate all’operatore che supervisiona lo spostamento delle merci.  Pannello Gateway: contiene le informazioni relative ai gruppi attivi e le funzioni per simulare il loro spostamento.  Pannello Emergency: contiene un elenco in cui ogni riga rappresenta un messaggio di aggiornamento sullo stato dei gruppi ricevuto dall’hub. Mette a disposizione le funzioni per l’invio di segnalazioni all’hub 6-151
  • 156. Assemble GatewayPanel Disassemble Alarm Main EmergencyPanel DestinationArrival GetGroupId ConsolePanel StatusClaim GetObcEvents Figura 44 - Funzionalità fornite dalle componentiPannello Console Figura 45 - Pannello relativo alla ConsoleIl pannello mostra un elenco che descrive le segnalazioni di allarme. Per ogni segnalazione viene indicato:  Identificativo del gruppo  Azione eseguita automaticamente dal sistema se esiste 6-152
  • 157.  Azione che deve essere eseguita dall’operatore  Problema riscontrato  Sistema che ha segnalato l’errore. Le segnalazioni possono essere generate dalla componente gestione emergenze(CGE) oppure dal business rule engine di biztalk che viene chiamato all’interno di un’orchestrazione specifica per analizzare i messaggi inviati dal gatewayL’operatore può fare click con il tasto destro del mouse per vedere il menu contestuale dal quale puòcambiare lo stato di ogni segnalazione in:  Presa in Carico  ChiusaLe segnalazioni quando vengono contrassegnate come chiuse spariscono dall’elenco.Sul lato sinistro del pannello sono presenti tre pulsanti che permettono di inviare richieste al gateway. Ilpulsante Richiesta Stato esegue l’apertura di una nuova form in cui si specifica l’identificativo di un obc e siottengono in risposta tutte le informazioni contenute nel messaggio di stato richiesto Figura 46 - Operazione di richiesta per ottenere informazioni di aggiornamento su un gruppoIl pulsante Richiesta Eventi esegue l’apertura di una nuova form in cui si specifica l’identificativo di un obc esi ottengono i valori di tutti i flag di stato dell’obc e dei tag ed inoltre un valore booleano che indica senell’obc è attiva la funzione di invio periodico dello stato. 6-153
  • 158. Figura 47 – Operazione di richiesta per ottenere gli eventi configurati su un obcL’ultimo pulsante porta l’etichetta Gruppo associato all’OBC ed esegue l’apertura di una form in cui sispecifica l’identificativo di un OBC e se è specificato in un gruppo attivo, allora viene restituitol’identificativo del gruppo. Figura 48 - Operazione per la richiesta di identificazione del gruppo associato a un obcIn entrambe le form è presente una barra di stato in cui viene mostrato un messaggio di errore in caso difallimento dell’operazione. Le operazioni di richiesta dello stato e di identificazione del gruppo prevedonol’invio in modo asincrono di un messaggio dal gateway verso l’hub contenente le informazioni chieste.Questo messaggio porta una motivazione di invio particolare e si distingue dagli altri per la presenzadell’identificativo di correlazione. 6-154
  • 159. Pannello Gateway Figura 49 - Pannello relativo alla componente GatewayLa maggior parte del pannello è dedicata ad un elenco che descrive i gruppi attivi. La descrizione prevedeuna sezione di lista e una sezione di dettaglio. Nella sezione di lista vengono mostrati:  Identificativo del gruppo  Identificativo dell’obc  Identificativo dei tag  Identificativo dei container  Stato del gruppoSelezionando una riga dall’elenco vengono aggiornate le informazioni nella sezione di dettaglio che mostratutti i flag di stato relativi all’obc e ai tag associati ai container. Inoltre viene segnalato se esiste unasimulazione attiva per il gruppo scelto.Facendo click con il tasto destro su una riga dell’elenco vengono visualizzate alcune funzioni la cuidisponibilità dipende dallo stato del gruppo. Le funzioni sono:  Avvia  Cambia stato  Arresta  Sciogli 6-155
  • 160. Se il gruppo si trova nello stato Abbinato e non esistono simulazioni attive allora si può scegliere avvia.Viene mostrata una nuova form dalla quale scegliere un percorso e una volta confermata la scelta ilgateway inizia ad inviare all’hub ad intervalli regolari di tempo di 30 secondi le informazioni sullo stato delgruppo. Nella sezione di dettaglio viene riportata la scritta Simulazione attiva e vengono abilitate le funzioniCambia Stato e Arresta del menu contestuale. L’inizio della simulazione consiste nella creazione diun’istanza della classe PathSimulator e della classe System.Threading.Thread. Il thread viene associatoall’istanza di simulazione e in particolare ad un suo metodo che viene eseguito invocando il metodo Start.L’istanza della classe che esegue la simulazione del movimento chiede come parametri di ingresso unistanza della classe Truck, un istanza della classe Path e un valore che indica la velocità di spostamento. Laclasse Truck rappresenta un gruppo mentre la classe Path rappresenta un percorso formato da un certonumero di unti intermedi. La parte di codice descritta è riportata di seguito: Path path = new Path(); Form pathForm = new PathSelectionForm(path); DialogResult result = pathForm.ShowDialog(); if (result == DialogResult.OK) { path = PathManager.Get(path.Id); PathSimulator simulator = new PathSimulator(truck, path, 70); simulator.Init(); Thread trd = new Thread(new ThreadStart(simulator.StartTruck)); trd.IsBackground = true; trd.Start(); }La funzione Cambia stato consente di cambiare il valore dei flag che indicano lo stato della strumentazione.Il valore attuale viene invertito eseguendo un operazione Not. Questa funzione è utile per testare ilfunzionamento dell’orchestrazione interna all’hub che individua situazioni allarme con il supporto delBusiness Rule Engine di Biztalk. Quando il veicolo termina il percorso scelto, il thread che esegue lasimulazione termina. In alternativa è possibile fermare il thread con il comando Arresta.Sul lato sinistro del pannello sono presenti i pulsanti Crea gruppo e Sciogli gruppo. Lo scioglimento puòessere eseguito in maniera più veloce dal menu contestuale perché il codice identificativo viene individuatoautomaticamente e non è necessario che sia inserito dall’utente.Il pulsante per la creazione di un nuovo gruppo apre una form in cui l’utente può inserire tutte leinformazioni necessarie alla vestizione attraverso controlli di tipo TextBox e ComboBox. 6-156
  • 161. Figura 50 - Operazione per la richiesta di vestizione di un gruppoIl pulsante per lo scioglimento di un gruppo apre una form in cui l’utente può inserire il codice di un gruppoattivo per eseguire la svestizione. Figura 51 - Operazione per la richiesta di svestizione di un gruppoIn entrambe le form è presente una barra di stato in cui viene mostrato un messaggio di errore in caso difallimento dell’operazione. 6-157
  • 162. Pannello Emergency Figura 52 - Pannello relativo alla componente di gestione emergenzeIl pannello mostra un elenco che descrive gli ultimi messaggi di stato ricevuti dall’hub. L’elenco è limitatoagli ultimi 30 messaggi in quanto le informazioni ricevute non devono essere utilizzate ma servono solo perverificare il funzionamento della sottoscrizione dei messaggi dall’hub verso la gestione emergenze. Perogni segnalazione viene indicato:  Identificativo del messaggio  Motivo di invio  Identificativo obc  Identificativo tag1  Identificativo tag2Sul lato sinistro del pannello sono presenti due pulsanti. Il pulsante Segnala Allarme fa apparire una nuovaform dalla quale si può creare una segnalazione. Sono presenti 5 controlli di input di cui tre sono di tipoTextBox per l’inserimento dell’identificativo del gruppo, dell’identificativo di un messaggio e per ladescrizione dell’azione da prendere e due sono di tipo ComboBox per la scelta dello stato dellasegnalazione e del problema riscontrato. 6-158
  • 163. Figura 53 - Operazione di segnalazione di un allarmeIl secondo pulsante ha l’etichetta Arrivo a Destinazione e anche questo fa aprire una nuova form checontiene un solo controllo per l’inserimento. Si tratta di un controllo di tipo TextBox in cui si specifical’identificativo del gruppo di cui si vuole segnalare l’arrivo a destinazione. Figura 54 - Operazione di notifica dellarrivo di un gruppo in zona sicuraConsole CompletaI tre pannelli descritti possono essere inseriti in una sola form contrassegnando con la spunta tutte lecaselle di scelta presenti nella schermata iniziale. La form che si presenta all’utente è simile a quella chesegue: 6-159
  • 164. Figura 55 - Schermata contenente tutti i pannelli di gestione 6-160
  • 165. ConclusioniIl lavoro svolto per questa tesi è durato un periodo di circa sei mesi. In questo periodo c’è stata una faseiniziale di formazione in cui è stato necessario acquisire conoscenze specifiche sul prodotto Biztalk Serverutilizzando manuali tecnici, articoli trovati nel web e consultando forum di sviluppatori. Successivamente èstata visionata la documentazione relativa al progetto SlimPort e nello specifico al sottosistema slimTruckper comprendere i processi di import/export delle merci e le operazioni sul campo degli operatori. Dopoaver ricevuto un documento di analisi in cui sono descritte le funzionalità previste dal sistema e la strutturadei messaggi scambiati è iniziata la fase di sviluppo. Durante questa fase sono state affrontate molteproblematiche in particolare nell’ambito di Biztalk. Questo prodotto presenta peculiarità che non possonoessere comprese attraverso uno studio superficiale ma che si presentano durante la realizzazione deiprogetti. L’approccio allo sviluppo deve tenere conto dei meccanismi specifichi del prodotto e in particolaredei concetti di pubblicazione e sottoscrizione su cui è basto il routing dei messaggi. Trattandosi di un hub dicomunicazione la maggior parte degli sforzi sono stati rivolti alla definizione degli schema e allaconfigurazione degli adapter utilizzati dalle porte.L’obiettivo che ci si era prefissati è stato raggiunto. E’ stata sviluppata un’applicazione con tutte lefunzionalità descritte di cui sono disponibili sia i sorgenti sia un file di installazione di tipo msi. Il file diinstallazione è necessario per importare l’applicazione in Biztalk Server evitando le fasi di deploy ecreazione dei binding tipiche di un ambiente di sviluppo ma non di un ambiente di produzione. Inoltre nellafase di installazione vengono importate nella GAC le class library necessarie e vengono create in IIS leapplicazioni relative ai web service esposti dall’hub.L’applicazione realizzata vuole essere un prototipo esplorativo per dimostrare l’effettiva fattibilità delprogetto e non è destinata ad un ambiente di produzione. Sono previsti in futuro ulteriori incontri perl’analisi delle componenti mancanti e la definizione delle specifiche di funzionamento. Una dellecomponenti che dovrà essere progettata è il MarketPlace che rappresenta il principale punto di accesso alsistema per fornitori, operatori portuali e clienti. Queste componenti dovranno trovare integrazione ancheall’interno dell’hub finora realizzato e si prevede quindi che il progetto ora disponibile verrà aggiornato conle nuove funzionalità.Questa esperienza è stata per me molto positiva perché ho potuto partecipare attivamente ad un progettoreale di notevoli dimensioni che coinvolge molte aziende. Ho avuto modo di approfondire la conoscenza di 6-161
  • 166. alcune tecnologie di sviluppo in ambiente Microsoft e di entrare in contatto con persone dall’elevato gradodi professionalità ed esperienza. 6-162
  • 167. BibliografiaI testi consultati per la realizzazione del progetto sono stati:  Mark Beckner, Ben Goeltz, Brandon Gross (September 2006) BizTalk 2006 Recipes: A Problem- Solution Approach, Apress  George Dunphy, Sergei Moukhnitski, Stephen Kaufman, Peter Kelcey, Harold Campos, David Peterson (2009) Pro Biztalk 2009, 1st edition, New York, Apress  Jim Dawson, John Wainwright (2009) Pro Mapping in Biztalk Server 2009, 1st edition, New York, Apress  Klein, Scott (2007), Professional WCF programming: .NET development with the Windows communication foundation, Indianapolis, IN 46256, Wiley Publishing, Inc.  Julia Lerman (2010) Programming Entity Framework, 2nd edition Sebastopol, CA 95472, O’ReillyI siti web più consultati sono stati:  http://msdn.microsoft.com/library/default.aspx: documentazione microsoft su .NET framework.  http://www.microsoft.com/downloads/en/default.aspx: centro per il download di software, documentazione e tutorial riguardanti prodotti microsoft.  http://www.biztalkgurus.com/forums/: forum frequentato da sviluppatori Biztalk. 6-163
  • 168. RingraziamentiArrivato a questo punto mi sento di dover ringraziare le persone che mi sono state vicine in tutti questianni, che non sono proprio pochi. I primi a cui va il mio pensiero sono sicuramente i miei genitori Edda eBattista che mi hanno sempre incoraggiato e sostenuto e mio fratello Valentino. Poi i miei zii Nello eDaniela, Antonio e Norina, e i miei cugini Patty, Fede e Enrico senza dimenticare Giuliano e Manu. Infine ivicini di casa Armando, Fiorenza, Francesco e tutta via Cernetta.Ci sono persone con cui ho trascorso solo brevi periodi e altre con cui ho condiviso gran parte delle mieesperienze. Tutte sono state importanti ma di alcune non avrei potuto fare a meno. I miei primi ricordiiniziano in una classe di 9 bambini. Sandro, Gianluca(Kendo), Francesco ed io: eravamo solo quattromaschietti e il nostro passatempo preferito erano i tornei di karate che si svolgevano regolarmente tutti igiorni durante lunghe ricreazioni che a volte riempivano gran parte della mattinata. In quegli anni nonc’erano molti impegni e i pomeriggi durante la bella stagione li trascorrevo all’aperto con il mio vicino dicasa Andrea facendo buchi in giardino, giocando a pallone o a tennis sulla ghiaia e cercando nascondigli difortuna nella campagna intorno a casa. Ci sono stati poi gli anni del pallone e la scuola media con Muro,Anza, Gianni, Alberto, Silla, Micio, Elia e poi Nicola, Maddalena, Anna, Maria, Federica, Marta, Stefania,Laura. Porto con me un bellissimo ricordo di quegli anni perché molti di quelli che ho conosciuto alloracontinuo a frequentare ancora oggi e ci sono molto affezionato: Andrea(Pitetta), Simone(Ciu), Checco, Ely,Elia, Davide, poi Ale, Luca, Krizia e Andrea anche se sono arrivati un po più tardi, Anna, AnnaP, Nicholas,Pippo, Gianluca Visotto(Bijoux). Checco viene citato più volte ma d’altra parte abbiamo fatto insiemepraticamente tutto per un sacco di anni. I compagni delle superiori Biduz, Calle, Pago, Daniele, Michael,Andrea Carrer, Alberto Perin, Olderic, Donato, Trevi, Defa, Bob(Denis) .All’Università ho conosciuto nuove persone con cui trascorrere le giornate. A cominciare da Alessandro concui ho condiviso l’appartamento il primo anno e Pietro ed Elena, i primi che ho conosciuto a Trieste. EnricoNatella il Paonazzo che per disgrazia vedo tutti i giorni, e poi Nicola e Freddie che abitano a qualchechilometro da casa mia ma che ho conosciuto solo all’Università. SimonB dj alla deriva, Matteo B.whiteeight, Andrea Ronchisciotte, Andrea Teso, e Michael Florio che ogni tanto si vede ancora a Trieste,Livio il cantastorie, Giuly open air, il Cutty, Lindi, Emilio, Matteo Gazzin, Ilaria e Matteo Bino la guida alpinadell’alpago, Marco il duca bianco e Martins War organizzatori ufficiali delle partire di calcetto, Checco theBlason, Enrico Zorzi, Gianluca Mazzooon e tutto Viale 56 per i tornei di call of duty e feste varie. Infine icoinquilini degli ultimi anni Claudio anche se solo per poco, Niccolò, Sebastiano, Alberto e Johnny e tutti glialtri che ho dimenticato. 6-164
  • 169. Infine un ringraziamento a Maurizio Fermeglia, il prof che mi ha seguito come relatore per la tesi, FabrizioSImeoni e tutte le persone di Teorema, l’azienda dove sono stato negli ultimi 5 mesi; in particolare icompagni di ufficio Andrea, Luca, Enrico e Simona. 6-165
  • 170. Il futuro appartiene a coloro che credono nella bellezza dei propri sogni. -Eleanor Roosevelt- La vita e i sogni sono fogli di uno stesso libro.Leggerli in ordine è vivere, sfogliarli a caso è sognare. -Arthur Schopenhauer- 6-166