<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1214412942025937&amp;ev=PageView&amp;noscript=1">

Red Blog

Sistema Pre-Billing, PA, sanità, sport e turismo: 5 esempi di applicazione del Middleware di integrazione

Stefano Marfella,

Sistema Pre-Billing, PA, sanità, sport e turismo - 5 esempi di applicazione del Middleware di integrazione

In Italia sono ancora molte le aziende che fanno fatica a tenere il ritmo delle continue evoluzioni in campo IT, e questo perché gli ostacoli da superare nel processo di implementazione di un nuovo sistema informativo vengono spesso sentiti come insormontabili.

Necessità di integrazioni, sia con l'esterno che con le applicazioni interne, cambiamenti nei flussi operativi e allineamento delle informazioni: le aziende non si sentono pronte ad affrontare il cambiamento, il ché può diventare un problema quando cambiare è una necessità - pena l'essere tagliati fuori dal business - o quando addirittura il cambiamento viene imposto dalla legge.

La soluzione vincente per l'integrazione di applicazioni software, dati e servizi è il Middleware, cioè un software di connessione che funge da "collante" tra diverse applicazioni e che diventa il ponte che fa dialogare fra di loro sistemi diversi, permettendo alle organizzazioni di adeguare i processi agli obiettivi e agli stimoli esterni.

 

Scarica subito l'eBook di Red Hat sulla Agile Integration!

 

In questo articolo voglio presentarti cinque casi di successo di organizzazioni - sia pubbliche che private - che sono riuscite a risolvere i loro problemi di gestione dei dati grazie al middleware di integrazione.

  1. Il cambiamento nel sistema di Pre-Billing: il caso SIA
  2. La fatturazione elettronica per la Pubblica Amministrazione: il caso IntermediaMarche
  3. La cooperazione applicativa nel Sistema Sanitario Nazionale: il caso ESTAR
  4. Wellness e integrazione dei dati dai sensori wearable: il progetto ARACNE
  5. Semplificare l'aggregazione dei dati: il caso dei Tour Operator

Ma andiamo con ordine!

1) Il cambiamento nel sistema di Pre-Billing: il caso SIA

La fatturazione elettronica per la Pubblica Amministrazione - il caso IntermediaMarche

SIA è leader europeo nella progettazione, realizzazione e gestione di infrastrutture e servizi tecnologici dedicati alle Istituzioni Finanziarie e Centrali, alle Imprese e alle Pubbliche Amministrazioni, nelle aree dei pagamenti, della monetica, dei servizi di rete e dei mercati dei capitali. L'azienda si trovava nella necessità di implementare un sistema di Pre-Billing basato su soluzioni Open Source che coinvolgesse anche un team interno, con l'obiettivo di far crescere le proprie risorse addette all'IT su tecnologie e metodologie innovative.

In cosa consiste il processo di Pre-Billing

Il processo di Pre-Billing (o pre-fatturazione) riveste un ruolo centrale per le aziende che offrono un'ampia gamma di prodotti e servizi e che devono implementare diverse strategie di politica commerciale. Comprende diverse fasi, tra cui la definizione e l'impostazione delle logiche di business, definite nei contratti stipulati con i clienti, e l'elaborazione di tutti i dati prima della creazione della fattura. La determinazione delle logiche di business, cioè la formalizzazione di tutte le condizioni economiche pattuite con il cliente, rappresenta una delle fasi più complicate.

L'assenza di logiche e processi che consentano di gestire e monitorare i dati acquisiti ed elaborati può influire sul processo di fatturazione vera e propria. Per cercare di gestire questa complessità è necessario adottare un Sistema di Pre-Billing solido, integrato con le aree funzionali dell'azienda e dinamico, che permetta di semplificare il processo di fatturazione fornendo in anticipo elementi statistici e di monitoraggio.

Vediamo quali sono i quattro elementi chiave per un buon sistema di Pre-Billing.

  • Aree Funzionali Integrate. Per poter velocizzare il processo di Pre-Billing, il sistema dovrebbe integrarsi con le aree funzionali dell'azienda e/o esterne ad essa (Anagrafiche, Servizi, Prodotti, Fatturazione, ecc.), dalle quali raccoglie i dati che devono essere elaborati. L'introduzione di un layer d'integrazione, realizzato con un Enterprise Service Bus (ESB), permette l'accentramento in un punto unico di ingresso/uscita dei dati scambiati tra i sistemi di gestione quotidiana del business e i sistemi di fatturazione. Questo tipo di infrastruttura è flessibile, scalabile, robusta e affidabile, e facilita inoltre lo sviluppo di flussi di messaggistica.
  • Interfaccia di Editing delle Regole User-Friendly. Il sistema dovrebbe essere rivolto sia agli utenti dell'area IT, che devono monitorare la correttezza semantica e sintattica dei dati acquisiti, sia agli utenti dell'area Business, che si occupano di definire le regole da applicare ai dati. L'interfaccia deve essere di facile utilizzo e deve permettere la creazione di regole di business, la visualizzazione, l'elaborazione e il monitoraggio dei dati, e dare la possibilità di intervenire su di essi. Trattandosi di logiche complesse è importante che il processo di Pre-Billing si avvalga di un motore delle regole, che permetta la parametrizzazione degli algoritmi e delle regole e che aggiorni rapidamente le regole di business al variare delle condizioni del mercato.
  • Maggiore efficienza operativa. Per poter elaborare correttamente i dati si dovrebbero impostare e configurare tutte le regole derivanti dai contratti stipulati. Trattandosi di logiche molto complesse, il sistema di Pre-Billing dovrebbe permettere all'utente di simulare, effettuare i test di configurazione delle regole e visualizzare i risultati.
  • Analisi Immediata. A termine dell'elaborazione dei dati, l'utente dovrebbe avere immediata visibilità dei risultati prodotti, evidenziando sia i dati che hanno soddisfatto le regole configurate, sia quelli che, a causa di qualche anomalia, non hanno soddisfatto le condizioni definite.

Extra Red ha aiutato SIA a evolvere i propri sistemi grazie a un'architettura integrata di componenti Open Source: Red Hat JBoss Fuse, Red Hat JBoss BPM Suite, Red Hat JBoss EAP e PostgreSQL.

Per visualizzare il progetto nelle sue fasi specifiche puoi consultare il case study di SIA.

2) La fatturazione elettronica per la Pubblica Amministrazione: il caso IntermediaMarche

Il cambiamento nel sistema di Pre-Billing - il caso SIA

Nell'era dell'Industria 4.0 e della Digital Transformation, la dematerializzazione delle fatture e la gestione elettronica dei file rappresentano il primo passo verso uno sviluppo all'insegna dell'innovazione tra le filiere. A partire dal 1 Gennaio 2017, con il decreto legislativo 127/2015 dedicato alla trasmissione telematica delle operazioni IVA, è stata introdotto un Sistema di Interscambio delle fatture per privati analogo a quello già creato dall'Agenzia delle Entrate per la Fattura PA, la fatturazione elettronica verso la pubblica amministrazione, nel 2008. I soggetti passivi IVA possono ora utilizzare la fatturazione elettronica tra privati tramite il portale gratuito messo a disposizione dall'Agenzia delle Entrate. Ciò ha reso necessario l'adeguamento del formato della Fattura PA, che fino a quel momento era opzionale, a differenza di quanto avveniva nella Pubblica Amministrazione, dove è obbligatorio dal 31 Marzo 2015 con il DL 66/2014 e nei Ministeri, Agenzie fiscali, Enti di previdenza e assistenza sociale, dove invece è obbligatoria dal 6 Giugno 2014.

Le novità introdotte dalla Fatturazione Elettronica sono davvero notevoli. Innanzitutto, ha permesso sia di abbandonare per sempre il supporto cartaceo e tutti i relativi costi di stampa, adottando un nuovo formato digitale .XML, sia di garantire autenticità e integrità del contenuto attraverso la firma digitale. Il Sistema di Interscambio ha inoltre messo a disposizione differenti canali di comunicazione (Posta Elettronica Certificata - PEC, Servizio SDICoop-Trasmissione, Servizio SPCoop-Trasmissione ecc.) e permette di ricevere notifiche, sia nel ciclo di fatturazione attiva che passiva, relative alla consegna, all'esito della consegna e alla decorrenza dei termini di accettazione.

Gli attori coinvolti nel sistema della Fatturazione Elettronica sono il fornitore o il suo intermediario, il Sistema di Interscambio (SdI) nazionale e il ricevente o il suo intermediario. L'intermediario è colui che viene autorizzato a trasmettere i file ai destinatari per conto di terzi, e/o che viene autorizzato a ricevere i file per conto del ricevente. Il suo ruolo consiste nel fornire supporto per la compilazione, e/o per la trasmissione e/o per la conservazione sostitutiva della fattura elettronica.

Le attività di supporto fornite variano da contesto a contesto: non esiste una soluzione ideale, ma è certo che l'affidarsi a un intermediario permetta di demandare sia le tematiche della conservazione digitale e fatturazione elettronica, che il continuo aggiornamento degli standard e delle norme.

Per l'ente Regione Marche, Extra ha realizzato il progetto IntermediaMarche. È stato introdotto un Enterprise Service Bus, JBoss Fuse ESB, con il ruolo di intermediario nella comunicazione con il SdI, i sistemi di protocollo degli enti aderenti ed i sistemi gestionali degli enti aderenti, sia per il ciclo di Fatturazione Passiva che Attiva, ponendosi come punto unico di ingresso/uscita dei messaggi scambiati tra il SdI e gli Enti aderenti.

Oltre ai vantaggi legati alla dematerializzazione e alla digitalizzazione della fattura, quali l'abbattimento dei tempi e dei costi di registrazione delle fatture, di gestione della relazione con il cliente, di gestione della conservazione e di riduzione dei margini di errore, la Fatturazione Elettronica permette anche di migliorare le procedure e il proprio business aziendale, attraverso l'adozione di opportune soluzioni software per la produzione della fattura, per l'analisi dei dati e molto altro ancora:

  • esclusione dalla trasmissione delle transazioni attraverso lo spesometro;
  • esclusione dalla trasmissione delle comunicazioni operazioni blacklist;
  • esclusione dalla trasmissione dei modelli Intrastat;
  • esclusione dalla trasmissione dei contratti stipulati dalle società di leasing;
  • diritto a ricevere rimborsi entro i 3 mesi successivi alla presentazione della dichiarazione;
  • verifiche e controlli e accertamenti fiscali ridotti ad 1 anno;
  • esonero dall'obbligo di apposizione del visto di conformità;
  • esonero dall'obbligo di registrare le fatture emesse e gli acquisti nell'apposito registro.

Anche in questo caso, puoi avere maggiori dettagli del progetto nel case study di IntermediaMarche.

3) La cooperazione applicativa nel Sistema Sanitario Nazionale: il caso ESTAR

La cooperazione applicativa nel Sistema Sanitario Nazionale - il caso ESTAR

Uno degli scenari più complessi dal punto di vista dei sistemi informativi è quello offerto dal Sistema Sanitario Nazionale. Si pensi, infatti, alla molteplicità di ambiti funzionali, dalla gestione operativa delle strutture sanitarie all'erogazione dei servizi, fino alla gestione amministrativa dei presidi. Se a tutto questo aggiungiamo la frammentazione organizzativa degli uffici, in alcuni casi accompagnata da un certa "indipendenza" nelle scelte tecnologiche fatta da ciascuna azienda sanitaria, il quadro diventa ancora più complicato.

La spinta verso la completa digitalizzazione del mondo sanitario e l'offerta di servizi al cittadino sempre più elaborati e fruibili via internet, impone quindi la necessità di far dialogare e interoperare gli applicativi presenti nella aziende sanitarie. In questo modo, è possibile ottenere maggiore qualità e efficienza nei servizi al cittadino e maggiori risparmi per le aziende sanitarie che trovano così modo di sfruttare pienamente il potenziale della propria infrastruttura informatica.

Per interoperabilità si intende la capacità di scambiare informazioni, interagire e attivare processi tra due o più sistemi informativi. Ma l'interoperabilità in sanità non è il punto di arrivo. Il passo che le aziende sanitarie da anni stanno cercando di fare è in realtà più grande: l'obiettivo è quello di perseguire sempre di più la cooperazione applicativa, ovvero far sì che i sistemi informativi possano interscambiare automaticamente e trarre un vantaggio attivo dallo scambio delle informazioni e dalla logica applicativa di ciascuno.

Per poter realizzare la cooperazione applicativa sanitaria diventa strategico individuare e utilizzare strumenti che possano supportare scenari complessi, come gli Enterprise Service Bus (ESB), che permettono di razionalizzare e coordinare il parco applicativo fungendo da punto accentrante delle integrazioni tra i vari sistemi informativi. 

Per la regione Toscana l'ente che gestisce i servizi è ESTAR (Ente di Supporto Tecnico Amministrativo Regionale). Estar ha l'incarico di ottimizzare la spesa regionale destinata ai beni sanitari pur mantenendo elevati standard di qualità dei servizi; da Gennaio 2015 unifica i tre enti regionali che gestivano diverse aree della Toscana.

Estar è organizzato in dipartimenti per seguire tutti gli aspetti della spesa sanitaria: il Dipartimento Tecnologie Informatiche e Sanitarie si occupa delle procedure, delle reti e dei sistemi informatici su tutta la Toscana.

Considerato che i costi della realizzazione di un nuovo software come la complessità della sostituzione di quello in uso con il nuovo possono facilmente diventare non banali, il grande obiettivo all'interno di una azienda sanitaria è realizzare un ecosistema informatico organizzato e coeso senza, o con minime, modifiche agli applicativi in uso, mantenendo quanto più possibile il disaccoppiamento tra i servizi che vengono integrati tra loro.

All'interno di questo scenario, le più comuni necessità sono:

  1. trasporto delle informazioni: mettere in comunicazione i servizi di una struttura sanitaria con i servizi di interoperabilità in sanità della regione Toscana e con altre strutture sanitarie;
  2. trasformazione dei dati: mettere in comunicazione i servizi che utilizzano protocolli e formati dei dati anche molto diversi;
  3. automazione processi: automatizzare i processi di gestione delle pratiche limitando il data entry manuale;
  4. analisi dei dati: eseguire elaborazioni statistiche o business intelligence sui dati trasferiti tramite i servizi informatici, al fine di calcolare le performance e i fabbisogni di un servizio ospedaliero;
  5. condivisione delle informazioni su aree geografiche (Routing Intelligente): distribuire e uniformare le informazioni condivise tra le aziende sanitarie sul territorio come all'interno di uno stesso ospedale;
  6. monitoraggio dell'infrastruttura: tenere sotto controllo il funzionamento dei servizi informatici e degli applicativi nell'infrastruttura informatica.

A. Trasferimento delle informazioni

Il problema

Trasferire informazioni in modo affidabile e robusto tra servizi e applicazioni senza richiedere nuovi sviluppi su applicazioni e servizi messi in comunicazione.

La soluzione

La soluzione scelta da Extra per questi scenari si avvale di Red Hat JBoss Fuse che grazie ad un integration framework, come Apache Camel, permette di realizzare agevolmente un mediation layer in grado di nascondere a ciascuno dei servizi integrati il formato dei dati degli altri.

Definire un'architettura robusta per mettere in comunicazione servizi eterogenei richiede come base che l'integrazione sia loosely coupled, per garantire che le modifiche su un servizio siano trasparenti per gli altri. Il mediation layer è uno strato applicativo che facilita la comunicazione tra software, anche molto diversi tra loro, in modo che, quando uno viene modificato o sostituito, l'altro non abbia evidenza dei cambiamenti avvenuti.

Le soluzioni proposte da Extra si avvalgono anche della presenza su JBoss Fuse, del broker JMS ActiveMQ e del frame work Apache CXF integrato con Apache Camel per sviluppare agevolmente web service sia SOAP che REST. Extra progetta l'architettura delle integrazioni avvalendosi dei noti Enterprise Integration Patterns che con Camel è immediato tradurre nello sviluppo di una nuova applicazione.

B. Trasformazione dei dati

Il problema

Spesso le applicazioni sanitarie utilizzano formati molto diversi per trasferire i dati, per esempio molte applicazioni usano il formato HL7 binario per trasferire i dati via TCP mentre altre utilizzano web service con messaggi XML. Quando è necessario integrare queste due classi di applicazioni, è necessario disporre di un sistema dotato della capacità di trasformare i dati da un formato all'altro.

Altre volte applicazioni che gestiscono lo stesso tipo dei dati ne danno una rappresentazione profondamente diversa, un esempio classico sono le applicazioni che trattano i dati anagrafici, anche se entrambe le applicazioni utilizzano XML per il trasferimento dati.

La soluzione

Le scelta di Extra di avvalersi di Red Hat JBoss Fuse si avvantaggia delle capacità native di Apache Camel che agevolano la realizzazione di applicazioni orientate alla trasformazione dei dati, grazie ai connettori pronti all'uso di cui è dotato Camel e alla facilità con cui si possono trasformare i formati dei dati tramite Camel.

Avere a disposizione un mediation layer dotato di capacità di trasformazione dei dati (data transformation) gioca un ruolo fondamentale in molti scenari di integrazione in ambito sanitario.

C. Automazione processi

Il problema

La richiesta di automatizzare alcuni processi può coprire vari scenari: dalla semplice automazione di un aggiornamento dati quotidiano, all'automazione del trasferimento dati tra diversi uffici per ridurre il lavoro manuale di data entry.

La soluzione

Le soluzione che Extra ha realizzato per Estar si avvale di processi batch realizzati su Red Hat JBoss Fuse, tipicamente allo scatto del timer si estrae il contenuto dalla sorgente (tabelle, file, ecc.) e si realizza un servizio di integrazione tramite Camel e CXF per inviare i dati. Il routing intelligente (basato su regole) di Camel permette di definire un workflow delle elaborazioni delle informazioni, che nel nostro caso è stato utile per gestire il ciclo di vita delle ricette dematerializzate nel processo batch. Si, lo so: un sacco di termini tecnici! Per capire meglio a cosa mi riferisco puoi accedere gratuitamente al nostro System Integration Knowledge Pack.

D. Analisi dei dati (Data Harvesting)

Il problema

La necessità di un ospedale è misurare la quantità di richieste di assistenza che arrivano sul pronto soccorso e su altri reparti e poter disporre di dati statistici che permettano di valutare le performance di un servizio ospedaliero e i fabbisogni dei reparti.

La soluzione

Creare un mediation layer che instrada i dati in transito su un canale parallelo per l'analisi statistica; tramite Camel i messaggi in transito vengono invitati in copia (enterprise integration pattern WireTap) ad un modulo che estrae gli elementi significativi, in modo anonimo, per alimentare un repository di informazioni utili al controllo di gestione.

La possibilità di agganciare al mediation layer un modulo plug-in per operazioni specifiche permette non solo di aggiungere plug-in per la valutazione statistica ma anche altri software che eseguono task asincroni: è il caso dell'integrazione denominata "Codice Argento" che riceve i dati del pronto soccorso tramite il mediation layer e calcola il punteggio Codice Argento che restituisce al pronto soccorso.

E. Routing intelligente

Il problema

L'informazione deve essere trasferita a un numero di destinatari variabile che può dipendere sia dal tipo di informazione veicolata sia da un insieme di destinatari variabile nel tempo.

Spesso l'informazione deve viaggiare su reti geografiche dove il destinatario finale viene scelto in base al contenuto del messaggio, non si tratta solo di scenari di broadcasting all'interno di una stessa struttura sanitaria.

La soluzione

La possibilità di utilizzare un routing engine basato su regole come Camel offre la flessibilità necessaria per realizzare in modo semplice e affidabile l'instradamento dinamico dei messaggi in base al contenuto, allo stato o altri parametri specifici. Combinato con il broker JMS per la messaggistica asincrona offre la possibilità di realizzare soluzioni complesse e scalabili.

Extra ha partecipato come uno dei fornitori accreditati alla realizzazione di una rete di proxy di messaggistica asincrona su tutto il territorio regionale. La soluzione utilizza JBoss Fuse con ActiveMQ, Camel e CXF per realizzare proxy veloci con politiche di re-delivery dei messaggi, code JMS per i messaggi in attesa di consegna, web service integrati nelle rotte Camel tramite CXF e i componenti CXF di Camel.

In altri scenari affrontati da Extra si richiede il broadcasting delle informazioni su un insieme di destinatari variabile nel tempo: qui Extra ha realizzato delle integrazioni specifiche utilizzando l'architettura publish/subscriber dei topic jms disponibili con ActiveMQ, integrato in JBoss Fuse.

F. Monitoraggio dell'infrastruttura

Sin dai primi progetti installati presso l'ospedale di Careggi si è notata la necessità di tenere sotto controllo le integrazioni con un sistema di monitoraggio che permettesse di osservare i componenti specifici (code JMS, componenti Camel, web service).

Affiancando JBoss Operations Network (che monitora i componenti su JBoss Fuse) ad alcuni componenti custom sviluppati da Extra per il keep alive su JBoss Operations Network, si è ottenuta una soluzione robusta e capace di segnalare i problemi su qualsiasi applicativo nell'infrastruttura.

Il monitoraggio a grana fine di una applicazione di integrazione disponibile solo con JBoss Operations Network permette di rilevare rallentamenti nel flusso dei messaggi, errori nell'invio dei dati su un web service, errori nella scrittura o lettura da un database, ecc.

Il server JBoss Operations Network notifica per mail gli alert quando rileva un problema. Gli alert permettono di rilevare la presenza di problemi non solo sulle macchine su cui è installato JBoss Fuse ma anche sui servizi terzi di altri fornitori: un tipico esempio è l'allarme per gli errori nella consegna dei messaggi su un applicativo, in base a queste rilevazioni è possibile segnalare tempestivamente un problema prima ancora che gli altri fornitori ne abbiano consapevolezza.

In supporto al servizio JBoss Operations Network, i componenti sviluppati da Extra permettono di rilevare in tempo reale eventuali problemi nella comunicazione tra agent e server e tra agent e container monitorati.

Il sistema di monitoraggio copre al momento una rete geografica perché monitora sei installazioni di JBoss Fuse, ciascuna su un differente centro di calcolo, sparse sul territorio conosciuto come ‘area vasta centro'.

Benefici della cooperazione applicativa in ESTAR

L'architettura definita per Estar permette di tagliare i costi mantenendo un'alta qualità del servizio, supportando così il cliente nella realizzazione del suo core business. L'architettura è modulare, facilmente estendibile e scalabile.

L'architettura del sistema di monitoraggio permette l'identificazione dei problemi in modo molto più veloce e di conseguenza permette di ridurre i disagi che un eventuale malfunzionamento può creare in un sistema mission critical come quello dei servizi informatici per la sanità.

I software utilizzati sono tutti open source e in più offrono le garanzie dei software enterprise forniti da Red Hat e beneficiano del supporto Red Hat incluso nella subscription.

Extra e il mondo della sanità

L'esperienza di Extra nel mondo delle integrazioni dei servizi per la sanità è iniziata sei anni fa, prima con la collaborazione con l'ospedale di Careggi, poi con l'ente Estav Centro confluito nel gennaio 2015 in Estar, ente con cui prosegue la collaborazione.

Nel corso degli anni i progetti realizzati da Extra in ambito sanitario sono cresciuti fino a raggiungere il totale di 40 e più integrazioni, che spaziano da proxy per integrare servizi locali con i servizi regionali, alle applicazioni di integrazione mission critical dedicate la gestione dei ticket e dei pagamenti.

La soluzione di Extra per le richieste provenienti dal mondo della sanità si avvale del middleware di Red Hat, in particolare JBoss Fuse, che offre gli strumenti necessari per realizzare le applicazioni di integrazione con la stabilità garantita dal software enterprise Red Hat e il minimo consumo di risorse come spesso è richiesto dal cliente.

4) Wellness e integrazione dei dati dai sensori wearable: il progetto ARACNE

Wellness e integrazione dei dati dai sensori wearable - il progetto ARACNE

Si può vivere fino a 150 anni? Gli studiosi hanno condotto svariate ricerche per cercare di capire come sia possibile prolungare la vita umana, arrivando a conclusioni differenti e definendolo un traguardo raggiungibile. Non ho naturalmente la presunzione di fornire una nuova teoria a riguardo, ma voglio solamente evidenziare quanto negli ultimi anni le applicazioni orientate al benessere si siano diffuse.

L'OMS (Organizzazione Mondiale della Sanità) nel 1948 definiva il benessere come "Uno stato di completo benessere fisico, psichico, sociale e non la semplice assenza dello stato di malattia o d'infermità". Il benessere non è costituito da una sola componente quindi, ma dall'equilibrio di tre fattori distinti e di eguale importanza. L'attività fisica incide positivamente su tutti e tre i fattori.

La crescita dell'attenzione rivolta al tema della salute e all'attività sportiva non è certo sfuggita agli sviluppatori di applicazioni, che negli ultimi anni hanno investito notevolmente in questo segmento di mercato. Ciò ha portato a un aumento vertiginoso delle applicazioni per dispositivi mobile nel segmento del wellness, con funzionalità sempre più avanzate e diversificate, che permettono di monitorare oltre ai parametri del proprio allenamento, tanti altri dati interessanti.

I binomi "app e salute" o "app e wellness" o "app e green" sembrano essere molto apprezzati da chi vuole curare il proprio corpo, il proprio benessere e ama monitorare e tracciare la propria attività sportiva e l'ambiente che lo circonda. Maggiori sono i parametri che i dispositivi indossabili sono in grado di rilevare e di conseguenza di registrare, classificare e analizzare, maggiori sono le soddisfazioni che hanno gli utenti nell'utilizzare queste applicazioni, fino a orientare i loro comportamenti, le loro decisioni e i loro stili di vita.

Proprio in questo ambito Extra in collaborazione con WinMedical Srl, 3Logic MK Srl, Cubit e Cnit, sta realizzando il progetto ARACNE, un progetto di ricerca co-finanziato da Regione Toscana nell'ambito del Bando RSI POR CreO 2014-2020. ARACNE permette di rilevare, monitorare ed effettuare la diagnosi di parametri fisiologici (cardiofrequenzimetro, SpO2, ECG 5 derivazioni, pressione sanguigna, frequenza respiratoria, temperatura corporea), ambientali (concentrazione NO2, livello umidità relativa) e meteorologici (profilo densità volumetrica della pioggia, stima dell'intensità di pioggia) durante lo svolgimento dell'attività sportiva, in particolare corsa e ciclismo.

L'architettura presente dietro queste applicazioni è molto complessa e, nella maggior parte dei casi, è integrata. Come abbiamo detto poco prima, di solito con le app di questo tipo è previsto l'utilizzo di sensori wearable che devono essere integrati in un'unica piattaforma tecnologica. L'integrazione può essere realizzata punto-punto attraverso connessioni dirette tra i dispositivi da integrare, oppure tramite l'introduzione di uno strato di integrazione, un Enterprise Service Bus.

Indipendentemente dalla soluzione tecnologica adottata, è importante che la piattaforma d'integrazione di questo tipo di applicazioni sia in grado di gestire volumi di dati eterogenei con una frequenza temporale continua e di rispondere ai requisiti di affidabilità, robustezza, estensibilità, scalabilità e modularità.

Puoi avere maggiori dettagli sul progetto accedendo al case study di ARACNE.

5) Semplificare l'aggregazione dei dati: il caso dei Tour Operator

 

Semplificare l'aggregazione dei dati - il caso dei Tour Operator

Con questo ultimo esempio voglio dimostrarti quanto siano ampie le possibilità e gli ambiti di applicazione del Middleware di integrazione.

Un portale di viaggi per avere successo deve avere un buon design, essere multilingua ed essere efficace ed efficiente, mostrando le reali disponibilità e prezzi sempre aggiornati. L'efficacia e l'efficienza sono legate soprattutto al back-end del portale web e all'architettura sottostante, che deve essere in grado di supportare un elevato carico di chiamate, effettuare manipolazioni sui dati, garantire tempi di risposta sempre più brevi, interfacciarsi con numerosi fornitori di voli, hotel, noleggio auto, con i software dell'azienda (ERP, CRM, ecc.).

L'architettura sottostante deve quindi essere in grado di interfacciarsi con fonti di dati differenti e formati diversi, gestire un elevato carico di chiamate, applicare logiche di normalizzazione e aggregare dati per poter fornire all'utente finale i risultati più vantaggiosi e ottimizzare i tempi di risposta.

Com'è possibile progettare un'architettura che permetta sia di far parlare il portale web con più sistemi eterogenei, sia di applicare logiche e regole sui dati stessi?

Non esiste un'unica risposta possibile. Tuttavia, una delle soluzioni migliori per risolvere i problemi che si incontrano quando si devono integrare fonti di dati differenti tra loro, con protocolli diversi e si devono applicare logiche sul dato garantendo comunque elevata affidabilità, robustezza e flessibilità, è sicuramente l'introduzione di un mediatore, ossia di uno strato middleware composto da un Enterprise Service Bus e un motore di gestione delle regole, che permettono di realizzare un sistema ad alta scalabilità, efficienza, modularità ed elevata flessibilità, oltre che riutilizzabilità dei servizi sviluppati.

Introdurre un Enterprise Service Bus nella propria architettura significa inserire una componente robusta e affidabile che permette di avere supporto per un gran numero di formati e protocolli (http, json, rest, soap, ftp, bpel, ecc.), di gestire le componenti software in modo modulare, di trasformare, arricchire ed effettuare il routing dei messaggi in modo tale che ciascun sistema esterno possa far riferimento ad un'unica interfaccia.

Invece, l'introduzione di un Motore delle Regole consente di definire l'insieme delle regole che devono essere applicate sui dati e il relativo ordine di esecuzione, garantendo anche la possibilità di eseguire modifiche frequenti facilmente. Per esempio, si può utilizzare per riportare facilmente variazioni sui prezzi, oppure simulare nuove politiche commerciali legate ad abbinamenti di prodotti.

Tornando però ai Portali Web, il vero vantaggio di introdurre un Enterprise Service Bus e un Motore delle Regole sta nel fornire un livello d'integrazione in grado di astrarre e semplificare tutta la complessità legata all'integrazione con i fornitori dei servizi turistici e con i software informativi dell'azienda, e nel poter implementare facilmente le logiche di business sui dati. Con questa architettura diventa possibile anche implementare logiche di normalizzazione sui dati in ingresso: se, ad esempio, per uno stesso servizio turistico vengono contattati differenti fornitori  che possono restituire gli stessi dati ma in formato diverso, è necessario normalizzare i dati secondo le opportune regole; inoltre, è opportuno ottimizzare i tempi di risposta delle ricerche tramite un sistema di gestione delle code dei messaggi.

Quindi, se nell'architettura della tua azienda sono presenti molteplici fonti e intendi applicare ai dati logiche di business, l'adozione di un ESB e di un Motore delle Regole possono rappresentare la soluzione per realizzare / migliorare il tuo sistema.

L'integrazione è un tema molto delicato quando si tratta di soluzioni software: è necessario avere le giuste conoscenze e competenze per poter mettere in atto una integrazione degna di tale nome! Se sei interessato a migliorare il tuo ecosistema IT, ti consiglio di dare un'occhiata a questo eBook gratuito di Red Hat sulla Agile Integration!

New call-to-action

Share this post

  

Commenti

Prova Red Cloud Gratis per 30 Giorni

Iscriviti alla newsletter

Condividi questo blog

   

Post correlati