Sviluppo della piattaforma dei servizi cloud di base per ...oscat.rete.toscana.it/docman/view.php/604/3150/RT+-+SAAS_PLATT... · Regione Toscana Sviluppo della piattaforma dei servizi

Regione Toscana

Sviluppo della piattaforma dei servizi cloud dibase per il data center TIX

DOCUMENTO CON LE SPECIFICHE PER L’ATTIVAZIONE

DELLE API

07 Ottobre 2015 versione 1.1

Consorzio HyperTIX Soci Fondatori:

Via Calabria, 1 - Località Gello CDC S.p.A.56025 – Pontedera (Pisa) TD Group S.p.A.

AlmavivA S.p.A.

Indice

1 INTRODUZIONE...................................................................................4

2 CONTESTO.........................................................................................5

3 ARCHITETTURA DELLA PIATTAFORMA.....................................................6

3.1 Breve introduzione alla piattaforma..................................................6

3.2 Integrazione tra piattaforma e mod_unique_id...................................8

3.3 Layout dell'architettura...................................................................9

4 AMBIENTI APPLICATIVI.......................................................................10

4.1 Specifiche di integrazione al servizio di replicazione della sessione.......10

4.1.1 Inclusione delle librerie Hazelcast.............................................104.1.2 Configurazione web.xml..........................................................10

4.2 Specifiche di integrazione al servizio di caching................................12

4.2.1 Inclusione delle librerie Hazelcast.............................................124.2.2 Configurazione librerie ORM.....................................................13

4.2.2.1 Framework JPA................................................................13

4.2.2.2 Hibernate........................................................................14

4.2.3 Utilizzo delle librerie Spring Cache............................................14

5 GESTIONE AMBIENTI APPLICATIVI E RISORSE.......................................16

5.1 Struttura degli eventi....................................................................16

5.2 Specifiche di integrazione tramite libreria SAASLogger.......................19

5.3 Specifiche di integrazione di appender log4j.....................................20

5.4 Specifiche di invio eventi tramite servizio REST.................................21

5.5 Specifiche di interrogazione eventi..................................................21

5.6 Specifiche di integrazione per invio segnalazione..............................22

5.7 Specifiche di integrazione per comunicazione chiusura segnalazione....22

6 DEFINIZIONE DELLE REGOLE DI COMPLEX EVENT PROCESSING: CASOD'USO FERT.........................................................................................24

6.1 Introduzione................................................................................24

6.2 Descrizione delle regole................................................................24

6.2.1 Nuova Istanza di Processo FERT...............................................246.2.2 Attività FERT conclusa senza timeout........................................256.2.3 Attività FERT conclusa con timeout...........................................266.2.4 Errore FERT...........................................................................27



AlmavivA S.p.A.

Sviluppo della piattaforma dei servizi cloud di base per il data center TIX – Documento dei requisitiGennaio 2014 3/27



AlmavivA S.p.A.

Sviluppo della piattaforma dei servizi cloud di base per il data center TIX – Documento con le specifiche per l’attivazione delle API 7 ottobre 2015 4/27

1 INTRODUZIONE

Obiettivo del presente documento è quello di illustrare le specifiche perl’attivazione delle API previste per il progetto “Sviluppo della piattaforma deiservizi cloud di base per il data center TIX” (successivamente, per brevità,piattaforma cloud), con riferimento ai servizi ritenuti prioritari al fine diconsentire la fruizione, in logica SaaS, del Fascicolo Sanitario Elettronico.

Il documento fornirà anche indicazioni utili all’implementazione delleapplicazioni per renderle idonee ad una erogazione in logica “as a service”.

Altri deliverable dell’attività di progettazione sono:

• Documento di progettazione dei servizi

• Documento di progettazione delle API

che saranno oggetto di distinta pubblicazione.



AlmavivA S.p.A.


2 CONTESTO

I servizi oggetto di sviluppo sono i seguenti:

Servizi (o ambienti) applicativi per l'erogazione dei servizi;

Logging e auditing applicativo di base;

Monitoring;

Servizi di assistenza utente (service desk ed help desk).

Tali servizi sono stati individuati nel corso della fase pre-contrattuale quandosono stati anche definiti (1) i principali requisiti che dovranno essere soddisfatti.Tali requisiti sono stati successivamente approfonditi (2) in fase di analisi.

E’ possibile suddividere concettualmente tali servizi distinguendo

quello (Ambienti applicativi) che riguarda la predisposizione dell’ambienteutile all’erogazione di applicazioni in logica “as a Service”,

dagli altri che riguardano la gestione di tale ambiente e di tutte le risorse(di piattaforma ed infrastrutturali) rese disponibili per l’erogazione diapplicazioni in logica “as a Service”.

1 Vedi “Sviluppo della piattaforma dei servizi cloud di base per il data center TIX” - Piano di la-voro – 27/11/2013

2 Vedi “Sviluppo della piattaforma dei servizi cloud di base per il data center TIX”-Documento con la definizione dei requisiti e delle caratteristiche di dettaglio delle soluzionida implementare- 18/2/2014



AlmavivA S.p.A.


3 ARCHITETTURA DELLA PIATTAFORMA

In questo capitolo si riassume sia l'architettura della piattaforma (ad alto livello, ma in modo che il lettore non debba far riferimento ad altri documenti),sia le modifiche alla piattaforma necessarie all'integrazione con mod_unique_id. Qui tralasciamo tutti componenti che si occupano di security e load balancing, non essenziali in questo contesto.

3.1 Breve introduzione alla piattaforma

La piattaforma SaaS-plat è un sistema di monitoraggio eventi generico adattabile a qualsiasi tipo di applicazione.E' costituita da due macro-componenti:

➔ Un sistema di raccolta dei log denominato elk, piattaforma open-source della società elastic

➔ Un sistema di alerting intelligente di situazioni anomale sviluppato da AlmavivA sopra elk

elk (acronimo di elasticsearch, logstash, kibana) è costituita dai seguenti componenti3:

➔ elasticsearch: un database NoSQL con funzionalità avanzate di ricerca basate su Apache Lucene

➔ logstash: un aggregatore di log provenienti da sistemi operativi, database, applicazioni e servizi. I log recuperati da logstah vengono generalmente conservati su elasticsearch

➔ kibana: una web application per l'analisi e la visualizzazione di dati di elasticsearch

Il sistema di alerting intelligente si basa invece, fondamentalmente, su:➔ Drools, motore a regole di inferenza (BRMS) con estensione Complex

Event Processing (CEP)➔ Karaf: container OSGI di Apache che permette in particolare l'utilizzo di

Apache Camel e ActiveMQ➔ MoTIX, una web application per la visualizzazione dei dati essenziali di

monitoring, in particolare i processi che, pur non essendo in errore presentano anomalie

➔ cee, uno standard di logging per l'interoperabilità dei eventi4

La piattaforma opera come di seguito:1. logstash raccoglie logs di qualsiasi natura provenienti da qualsiasi

applicazione, sistema operativo, database, web server etc che produca

3 Cfr. http://elastic.co4 Cfr. https://cee.mitre.org/



AlmavivA S.p.A.


un log in qualsiasi formato e pubblica, attraverso vari protocolli, i log raccolti in elasticsearch in formato json

2. elasticsearch conserva i log e permette ricerche di varia natura. Le ricerche possono essere effettuati da API REST, Java, groovy, python etc

3. kibana permette l'interrogazione user friendly dei logs attraverso dashboard personalizzabili

Ove ci sia la necessità di un alerting intelligente dei dati la piattaforma opera nelle seguenti modalità:

1. Le applicazioni utente producono log in formato cee. Detti log, in formatojson5, comunicano le seguenti informazioni riguardanti eventi:

• hostname dell'applicazione• ip address dell'applicazione• data dell'evento• processo loggato• istanza del processo loggato• progressivo dell'evento• nome dell'applicazione• attività eseguita• esito dell'evento• tipologia dell'evento• messaggio dell'evento

2. logstash raccoglie i log cee e li invia a code ActiveMQ di Karaf

3. Camel esegue una prima analisi degli eventi, invia quelli significativi a Drools e comunque tutti gli eventi a elasticsearch

4. Drools, attraverso regole CEP specifiche per ogni sistema, discrimina gli eventi che significano una corretta conclusione di un processo da quelli che segnalano un'anomalia (anche, non bloccante, es. un delay temporale eccessivo).

5. MoTIX visualizza processi, eventi e attività sul browser

5 La validità sintattica dei json prodotti è stata verificata con http://jsonlint.com, il validatoreufficiale del portale http://json.org/



AlmavivA S.p.A.


3.2 Integrazione tra piattaforma e mod_unique_id

L'integrazione tra piattaforma e mod_unique_id ha i seguenti requisiti architetturali:

➔ logstash non deve essere installato sulle macchine di frontend, solitamente prive di Java (logstash è scritto in Jruby)

➔ Lo unique_id generato da mod_unique_id deve essere propagato alle applicazioni di backend che continuano ad utilizzarlo nello scambio informazioni

l'integrazione si basa sui seguenti componenti:

➔ rsyslog: un'utility per il forwarding di log su una rete. Permette l'invio dilog a logstash senza che questo sia presente sulla macchina di frontend

➔ mod_unique_id: modulo di apache che genera l'unique_id➔ ajp: componente che permette il colloquio tra il web server apache ed il

container tomcat➔ SAASLogger.jar: una libreria Java che invia, via REST, eventi in formato

cee a Karaf

L'integrazione, come processo, consiste nei seguenti step:1. il frontend apache riceve una request, la arricchisce col

mod_unique_id, logga la richiesta su un file di log (/var/log/httpd/servizi.toscana.it_ssl_json_log) in formato json. Per produrre detto log la configurazione di Apache è stata opportunamente modificata

2. apache inoltra la richiesta, arricchita dal parametro mod_unique_id.

3. rsyslog, in ascolto su detto log file, invia le righe del file ad un ip/porta sulla quale logstash è in ascolto.

4. logstash recupera le righe ricevute e le invia ad elasticsearch nell'indice syslog

5. le applicazioni Java, dispiegate su Tomcat, inviano gli eventi di competenza a Karaf in formato cee

6. successivamente il processo di monitoraggio continua come spiegato nel paragrafo precedente.

Nella prossima pagina mostriamo uno schema delle connessioni tra i diversi componenti.



AlmavivA S.p.A.


3.3 Layout dell'architettura



AlmavivA S.p.A.


4 AMBIENTI APPLICATIVI

4.1 Specifiche di integrazione al servizio di replicazione della sessione

Per integrare il servizio ad una web application JEE è sufficiente aggiungere lelibrerie di Hazelcast al classpath dell’applicazione e configurareopportunamente il file web.xml. Il servizio risulterà integrato in manieratrasparente: quando l’applicazione andrà a richiedere o a modificare lasessione il servizio estenderà gli effetti di queste operazioni a tutti i nodi cheutilizzano il servizio.

4.1.1Inclusione delle librerie Hazelcast

Inserire nelle librerie della web application e quindi nella cartella WEB-INF/lib iseguenti jar:

hazelcast-3.1.x.jar

hazelcast-client-3.1.x.jar

hazelcast-wm-3.1.x.jar

4.1.2Configurazione web.xml

Il seguente frammento xml deve essere inserito nel file web.xml avendo curache il servlet filter introdotto sia il primo dell’eventuale catena.

<filter>

<filter-name>hazelcast-filter</filter-name><filter-class>com.hazelcast.web.WebFilter</filter-class>

<init-param><param-name>map-name</param-name><param-value>tix-sessions-scope1</param-value>

</init-param>

<init-param><param-name>sticky-session</param-name><param-value>true</param-value>

</init-param>

<init-param><param-name>cookie-name</param-name><param-value>hazelcast.sessionId</param-value>



AlmavivA S.p.A.


</init-param>

<init-param><param-name>cookie-secure</param-name><param-value>false</param-value>

</init-param>

<init-param><param-name>cookie-http-only</param-name><param-value>false</param-value>

</init-param>

<init-param><param-name>debug</param-name><param-value>false</param-value>

</init-param>

<init-param><param-name>config-location</param-name><param-value>/WEB-INF/hazelcast.xml</param-value>

</init-param>

<init-param><param-name>instance-name</param-name><param-value>default</param-value>

</init-param>

<init-param><param-name>use-client</param-name><param-value>true</param-value>

</init-param>

<init-param><param-name>client-config-location</param-name><param-value>hazelcast-session-rep-client.xml</param-value>

</init-param>

<init-param><param-name>shutdown-on-destroy</param-name><param-value>false</param-value>

</init-param>

</filter>

<filter-mapping><filter-name>hazelcast-filter</filter-name><url-pattern>/*</url-pattern><dispatcher>FORWARD</dispatcher><dispatcher>INCLUDE</dispatcher><dispatcher>REQUEST</dispatcher>

</filter-mapping>

<listener><listener-class>com.hazelcast.web.SessionListener</listener-class>

</listener> 

Evidenziati in grassetto i campi che possono essere modificati daglisviluppatori:



AlmavivA S.p.A.


map-name – qualora si volessero creare più scope di replicazione dellasessione inserire qui una etichetta che contrassegni univocamente quelloscelto.

debug – impostare true se si desidera avere un logging dalle librerie direplicazione. Impostare a false in ambienti di produzione.

N.B.Si ricorda che per questo servizio, come già avviene nei cluster di applicationserver JEE, rimane l’obbligo che tutti gli oggetti inseriti nella sessione debbanoessere serializzabili (devono implementare l’interfaccia java.io.Serializable).

4.2 Specifiche di integrazione al servizio di caching

Per integrare il servizio ad una applicazione JEE è sufficiente aggiungere lelibrerie di Hazelcast al classpath e modificare opportunamente i file diconfigurazione dei framework adottati. Questo secondo step differisce però aseconda della strategia di integrazione scelta:

1. Integrazione del servizio di caching attraverso librerie ORM. 2. Integrazione del servizio di caching attraverso Spring Cache.

4.2.1Inclusione delle librerie Hazelcast

Inserire nelle librerie della web application e quindi nella cartella WEB-INF/lib iseguenti jar:

hazelcast-3.1.x.jar

hazelcast-client-3.1.x.jar

hazelcast-wm-3.1.x.jar

hazelcast-hibernate4-3.1.x.jar - integrazione tramite framework ORMbasato su Hibernate 3.3.x e versioni successive.oppure

hazelcast-hibernate3-3.1.x.jar - integrazione tramite framework ORMbasato sulle versioni precedenti a Hibernate 3.3 oppure

hazelcast-spring-3.1.x.jar - integrazione tramite Spring Cache

Nel caso, più generico, in cui l’applicazione client sia Java Enterprise, i jar



AlmavivA S.p.A.


potranno essere inclusi direttamente nell’EAR e collegati ai moduli checompongono l’applicazione secondo gli standard definiti da questo formato didistribuzione: copiare i jar nella “root” dell’archivio EAR e inserirli nel classpathdei moduli (che intendano utilizzare il servizio) editando i file di manifest.

4.2.2Configurazione librerie ORM

Le modalità di integrazione cambiano leggermente a seconda della tipologia diframework ORM utilizzato.

4.2.2.1 Framework JPAControllare il provider JPA utilizzato. Se diverso da Hibernate sostituirlo con laversione di Hibernate più recente.

Inserire il seguente frammento xml nel persistence.xml, all’interno del tagpersistence-unit:

<shared-cache-mode>ALL</shared-cache-mode>

Lo shared cache mode è da impostare a ENABLE_SELECTIVE se si desideraabilitare il caching sulle singole entità tramite le annotazioni.

Inserire il seguente frammento xml nel tag persistence-unit/properties in codaall’elenco delle proprietà già presenti:

 <property name="hibernate.cache.use_second_level_cache" value="true"/><property name="hibernate.cache.use_query_cache" value="true" /><property name="hibernate.cache.hazelcast.shutdown_on_session_factory_close" value="false" /><property name="hibernate.cache.use_minimal_puts" value="false" />

<property name="hibernate.cache.hazelcast.use_native_client" value="true" /><property name="hibernate.cache.hazelcast.configuration_file_path" value="hazelcast-dbcache-client.xml" /><property name="hibernate.cache.region.factory_class" value="com.hazelcast.hibernate.HazelcastCacheRegionFactory" />



N.B.Per attivare il caching anche sulle query hql occorre settare l’hint:

query.setHint("org.hibernate.cacheable", true);



AlmavivA S.p.A.


Per maggiori informazioni sulla cache di secondo livello JPA consultare ladocumentazione ufficiale:http://docs.oracle.com/javaee/6/tutorial/doc/gkjia.html

4.2.2.2 HibernateNel file di configurazione di Hibernate aggiungere le seguenti proprietà:

 <property name="hibernate.cache.use_second_level_cache">true</property><property name="hibernate.cache.use_query_cache">true</property><property name="hibernate.cache.hazelcast.shutdown_on_session_factory_close">false</property><property name="hibernate.cache.use_minimal_puts">false</property> <property name="hibernate.cache.hazelcast.use_native_client">true</property><property name=" hibernate.cache.hazelcast.configuration_file_path">hazelcast-dbcache-client.xml</property><property name="hibernate.cache.region.factory_class"> com.hazelcast.hibernate.HazelcastCacheRegionFactory </property>



Anche in questo caso, per attivare il caching su una query hql, occorreimpostare l’hint.

Per maggiori informazioni sulla cache di secondo livello di Hibernate si rimandaalla documentazione ufficiale:https://docs.jboss.org/hibernate/orm/3.3/reference/en/html/performance.html#performance-cache

4.2.3Utilizzo delle librerie Spring Cache

Modificare come indicato gli attributi del tag beans nell’applicationContext.xml:

<beans xmlns="http://www.springframework.org/schema/beans" xmlns:aop="http://www.springframework.org/schema/aop" xmlns:context="http://www.springframework.org/schema/context" xmlns:jee="http://www.springframework.org/schema/jee" xmlns:tx="http://www.springframework.org/schema/tx" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:hz="http://www.hazelcast.com/schema/spring" xmlns:cache="http://www.springframework.org/schema/cache"

xsi:schemaLocation="http://www.springframework.org/schema/aophttp://www.springframework.org/schema/aop/spring-aop-3.2.xsd http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-3.2.xsd http://www.springframework.org/schema/context

http://www.springframework.org/schema/context/spring-context-3.2.xsd



AlmavivA S.p.A.

http://docs.oracle.com/javaee/6/tutorial/doc/gkjia.html

tp://www.springframework.org/schema/context%20h

tp://www.springframework.org/schema/context%20h

tp://www.springframework.org/schema/beans%20h

tp://www.springframework.org/schema/beans%20h

https://docs.jboss.org/hibernate/orm/3.3/reference/en/html/performance.html%23performance-cache

https://docs.jboss.org/hibernate/orm/3.3/reference/en/html/performance.html%23performance-cache


http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee-3.2.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-3.2.xsdhttp://www.springframework.org/schema/cache

http://www.springframework.org/schema/cache/spring-cache-3.2.xsdhttp://www.hazelcast.com/schema/spring http://www.hazelcast.com/schema/spring/hazelcast-spring-3.0.xsd">

In grassetto sono evidenziate le parti da aggiungere.

Sempre nello stesso file aggiungere un property placeholder per la configurazione del client:

<context:property-placeholder location="classpath*:/hazelcastDbcacheClient.properties" ignore-unresolvable="true" />

Inserire inoltre il seguente frammento xml prima della chiusura del tag beans:



<cache:annotation-driven cache-manager="cacheManager" />

<hz:client id="client" ><hz:group name="${group.name}" password="${group.password}"/><hz:network>

<hz:member>${cluster.members.address1}</hz:member><hz:member>${cluster.members.address2}</hz:member>

</hz:network></hz:client>

<bean id="cacheManager" class="com.hazelcast.spring.cache.HazelcastCacheManager"><constructor-arg ref="client"/>

</bean>



Per maggiori informazioni su Spring Cache fare riferimento alla documentazio-ne ufficiale:http://docs.spring.io/spring/docs/3.2.x/spring-framework-reference/html/ca-che.html



AlmavivA S.p.A.

http://docs.spring.io/spring/docs/3.2.x/spring-framework-reference/html/cache.html

http://docs.spring.io/spring/docs/3.2.x/spring-framework-reference/html/cache.html

tp://www.springframework.org/schema/cache%20h

tp://www.springframework.org/schema/cache%20h


5 GESTIONE AMBIENTI APPLICATIVI E RISORSE

5.1 Struttura degli eventiIl dizionario dei dati dell’evento raccoglie i dati dell’evento e ne definisce ilsignificato, in accordo con i requisiti espressi, per effettuare un monitoraggioefficace dei processi analizzati.Il dizionario dei dati dell’evento è una lista nella quale il singolo dato èspecificato con i seguenti campi:

Attributo: identificativo del dato Tipo: indica il tipo dato, ossia come sono rappresentati i valori del dato Opzionale o Richiesto: indica se il dato è opzionale o obbligatorio Descrizione: riporta una descrizione del dato

I tipi di dato ammessi sono: string: sequenza di caratteri alfanumerici number: numero intero null: vuoto o null timestamp: timestamps object: struttura dati rappresentata da sequenze di coppie nome-valore



AlmavivA S.p.A.


La tabella che segue riporta il dizionario dei dati dell’evento per TiX.

Attributo TipoObbl./Opz.

Descrizione

hostname STRINGIdentificativo dell’hostname che ha generato l’evento

ipAddress STRINGIndirizzo ip della macchina cheha generato l’evento

dataEvento TIMESTAMPData dell'evento in formato YYYY-MM-DD hh.mm.ss.SSS

codProc STRING opzionale Identificativo del processo

codApp STRINGIdentificativo dell’applicazione che partecipa al processo in esame

idIstanza STRINGIdentificativo dell’istanza di processo che permette di correlare gli eventi.

progEvento NUMBER

Nell’ambito di una istanza di processo è un progressivo cheviene incrementato ogni volta che viene prodotto un evento.

codAtt STRING

Codice dell’attività sulla quale ha effetto l’esecuzione del Processo. In questo modo si intende definire la gerarchia: Processo con sotto attività (senecessarie)

codEsitoEvento NUMBER Codice esito evento

tipoEvento STRINGTipologia dell’evento che si stacomunicando

idMsgEvento STRING opzionaleCampo utile all’identificazione ed alla raccolta e categorizzazione degli eventi.

msgEvento STRING opzionale

Messaggio dell’evento. Eventuale descrizione che si vuole comunicare con l’evento.

idUtente STRING opzionaleIdentificativo utente per cui si esegue l'attività che ha generato l'evento

idOperatore STRING opzionaleIdentificativo del soggetto cheè loggato sull’applicativo

idRuoloOperatore STRING opzionaleIdentificativo del ruolo del soggetto che è loggato sull’applicativo



AlmavivA S.p.A.


Attributo TipoObbl./Opz.

Descrizione

ComplexDataObject[<STRING,STRING>]

opzionale

Struttura di array <key,value>in cui è possibile inserire attributi che si rendono necessari per le singole applicazioni

Gli attributi opzionali sono da considerarsi non obbligatori quando leapplicazioni non hanno i corrispondenti dati disponibili per la natura stessadell’applicazione. In questo caso possono non essere valorizzati tali attributi.

I dati la cui opzionalità è a discrezione del produttore dell’evento devonoessere inseriti nel formato chiave valore nel campo Complex Data.

Se si utilizza l’appender log4j per produrre le informazioni questo popolerà iseguenti campi interrogando il sistema:

1. Hostname2. IpAddress3. DataEvento

Il campo CodApp potrà essere configurato staticamente all’interno dellaconfigurazione.

Nel caso si voglia comunicare un evento di sicurezza è necessario indicarlo nelcampo tipo evento. Considerando che gli eventi di sicurezza sono in relazionecon un’utenza sarà necessario popolare i campi:

IdUtente IdOperatore IdRuoloOperatore IdMsgEvento MsgEvento

Al fine di avere una definizione corretta e delimitata dei valori degli attributi,viene definita una serie di valori ammessi che possono essere ampliati anchecon interventi futuri. Un eventuale ampliamento dei valori degli attributipotrebbe comportare la necessità di effettuare un nuovo rilascio delle API perrecepire le modifiche effettuate. L’aggiornamento delle API avverrà in modo del



AlmavivA S.p.A.


tutto trasparente agli applicativi che le utilizzano in quanto si manterrà sempreretro compatibilità con i valori precedenti.

La tabella seguente illustra una ipotesi di valori ammessi per quegli attributi aiquali si pensa di dare un valore compreso in un range ben definito.

Attributo Valore Descrizione

CodProc PR1 Codice Processo PR1PR2 Codice Processo PR2

CodApp A1 Codice applicazione A1A2 Codice applicazione A2An Codice applicazione An

CodAtt C1 Codice dell’attività C1C2 Codice dell’attività C2Cn Codice dell’attività Cn

CodEsitoEvento 1…n Numerico che specifica il tipo di esito dell’ evento

TipoEvento Sicurezza Evento di tipo sicurezzaProcesso Evento di processo

5.2 Specifiche di integrazione tramite libreria SAASLoggerIl colloquio tra le applicazioni Java e la piattaforma è stato centralizzato nella libreria Java SAASLogger contenuta nel file SAASLogger.jar. Naturalmente la piattaforma può essere contattata anche via logstash (cfr. prossimo paragrafo) in ascolto su file di log applicativi. La libreria SAASLogger è costituita dalle seguenti classi:

➔ CeeEvent: classe che costruisce un evento in formato cee. La firma del costruttore della classe è la seguente:public CeeEvent(String hostname, String ipAddress, Date dataEvento, String codProc, String idIstanza, String codApp, String codAtt, int codEsitoEvento, String tipoEvento, String msgEvento)

➔ RestClient: classe che invia un evento cee a Karaf. La firma del metodo principale è la seguente:public HttpResponse post_JSON(Object requestEntity, String baseUri)dove requestEntity è un'istanza di CeeEvent e baseUri è l'url del servizio REST di Karaf restlogcollector

Vediamo un esempio di invocazione:

CeeEvent ceeEvent = new CeeEvent("RT-SANFER-JB01-S1.rt.tix.it","10.159.33.81",



AlmavivA S.p.A.


new java.util.Date(),"ASYNC-NT","1","1","FERT",2,"Processo","Elaborazione asincrona notifiche 1.");

RestClient restClient = new RestClient(); restClient.post_JSON(ceeEvent, "http://localhost:8888/restlogcollector");

5.3 Specifiche di integrazione di appender log4jAl fine di consentire la comunicazione degli eventi, le applicazioni dovrannomodificare il proprio file di configurazione “log4j configuration file”(presumibilmente log4j.xml). In particolare nel file di configurazione è necessario definire il seguenteappender:<appender name="EVENT_DAILY" class="org.apache.log4j.DailyRollingFileAppender">

<param name="Threshold" value="DEBUG"/><param name="File" value="${server.dir}/log/ceeEvent.log"/><param name="DatePattern" value=".yyyy-MM-dd"/><layout class="org.apache.log4j.PatternLayout"><param name="ConversionPattern" value="%d %-5p - [%C{1}] %m%n"/></layout>

</appender>

In particolare bisogna notare che la descrizione ${server.dir} è specifica deltipo di server che si sta utilizzando e si riferisce alla directory di installazionedel server.Questa configurazione consente di tracciare gli eventi di log tramite log4jclassificandoli con un livello “debug”.Le applicazioni dovranno generare un evento nel formato chiave:valoreseparando le coppie con il carattere speciale “|” ed inserendoli nellainvocazione dell’evento. Le coppie chiave:valore dovranno rispettare ildizionario degli eventi definito nel documento di progettazione delle API.Un esempio di invio di evento tramite questo appender è il seguente:logger.debug(“Hostname:nomemacchina1|Ipaddress:10.100.5.28|DataEvento:2014-02-25 12.20.28.111|CodApp:A1|CodAtt:C1|CodEsitoEvento:51|TipoEvento:Processo”);



AlmavivA S.p.A.


5.4 Specifiche di invio eventi tramite servizio RESTLe applicazioni che inviano gli eventi utilizzando il servizio REST messo adisposizione, dovranno realizzare un client REST che invochi la url fornita(http://ipaddres:portnumber/GestioneEventi/raccoltaEventi). Il client devegestire una connessione http in cui specificare un MIME media type“application/json”.Il parametro di input fornito al servizio è una stringa in formato JSON costituitadagli elementi del dizionario eventi, avendo cura di rispettare le obbligatorietà.Il seguente è un esempio di stringa in formato java per il parametro di input:String input = "{\" Hostname \": nomemacchina1,\"Ipaddress \":\"10.100.5.28, \" DataEvento \":\"2014-02-25 12.20.28.111, \"CodApp \":\"A1, \" CodAtt \":\"C1, \" CodEsitoEvento \":51,TipoEvento \":\"Processo\"}";

A questa richiesta il servizio REST fornisce in risposta una stringa in formatoJSON con l’esito dell’invio evento nella forma:{“esito”:”OK”} in caso di esito positivo dell’invio{“esito”:”KO”,”descrizione”:”dato XYZ obbligatorio non presente”}

5.5 Specifiche di interrogazione eventiGli eventi messi a disposizione dal sistema di logging e monitoring possonoessere reperiti interrogando il servizio RESThttp://ipaddres:portnumber/GestioneEventi/auditingEventoProcesso.Il servizio REST comunica accettando il parametro in input con il formalismoJSON, quindi nella comunicazione rispetta il pattern "application/json".I parametri di ricerca sono tutti gli attributi previsti dal dizionario dati, inparticolare il servizio REST accetta come parametro di input un oggettoEventModel dettagliato nel documento di progettazione delle API. I valori fornitial parametro di input saranno utilizzati per eseguire l’interrogazione e reperire idati. Il risultato della richiesta viene fornito in risposta dal servizio REST econterrà un array di EventModel in formato JSON.Un esempio di parametro di input fornito nel formalismo JSON sotto forma distringa è il seguente:{\" CodApp \": A1\"}la richiesta verrà tradotta dalle API in una ricerca degli eventi riguardanti ilcodice applicazione “A1”. Il risultato della interrogazione viene fornito sottoforma di array di oggetti JSON rappresentabili con lo stesso oggetto dellainterrogazione “EventModel”.



AlmavivA S.p.A.


Dovendo trattare eventi di sicurezza, classificati dal TipoEvento “Sicurezza”, iservizi REST messi a disposizione saranno due, uno per la ricerca di eventi di“Processo”(http://ipaddres:portnumber/GestioneEventi/auditingEventoProcesso) ed unoper la ricerca di eventi di “Sicurezza”(http://ipaddres:portnumber/GestioneEventi/auditingEventoSicurezza),l’invocazione di quest’ultimo sarà soggetta ad autenticazione ed autorizzazione.

5.6 Specifiche di integrazione per invio segnalazioneIl sistema di Trouble Ticketing provvede ad inviare le segnalazioni alleapplicazioni attraverso l’invocazione di un web service messo a disposizione equindi esposto dalle applicazioni che devono ricevere le segnalazioni. Il webservice comunicherà sfruttando il protocollo SOAP e l’informazione minimaprevista per la segnalazione del ticket è la seguente:<complexType name="TTassigned">

<sequence><element name="id" type="string"/><element name="title" type="string"/><element name="type" type="string"/><element name="priority" type="string"/><element name="openDate" type="dateTime"/><element name="description" type="string"/><element name="idReminder" type="string" minOccurs=”0”/>

</sequence></complexType>Il web service deve quindi essere adeguato a ricevere una informazione diquesto tipo e a fornire una risposta positiva o negativa per informare ilchiamante della corretta ricezione o meno della segnalazione (ticket).

5.7 Specifiche di integrazione per comunicazione chiusura segnalazione

Gli applicativi che devono comunicare al sistema di Trouble Ticketing lachiusura di un ticket precedentemente preso in carico, devono invocare un webservice esposto dal sistema di TTMS (Trouble Ticketing Management System) ecomunicare attraverso il protocollo SOAP.Il set di dati minimo previsto che l’applicazione dovrà fornire al TTMS è ilseguente:<complexType name="TTmanaged">

<sequence>



AlmavivA S.p.A.


<element name="id" type="string"/><element name="title" type="string"/><element name="type" type="string"/><element name="priority" type="string"/><element name="closedDate" type="dateTime"/><element name="openEngineer" type="string"/><element name="closeEngineer" type="string"/><element name="contactEngineer" type="string"/><element name="solutionDescription" type="string"/><element name="location" type="string"/>

</sequence></complexType>

in fase di progetto e analisi di dettaglio sarà possibile aggiungere funzionalità oservizi che si riveleranno necessari e quindi estendere o modificare i datiproposti.

La seguente descrizione riporta il significato ed i possibili valori ammessi deldizionario dati per quanto riguarda i ticket:id: identificativo univoco del tickettitle: titolo della segnalazionetype: operational, administrative, informational, testpriority: low, medium, highopenDate: data/ora apertura ticketdescription: breve descrizione testuale della problematicaidReminder: identificativo del ticket per cui si invia un sollecito.status: opened, updated, closed, solved, cancelled, reopened, not competenceclosedDate: data/ora chiusura ticketopenEngineer: nome del tecnico che visualizza il ticketcloseEngineer: nome del tecnico che chiude il ticketcontactEngineer: nome del tecnico da contattaresolutionDescription: descrizione della soluzione adottatalocation: luogo in cui avviene la gestione del ticket



AlmavivA S.p.A.


6 DEFINIZIONE DELLE REGOLE DI COMPLEX EVENT PROCESSING: CASO D'USO FERT

6.1 IntroduzioneLa modalità con la quale gli eventi attivano alert riguardanti le applicazionimonitorate è naturalmente peculiare alla logica di business di ogniapplicazione.L'approccio utilizzato è quello di Complex Event Processing (CEP) per ilquale rimandiamo al documento di progettazione dei servizi e alladocumentazione del framework utilizzato (DROOLS).In questo paragrafo mostriamo come gli eventi cee vengono gestiti inDrools nel caso del sistema di Fatturazione Elettronica.

6.2 Descrizione delle regoleNel sistema di fatturazione Elettronica (FERT) sono state implementate 4regole di Complex Event Processing.

6.2.1 Nuova Istanza di Processo FERT

Quando al sistema di monitoraggio arriva un evento legato ad un processoavente una istanza ancora non registrata il motore a regole cataloga comenuovo il processo pervenuto:

rule "Nuova Istanza di Processo FERT"

when

$e : Evento( status == Evento.RUNNING) from entry-point "entryone"

not Processo(id == $e.getIdProcesso(), idIstanza == $e.getIdIstanza())

not First(idProcesso == $e.getIdProcesso(), idIstanza == $e.getIdIstanza())

then

insert(new Processo($e.getIdProcesso(), $e.getIdIstanza(), $e.getStatus()));

insert(new First($e.getIdProcesso(), $e.getIdIstanza()));

log("Processo iniziato.");

end

Il processo rimane in memoria per un numero di minuti parametrizzabile.



AlmavivA S.p.A.


6.2.2 Attività FERT conclusa senza timeout

Quando al sistema di monitoraggio arriva un evento che dichiara laconclusione di un processo e la distanza temporale dell'evento da quellodichiarante l'inizio del processo è inferiore ad un intervallo temporaleparametrizzato il processo viene dichiarato chiuso con esito positivo:

rule "Attività FERT conclusa senza timeout, reset KB"

when

$f: First()

$e1: Evento(idProcesso == $f.getIdProcesso(),

idIstanza == $f.getIdIstanza(),

status == Evento.RUNNING) from entry-point "entryone"

$e2: Evento(idAttivita == $e1.getIdAttivita(),

idProcesso == $f.getIdProcesso(),


status == Evento.COMPLETED,

this after[ 0,30s ] $f ) from entry-point "entryone"

$p: Processo(id == $f.getIdProcesso(), idIstanza == $f.getIdIstanza())

then

log("Attività FERT completata, reset KB");

java.util.Calendar cal = java.util.Calendar.getInstance();

java.text.SimpleDateFormat sdf =

new java.text.SimpleDateFormat("yyyy-MM-dd HH.mm.ss.SSS");

Risposta ris = new Risposta($p.getId(), "MR", 0, $e2.getIdAttivita(), 3,

"Processo", "", sdf.format(cal.getTime()),

$f.getIdIstanza(),

it.almaviva.tix.common.Utils.findIpAddresses().get(0), it.almaviva.tix.common.Utils.findHostName());

com.google.gson.Gson gson = new com.google.gson.Gson();

String s = gson.toJson(ris);

it.almaviva.tix.common.UtilitySendRequest.sendRequestPost(

"http://elasticsearch/cee/cee/", s,

it.almaviva.tix.common.UtilitySendRequest.CONTENT_TYPE_JSON);

retract($f);

retract($p);

retract($e1);

retract($e2);

end

Il processo viene rimosso dal motore a regole.



AlmavivA S.p.A.


6.2.3 Attività FERT conclusa con timeout

Quando al sistema di monitoraggio arriva un evento che dichiara laconclusione di un processo e la distanza temporale dell'evento da quellodichiarante l'inizio del processo è superiore ad un intervallo temporaleparametrizzato il processo viene dichiarato chiuso con timeout:

rule "Attività FERT conclusa con timeout, reset KB"

when

$f: First()

$e1: Evento(idProcesso == $f.getIdProcesso(),


status == Evento.RUNNING) from entry-point "entryone"

$e2: Evento(idAttivita == $e1.getIdAttivita(),

idProcesso == $f.getIdProcesso(),


status == Evento.COMPLETED, this after[30s] $f ) from entry-point "entryone"

$p: Processo(id == $f.getIdProcesso(), idIstanza == $f.getIdIstanza())

then

log("Attività FERT conclusa con timeout, invio warning");




Risposta ris = new Risposta($p.getId(), "MR", 0, $e2.getIdAttivita(), 0,

"Processo",

"E' stato rilevato un timeout maggiore di 30 secondi nel processo", sdf.format(cal.getTime()),

$f.getIdIstanza(), i

t.almaviva.tix.common.Utils.findIpAddresses().get(0), it.almaviva.tix.common.Utils.findHostName());




"http://elasticsearch/cee/cee/", s, it.almaviva.tix.common.UtilitySendRequest.CONTENT_TYPE_JSON);

retract($f);

retract($p);

retract($e1);

retract($e2);

end




AlmavivA S.p.A.


6.2.4 Errore FERT

Quando al sistema di monitoraggio arriva un evento che dichiara che ilprocesso ha generato un'eccezione il processo viene dichiarato in errore:

rule "Errore FERT, reset KB"

when

$e : Evento( status == Evento.ERROR) from entry-point "entryone"

$p: Processo(id == $e.getIdProcesso(), idIstanza == $e.getIdIstanza())

$f: First()

then

log("Errore FERT");




Risposta ris = new Risposta($p.getId(), "MR", 0, "ATT_MR_2", 0,

"Processo", "Evento di errore", sdf.format(cal.getTime()),

$f.getIdIstanza(),

it.almaviva.tix.common.Utils.findIpAddresses().get(0), it.almaviva.tix.common.Utils.findHostName());




"http://10.159.35.91:9200/cee/cee/", s,

it.almaviva.tix.common.UtilitySendRequest.CONTENT_TYPE_JSON);

retract($p);

retract($e);

retract($f);

end




AlmavivA S.p.A.

Documents

Sviluppo della piattaforma dei servizi cloud di base per ...oscat.rete.toscana.it/docman/view.php/604/3150/RT+-+SAAS_PLATT... · Regione Toscana Sviluppo della piattaforma dei servizi