Guida Installazione della distribuzione sorgente di ... · 3.3.1.8 Validazione Semantica della Conﬁgurazione e del Registro dei Servizi . . . . . . . . . . . . .17

Guida Installazione della distribuzionesorgente di OpenSPCoop 1.4

i

Guida Installazione della distribuzione sorgente diOpenSPCoop 1.4


ii

Copyright © 2005-2011 Link.it s.r.l.

http://www.link.it


iii

Indice

1 Prerequisiti di Installazione 1

2 Contenuti della Distribuzione 1

3 Porta di Dominio OpenSPCoop 1

3.1 Compilazione dei sorgenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

3.1.1 Porta di Dominio per Application Server J2EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

3.1.2 Porta di Dominio per Servlet Container . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3.1.3 Documentazione API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3.2 Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3.2.1 Creazione delle directory di lavoro e di configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3.2.2 Configurazione delle code JMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.2.3 Configurazione del Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.2.4 Pool di Connessioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.2.5 Configurazione Iniziale della Porta di Dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2.5.1 Installazione Configurazione XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2.5.2 Installazione Configurazione DB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2.6 Configurazione Iniziale del Registro dei Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2.7 Deploy del Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3.1 Aspetti di Configurazione Generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3.1.1 Accesso alla Configurazione della Porta di Dominio . . . . . . . . . . . . . . . . . . . . . . . 10

3.3.1.2 Accesso al Registro dei Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3.1.3 Accesso al DBMS dei messaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3.1.4 Accesso al broker JMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3.1.5 Configurazione HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3.1.6 Configurazione dei Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3.1.7 Configurazione JMX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3.1.8 Validazione Semantica della Configurazione e del Registro dei Servizi . . . . . . . . . . . . . 17

3.3.1.9 Integrazione dei Servizi Applicativi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3.1.10 Autorizzazione Buste e-Gov in ingresso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.1.11 Protocollo e-Gov . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3.1.12 Gestione stateless/stateful dei messaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3.1.13 Consegna asincrona dei messaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3.1.14 Sincronizzazione temporale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3.1.15 Dump dei messaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3.1.16 Tuning dei componenti architetturali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26


iv

3.3.2 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3.2.1 Messaggi Diagnostici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3.2.2 Tracce e-Gov . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3.2.3 Log della Porta di Dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3.2.4 Dump dei messaggi applicativi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.3.3 Personalizzazione dei componenti della Porta di Dominio . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.3.3.1 Implementazione personalizzata del servizio Consegna Contenuti Applicativi . . . . . . . . . 32

3.3.3.2 Autenticazione personalizzata dei Servizi Applicativi . . . . . . . . . . . . . . . . . . . . . . 32

3.3.3.3 Autorizzazione personalizzata dei Servizi Applicativi . . . . . . . . . . . . . . . . . . . . . . 32

3.3.3.4 Autorizzazione Contenuti dei Servizi Applicativi . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.3.3.5 Autorizzazione personalizzata buste eGov in ingresso . . . . . . . . . . . . . . . . . . . . . . 33

3.3.3.6 Autorizzazione Contenuti delle buste eGov in ingresso . . . . . . . . . . . . . . . . . . . . . . 34

3.3.3.7 Header di Integrazione dei Servizi Applicativi personalizzati . . . . . . . . . . . . . . . . . . 34

3.3.3.8 OpenSPCoopAppender personalizzato per i Messaggi Diagnostici . . . . . . . . . . . . . . . 35

3.3.3.9 OpenSPCoopAppender personalizzato per le Tracce . . . . . . . . . . . . . . . . . . . . . . . 35

3.3.3.10 Implementazione personalizzata del servizio Ricezione Contenuti Applicativi . . . . . . . . . 36

3.3.3.11 Threshold personalizzati per il controllo delle risorse . . . . . . . . . . . . . . . . . . . . . . 37

3.3.3.12 Marcatura personalizzata delle Buste nel repository e-Gov . . . . . . . . . . . . . . . . . . . 37

3.3.3.13 Sincronizzazione temporale personalizzata . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.3.4 Interoperabilità rispetto ad altre implementazioni di Porta di Dominio . . . . . . . . . . . . . . . . . . . 38

4 Registro dei Servizi 39

4.1 Interfaccia Web del Registro dei Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1.1 Compilazione dei sorgenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1.1.1 Interfaccia Web per Application Server J2EE . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1.1.2 Interfaccia Web per Servlet Container . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.1.2 Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.1.2.1 Configurazione del Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.1.2.2 Pool di Connessioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1.2.3 Configurazione delle code JMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1.2.4 Configurazione Iniziale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.1.2.5 Deploy del Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.1.3 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.1.3.1 Tipologia del Registro dei Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1.3.2 Accesso al DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43


4.1.3.4 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.1.3.5 Personalizzazione dell’interfaccia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2 Interfaccia WebService del Registro dei Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46


v


4.2.1.1 Interfaccia WebService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2.2 Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46



4.2.3 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47


4.2.3.2 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5 Pdd Console 48

5.1 PddConsole con Registro dei Servizi locale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48




5.1.2 Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49





5.1.3 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.1.3.1 Accesso al DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.1.3.2 Accesso al database delle tracce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.1.3.3 Accesso al database dei messaggi diagnostici . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.1.3.4 Accesso al database dei messaggi in transito sulla Porta di Dominio . . . . . . . . . . . . . . . 52

5.1.3.5 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53


5.2 PddConsole con Registro dei Servizi centralizzato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55




5.2.2 Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56





5.2.3 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2.3.1 Accesso al DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2.3.2 Accesso al database delle tracce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.2.3.3 Accesso al database dei messaggi diagnostici . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.2.3.4 Accesso al database dei messaggi in transito sulla Porta di Dominio . . . . . . . . . . . . . . . 59

5.2.3.5 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60



vi

6 Pdd Console per la gestione centralizzata 616.1 Interfaccia Web di gestione centralizzata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62


6.1.2 Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62



6.1.2.3 Configurazione delle code JMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64



6.1.3 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.1.3.1 Gestione/Monitoraggio delle Porte di Dominio . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.1.3.2 Gestione del Registro dei Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.1.3.3 Gestione del Gestore Eventi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.1.3.4 Gestione del sistema di autorizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.1.3.5 Accesso al DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67


6.1.3.7 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67


6.2 Interfaccia WebService per la gestione CRUD del Registro dei Servizi . . . . . . . . . . . . . . . . . . . . . . . 70


6.2.2 Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71



6.2.3 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71


6.2.3.2 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.3 Interfaccia WebService per la gestione CRUD della configurazione di una PdD . . . . . . . . . . . . . . . . . . 72


6.3.2 Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73



6.3.3 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.3.3.1 Tipologia della configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.3.3.2 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.4 Interfaccia WebService per il monitoraggio di una PdD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74


6.4.2 Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74



6.4.3 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.4.3.1 Accesso al Repository dei Messaggi della PdD . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.4.3.2 Accesso ai diagnostici emessi dalla PdD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.4.3.3 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76


vii

7 Gestore Eventi 76

7.1 Compilazione dei sorgenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

7.1.1 Gestore Eventi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

7.1.2 Interfaccia Web di gestione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

7.2 Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

7.2.1 Configurazione del Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

7.2.2 Pool di Connessioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

7.2.3 Configurazione delle code JMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

7.2.4 Configurazione Iniziale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

7.2.5 Deploy del Software GestoreEventi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

7.2.6 Deploy dell’Interfaccia di Gestione del GestoreEventi . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

7.2.7 Configurazione dell’ambiente SPCoop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

7.2.7.1 Configurazione del Registro dei Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

7.2.7.2 Configurazione della Porta di Dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

7.3 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7.3.1 Configurazione del Gestore Eventi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7.3.1.1 Accesso al DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82


7.3.1.3 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7.3.1.4 Personalizzazione dell’applicazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.3.2 Configurazione dell’interfaccia web di gestione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7.3.2.1 Accesso al DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7.3.2.2 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84



viii

Elenco delle figure

1 Menù di Configurazione della Porta di Dominio OpenSPCoop . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Configurazione per l’accesso ad un Registro dei Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Architettura della PddConsole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62


1 / 84

1 Prerequisiti di Installazione

L’installazione della distribuzione sorgente del Software OpenSPCoop ha come prerequisiti la disponibilità del seguente software:

• Java JDK 1.5.0 (http://java.sun.com/j2se/1.5.0/index.jsp)

• Un Application Server J2EE, attualmente il progetto è sviluppato in ambiente JBoss 4.2.2 e JBoss 5.1.0 (http://www.jboss.com)e su questi Application Server sono mirate le istruzioni per l’installazione.

In alternativa, per alcuni prodotti di questa guida è possibile utilizare anche un servlet container

• Un DBMS, accessibile via JDBC, attualmente la distribuzione è testata usando Postgresql 8.x, MySQL 5.x e Oracle 10g; suquesti DB sono mirate le istruzioni per l’installazione.

• L’utility Ant (http://ant.apache.org/)

2 Contenuti della Distribuzione

Il software della distribuzione sorgente di OpenSPCoop è scaricabile dalla sezione download del sito www.openspcoop.org.

La distribuzione software dei sorgenti include le seguenti directory:

• deploy: include i files che permettono la configurazione dell’ambiente necessario al corretto funzionamento di OpenSPCoop.

• doc: include i manuali d’installazione dei prodotti e la documentazione API (vedi Sezione 3.1.3).

• example: include Client, Server e configurazioni di esempio utilizzabili per effettuare test dei prodotti di OpenSPCoop.

• tools: include interfacce grafiche per la gestione della porta di dominio, del registro dei servizi, del gestore eventi ed un sistemacentralizzato di gestione dell’intero ambiente SPCoop. Inoltre sono presenti vari tool web services e ’command-line’ per lagestione ed il monitoraggio dei vari componenti software del progetto.

• services: include servizi forniti insieme alla porta di dominio OpenSPCoop. Il principale di questi è un GestoreEventi chepermette di utilizzare il paradigma ad eventi nell’ambiente SPCoop.

• testsuite: include una test suite del software, realizzata tramite TestNG (http://testng.org).

• src, include i sorgenti dei componenti principali del progetto

3 Porta di Dominio OpenSPCoop

3.1 Compilazione dei sorgenti

3.1.1 Porta di Dominio per Application Server J2EE

I sorgenti della Porta di Dominio sono disponibili all’interno della distribuzione nella directory src. Per procedere con lacompilazione è necessario utilizzare l’utility Ant sulla radice della distribuzione, eseguendo il seguente comando:

ant clean build

La compilazione produce come risultato degli archivi compressi forniti nella directory dist:

• openspcoop_core.jar, archivio contenente le classi java che formano il core della suite OpenSPCoop

• openspcoop_egov.jar, archivio contenente le classi java che implementano il protocollo e-Gov

• openspcoop_pdd.jar, archivio contenente le classi java che implementano la Porta di Dominio

• OpenSPCoop.ear, la Porta di Dominio OpenSPCoop realizzata come applicazione J2EE


2 / 84

3.1.2 Porta di Dominio per Servlet Container

È possibile effettuare anche una compilazione dei sorgenti con lo scopo di creare una versione della porta di dominio che siainstallabile in un servlet container (es. Tomcat). Per procedere con questo tipo di compilazione, sulla radice della distribuzioneeseguire il seguente comando:

ant clean build_openspcoop_web

La compilazione produce come risultato, nella directory dist, l’archivio openspcoop.war contenente la Porta di Dominio Open-SPCoop installabile in un servlet container. Con questa versione della porta di dominio non è possibile usufruire di tutte lefunzionalità presenti nella versione J2EE (vedi Sezione 3.3.1).

3.1.3 Documentazione API

Per generare la documentazione JavaDoc dei sorgenti è necessario invocare sulla radice della distribuzione il seguente comando:

ant clean api

I files javadoc verrano prodotti nella directory doc della distribuzione.

• doc/api: contiene la documentazione globale del prodotto OpenSPCoop;

• doc/pdd/api: contiene la documentazione della libreria org.openspcoop.pdd;

• doc/egov/api: contiene la documentazione della libreria org.openspcoop.egov.

3.2 Installazione

I paragrafi di questa sezione descrivono come procedere con l’installazione della Porta di Dominio nell’application server JBoss4.2.X / 5.x o nel servlet container Tomcat 5.x.

L’applicazione Porta di Dominio OpenSPCoop viene fornita sotto forma di archivio OpenSPCoop.ear (per application serverJBoss) e openspcoop.war (per servlet container Tomcat) come risultato della compilazione dei sorgenti descritta in Sezione 3.1

3.2.1 Creazione delle directory di lavoro e di configurazione

Prima di iniziare l’installazione di OpenSPCoop, è necessario creare alcune directory di lavoro e configurazione:

1. /var/openspcoop/log, dove saranno prodotti i log prodotti dalla porta di dominio

2. /var/openspcoop/msgRepository, un’area di lavoro che funge da repository temporaneo di messaggi in transito dalla portadi dominio

3. /etc/openspcoop, necessaria solo in caso di configurazione della PdD (vedi Sezione 3.2.5) o del registro dei servizi (vediSezione 4) in formato xml, contiene i relativi file xml.

NotaLa porta di dominio deve possedere i diritti di lettura sulla directory di configurazione (/etc/openspcoop) e di scrittura su quelledi lavoro (/var/openspcoop); se il server dove è in esecuzione gira come utente jboss/tomcat, sarà necessario dare i diritti inscrittura all’utente jboss/tomcat sulla directory /var/openspcoop/log e /var/openspcoop/msgRepository.

Per denominare diversamente le directory di cui sopra, vedi Sezione 3.3.2, Sezione 3.3.1.3 e Sezione 3.3.1


3 / 84

3.2.2 Configurazione delle code JMS

La PdD OpenSPCoop distributa sotto forma di archivio J2EE OpenSPCoop.ear necessita di alcune code JMS. Se si sta installandola versione per Servlet Container (Tomcat) non si devono seguire le indicazioni descritte in questo paragrafo.

All’interno della distribuzione in deploy/pdd/code_jms/BROKER/openspcoop-destinations-service.xml vengono fornite le confi-gurazioni delle code JMS per la loro creazione in JBoss 4.x e in JBoss 5.x:

• deploy/pdd/code_jms/jbossMQ/openspcoop-destinations-service.xml, le code sono istanziabili in JBoss 4.x attraverso la copiadel file in JBOSSDIR/server/default/deploy/jms

• deploy/pdd/code_jms/jbossMessaging/openspcoop-destinations-service.xml, le code sono istanziabili in JBoss 5.x attraverso lacopia del file in JBOSSDIR/server/default/deploy/messaging

3.2.3 Configurazione del Database

OpenSPCoop richiede l’installazione di un database relazionale nel quale devono essere registrate le tabelle utilizzate per lagestione dei messaggi. Attualmente lo sviluppo di OpenSPCoop viene effettuato su tre tipi di database: Postgres v8, MySQL v5e Oracle10gExpress.

Le tabelle SQL richieste da OpenSPCoop sono descritte all’interno del file deploy/pdd/SQL_Table/TIPO_DATABASE/OpenSPCoop.sql.

NotaLa porta di dominio deve possedere i diritti di lettura/scrittura sulle suddette tabelle.

NotaA seconda del tipo di repository dei messaggi impostato per la porta di dominio (file system o db; per ulteriori dettagli vediSezione 3.3.1.3), la tabella DEFINIZIONE_MESSAGGI definita nel file OpenSPCoop.sql deve possedere o meno la colonnaMSG_BYTES. Di default OpenSPCoop utilizza il fileSystem per implementare il msgRepository, e quindi la definizione fornitanel file non contiene la colonna MSG_BYTES. All’interno del file viene anche fornita, per esempio, la definizione (commentata)della tabella con l’elemento MSG_BYTES utilizzabile per un repository dei messaggi mantenuto su database.

A titolo esemplificativo, vengono elencati i passi di configurazione da effettuare per la configurazione del Database PostgreSQLsu sistema operativo Linux.

1. Creazione Utente

[user@localhost]$ suParola d’ordine: XXX[root@localhost]# su - postgres-bash-3.1$ createuser -PEnter name of role to add: openspcoopEnter password for new role: openspcoopConferma password: openspcoopShall the new role be a superuser? (y/n) nShall the new role be allowed to create databases? (y/n) nShall the new role be allowed to create more new roles? (y/n) nCREATE ROLE

2. Crezione Database

[user@localhost]$ suParola d’ordine: XXX[root@localhost]# su - postgres-bash-3.1$createdb -O openspcoop openspcoopCREATE DATABASE


4 / 84

3. Abilitazione accesso dell’utente al Database, è possibile abilitare l’accesso editando il file /var/lib/pgsql/data/pg_hba.conf(come super utente). Abilitiamo quindi l’utente openspcoop ad accedere al db openspcoop, aggiungendo le seguenti righeal file:

local openspcoop openspcoop md5host openspcoop openspcoop 127.0.0.1 255.255.255.255 md5

4. Creazione tabelle SQL

[user@localhost]$ psql openspcoop openspcoop < deploy/pdd/SQL_Table/TIPO_DATABASE/ ←↩OpenSPCoop.sql

Password for user openspcoop: openspcoop

5. Fornire infine all’application server il driver JDBC del DB utilizzato. Ad es. per l’A.S. JBoss copiare l’apposito jar nellacartella JBOSS/server/default/lib.

NotaUlteriori tabelle SQL possono essere necessarie in caso si voglia registrare i messaggi diagnostici e/o tracciare le buste eGovsu database utilizzando gli appender forniti nella distribuzione (Vedi Sezione 3.3.2 per ulteriori dettagli ). In tal caso le tabellerichieste sono descritte nel file fornito con la distribuzione in deploy/pdd/SQL_Table/TIPO_DATABASE/Tracciamento.sql. Il filedefinisce le tabelle necessarie sia per la registrazione dei messaggi diagnostici che per il tracciamento delle buste eGov.

3.2.4 Pool di Connessioni

OpenSPCoop richiede l’installazione di un pool di connessioni verso il DBMS e, solo per la versione J2EE, di un pool diconnessioni anche verso il broker JMS.

• Database, la configurazione di default della porta di dominio richiede un datasource con nome org.openspcoop.dataSource percreare connessioni verso il Database dei messaggi.

Un datasource di esempio per l’application server JBoss viene fornito in deploy/pdd/datasource/jboss/openspcoop-ds.xml. Ilfile permette di creare la risorsa nella propria installazione dell’A.S., attraverso la configurazione e la successiva copia del filein JBOSS_DIR/server/default/deploy.

In alternativa, per l’application server JBoss, è possibile utilizzare un datasource realizzato tramite l’applicazione openspcoop-Sysconfig; per ulteriori dettagli è possibile leggere la documentazione dell’applicazione in doc/sysconfig.readme.

Un datasource di esempio per l’application server Tomcat viene fornito in deploy/pdd/datasource/tomcat/openspcoop.xml. Ilfile permette di creare la risorsa nella propria installazione di Tomcat, attraverso la configurazione e la successiva copia del filein TOMCAT_DIR/Catalina/ (es. /etc/tomcat5/Catalina/localhost/).

• Broker JMS (solo per versione J2EE), la configurazione di default della porta di dominio richiede una connection factory connome org.openspcoop.jmsPool per creare connessioni (e sessioni che permettano la gestione applicativa della transazione) versoil Broker JMS. Una connection factory di esempio viene fornita in deploy/pdd/code_jms/BROKER/openspcoop-jms-ds.xml perla sua creazione in JBoss 4.x e in JBoss 5.x:

– deploy/pdd/code_jms/jbossMQ/openspcoop-jms-ds.xml, la connection factory è istanziabile in JBoss 4.x attraverso la copiadel file in JBOSSDIR/server/default/deploy/jms

– deploy/pdd/code_jms/jbossMessaging/openspcoop-jms-ds.xml, la connection factory è istanziabile in JBoss 5.x attraverso lacopia del file in JBOSSDIR/server/default/deploy/messaging

In alternativa è possibile utilizzare una connection factory realizzata tramite l’applicazione openspcoopSysconfig, per ulterioridettagli è possibile leggere la documentazione dell’applicazione in doc/sysconfig.readme.

NotaPer ulteriori informazioni su come utilizzare connection factory o datasource registrati con nomi JNDI diversi dai default diOpenSPCoop vedi Sezione 3.3.1.4.


5 / 84

NotaL’applicazione openspcoopSysconfig, disponibile nella distribuzione in tools/sysconfig, permette di creare pool di risorse e regi-strarli nell’albero JNDI del proprio Application Server. La definizione dei pool deve essere fornita tramite un file xml che rispettilo schema in tools/sysconfig/src/schemi/sysconfig.xsd . Tutti i pool indicati nella guida utente/installazione e richiesti dai variprodotti rilasciati con la distribuzione di OpenSPCoop sono descritti in una configurazione di esempio dell’applicazione open-spcoopSysconfig in tools/sysconfig/deploy/config_file/sysconfig.xml. L’applicazione per default si aspetta il file sysconfig.xml in/etc/openspcoop. Per ulteriori dettagli è possibile leggere la documentazione dell’applicazione in doc/sysconfig.readme.

3.2.5 Configurazione Iniziale della Porta di Dominio

La Porta di Dominio richiede, per il suo funzionamento, un repository di configurazione.

OpenSPCoop supporta due tipologie di repository per la configurazione:

• XML, la configurazione della PdD risiede in un unico file xml. Questa versione è perfettamente funzionale, e più semplice dagestire, in scenari non molto dinamici e con un basso numero di soggetti e servizi. È il modo migliore di usare OpenSPCoopin ambiente di testing e di sviluppo, mentre non si addice in ambiente di produzione o in generale in casi complessi. Laconfigurazione XML della Porta di Dominio è documentata nella Guida Utente XML .

• Database, la configurazione della PdD risiede in un database relazionale. Si addice nei casi dove gli scenari sono moltodinamici e il numero di soggetti e servizi da gestire risulta elevato. Infatti la configurazione su Database consente la gestionetramite una web application che è descritta in Sezione 5. La configurazione DB della Porta di Dominio è documentata nellaGuida Utente della Porta di Dominio OpenSPCoop .

Quick StartSupponendo che si desideri utilizzare una configurazione della Porta di Dominio in modalità XML è necessario installare nelladirectory di configurazione (per default /etc/openspcoop) il file config.xml presente nella directory example/pdd/config_file delladistribuzione. Tale file è predisposto per gli esempi inclusi nella distribuzione sorgente di OpenSPCoop e documentati nellaGuida Utente XML

3.2.5.1 Installazione Configurazione XML

All’interno della distribuzione sorgente, in deploy/pdd/config_file/config.xml.blank, è disponibile una configurazione XML ini-ziale. Questa configurazione non contiene alcun oggetto di integrazione (porte delegate, porte applicative, servizi applicativi)e indirizza un registro dei servizi XML che suppone si trovi nel path /etc/openspcoop/registroServizi.xml. Deve quindi esseremodificato il file xml se si desidera impostare un registro dei servizi di diverso tipo (vedi Sezione 4) o disponibile in un path delfile system diverso. Il file xml deve essere copiato nella directory di configurazione della porta di dominio OpenSPCoop (Default/etc/openspcoop, vedi Sezione 3.3.1).

Una volta copiato il file xml all’interno della directory di configurazione della porta di dominio OpenSPCoop, deve essereindicato di utilizzare la tipologia di configurazione XML all’interno dell’archivio OpenSPCoop (file openspcoop.properties)come descritto in Sezione 3.3.1.1.

La configurazione XML della Porta di Dominio è documentata nella Guida Utente XML . Un esempio di configurazione xml,con configurazioni pre-installate necessarie per utilizzare gli esempi descritti nella Guida Utente XML , è disponibile nelladistribuzione in example/pdd/config_file/config.xml.

3.2.5.2 Installazione Configurazione DB

La configurazione della Porta di Dominio su Database richiede l’installazione di un database relazionale nel quale devono essereregistrate le tabelle che conterranno gli elementi di configurazione. Tale database differisce a seconda del tipo di interfaccia digestione che gli si vuole associare:

http://www.openspcoop.org/openspcoop_v3/jsp?sel=doc-file&guida=manualexml&rel=1.4&id=index.html

http://www.openspcoop.org/openspcoop_v3/jsp?sel=doc-file&guida=utente&rel=1.4&id=index.html





6 / 84

• Interfaccia PDDConsole con Registro dei Servizi locale, permette di gestire sia gli elementi di integrazione della Porta diDominio che un registro dei servizi integrato. Le tabelle SQL richieste da questo tipo di interfaccia si trovano nella distribu-zione all’interno del file tools/web_interfaces/control_station/deploy/sql/TIPO_DATABASE/single_pdd/PddConsole.sql. Perulteriori dettagli sulla creazione del database vedi Sezione 5.1.

• Interfaccia PDDConsole con Registro dei Servizi centralizzato, permette di gestire solo elementi di integrazione della Portadi Dominio. Le tabelle SQL richieste da questo tipo di interfaccia si trovano nella distribuzione all’interno del file tools/-web_interfaces/pdd/deploy/sql/TIPO_DATABASE/ConfigurazionePdD.sql. Per ulteriori dettagli sulla creazione del databasevedi Sezione 5.2.

Una volta creato il database per l’interfaccia desiderata, deve essere indicato di utilizzare la tipologia di configurazione basata suDBMS all’interno dell’archivio OpenSPCoop (file openspcoop.properties) come descritto in Sezione 3.3.1.1.

La configurazione DB della Porta di Dominio è documentata nella Guida Utente della Porta di Dominio OpenSPCoop . Esempidi utilizzo di questa tipologia di configurazione sono disponibili anche nel Tutorial della Porta di Dominio OpenSPCoop .

3.2.6 Configurazione Iniziale del Registro dei Servizi

La Porta di Dominio richiede per poter funzionare l’installazione di una tipologia di Registro dei Servizi.

Esistono diverse tipologie di registro dei servizi (vedi Sezione 4), i seguenti sono consultabili a run-time dalla Porta di DominioOpenSPCoop:

• Registro dei Servizi XML, il registro è realizzato tramite un singolo file xml. Questa versione è perfettamente funzionale, e piùsemplice da gestire, in scenari non molto dinamici e con un basso numero di soggetti e servizi. È il modo migliore di usareOpenSPCoop in ambiente di testing e di sviluppo, mentre non si addice in ambienti reali. La configurazione XML del Registrodei Servizi è documentata nella Guida Utente XML .

• Registro dei Servizi DB, il registro è realizzato come un database relazionale. Si addice per ambienti reali dove gli scenaripossono essere dinamici e il numero di soggetti e servizi da gestire risulta elevato. Infatti in questo caso il registro può esseregestito tramite un’interfaccia web in maniera integrata alla configurazione della PdD (Sezione 5) oppure con un’interfacciaweb di gestione dedicata (Sezione 4.1). La configurazione DB del registro dei servizi è documentata nella Guida Utente dellaPorta di Dominio OpenSPCoop .

• Registro dei Servizi WEB, il registro è realizzato come un sito web che mantiene un insieme di oggetti descritti in xml eaccessibili via http (Registro dei Servizi HTTP ); questo registro può essere gestito tramite l’interfaccia web di gestione delRegistro (Sezione 4.1) e tramite l’interfaccia di gestione centralizzata di un dominio SPCoop (Sezione 6).

• Registro dei Servizi WS, i registri di OpenSPCoop possono essere interrogati attraverso un’interfaccia WebService (InterfacciaWS per il Registro dei Servizi ). L’interfaccia espone tramite WebServices uno qualsiasi dei tipi di registri descritti in questoelenco.

Quick StartSupponendo che si desideri utilizzare un registro dei servizi in modalità XML è necessario installare nella directory di configura-zione (per default /etc/openspcoop) il file registroServizi.xml presente nella directory example/pdd/config_file della distribuzione.Tale file è predisposto per gli esempi inclusi nella distribuzione sorgente di OpenSPCoop e documentati nella Guida UtenteXML

Di seguito vengono riportate le indicazioni su come indicare le informazioni di accesso ad un registro dei servizi di OpenSPCoopall’interno delle due tipologie di configurazione disponibili per la Porta di Dominio OpenSPCoop. Per l’installazioni di unatipologia di Registro dei Servizi si rimanda alla sezione Sezione 4.

• Configurazione XML, le indicazioni sul registro dei servizi devono essere impostate nell’elemento XML accesso-registro pre-sente all’interno del root element configurazione. Di seguito si riporta un esempio di configurazione xml che indica alla Portadi Dominio di accedere ad un registro dei servizi di tipo XML disponibile al path /etc/openspcoop/registroServizi.xml:


http://www.openspcoop.org/openspcoop_v3/jsp?sel=doc-file&guida=tutorial&rel=1.4&id=index.html




http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=registro&rel=1.4&id=ar01s02.html






7 / 84

<openspcoop xmlns="http://www.openspcoop.org/dao/config" xmlns:xsi="http://www.w3.org ←↩/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openspcoop.org/dao/config ←↩config.xsd">

....

<configurazione>

<accesso-registro><registro nome="RegistroXML" tipo="xml" location="/etc/openspcoop/ ←↩

registroServizi.xml" /></accesso-registro>

....

</configurazione>

</openspcoop>

Per ulteriori indicazioni è possibile consultare Guida Utente XML: Accesso al Registro dei Servizi

• Configurazione DBMS, il riferimento al registro dei servizi deve essere indicato nella sezione Configurazione -> Generale ->Registro dei Servizi (visualizza) -> Elenco registri -> Aggiungi.

Le seguenti immagini mostrano un esempio di utilizzo dell’interfaccia PdDConsole (Sezione 5) nel quale viene registrato un re-gistro dei servizi di tipo DB accessibile tramite un datasource (registrato nell’albero JNDI), con nome org.openspcoop.dataSource.registroServizi

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s03.html#accessoRegServ


8 / 84

Figura 1: Menù di Configurazione della Porta di Dominio OpenSPCoop

Figura 2: Configurazione per l’accesso ad un Registro dei Servizi

Per ulteriori indicazioni è possibile consultare Guida Utente della Porta di Dominio, Funzionalità avanzate: Registro

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=utente&rel=1.4&id=ar01s05.html#id2776577


9 / 84

3.2.7 Deploy del Software

Per il deploy della versione J2EE è sufficiente copiare il file dist/OpenSPCoop.ear nella directory di deploy dell’applicationserver: JBOSS_DIR/server/ISTANZA/deploy (es. /var/lib/jbossas/server/default/deploy).

Per il deploy della versione ServletContainer è sufficiente copiare il file dist/openspcoop.war nella directory di deploy del servletcontainer: TOMCAT_DIR/webapps (es. /var/lib/tomcat5/webapps).

Nel log del server e in /var/openspcoop/log/openspcoop.log, se il deploy è andato a buon fine deve comparire un messaggiosimile al seguente:

Porta di Dominio OpenSPCoop v1.4 avviata correttamente in 5 secondi

Una volta effettuato il deploy, saranno disponibili tre servizi web che rappresentano i punti di ingresso alla PdD OpenSP-Coop, rispettivamente per la ricezione di contenuti applicativi, per la ricezione di buste e-Gov e per i servizi di integrazione(IntegrationManager). Questi 3 servizi saranno rispettivamente accessibili agli indirizzi:

• http://localhost:8080/openspcoop/PD

• http://localhost:8080/openspcoop/PA

• http://localhost:8080/openspcoop/IntegrationManager

3.3 Configurazione

La Distribuzione della Porta di Dominio OpenSPCoop è preconfigurata per l’uso più comune, in linea con le indicazioni dellaGuida Utente XML . Il prodotto è tuttavia altamente configurabile agendo sui file di proprietà presenti all’interno dell’archivio(OpenSPCoop.ear/properties per la versione J2EE o openspcoop.war/WEB-INF/classes per la versione ServletContainer.

In questa sezione verrano descritti alcuni aspetti di configurazione avanzata riguardanti:

• Aspetti di Configurazione Generale

• Logging

• Personalizzazione dei componenti della Porta di Dominio

• Interoperabilità rispetto ad altre implementazioni di Porta di Dominio

3.3.1 Aspetti di Configurazione Generale

La Porta di Dominio è configurabile, su molte funzionalità, tramite il file openspcoop.properties. Il file contiene proprietà cheinteressano i più svariati aspetti di funzionamento della Porta di Dominio. Di seguito vengono riportato solo alcune proprietà dicarattere generale; tutte le altre sono state organizzate in sotto-sezioni riguardanti ognuna un argomento che le racchiude.

• org.openspcoop.pdd.confDirectory, indica la directory di configurazione della porta di dominio OpenSPCoop. (Default: /et-c/openspcoop). Nella directory indicata nella proprietà dovranno essere inserite la configurazione della PdD e/o il registrodei servizi, entrambi in formato xml. Per ulteriori dettagli sulle configurazioni xml si rimanda alle sezioni Sezione 3.2.5 eSezione 4.

• org.openspcoop.pdd.server, indica la tipologia di server su cui viene installata la Porta di Dominio.

– j2ee, il server è un application server J2EE. Contiene sia un WebContainer che un EJBContainer. Con questo tipo di serverè possibile sfruttare tutte le potenzialità della Porta di Dominio (Verranno utilizzate code JMS, MDB, EJB Timer e il serverJMX)

– web, il server è un WebContainer (es. Tomcat). Con questo tipo di server, i profili di collaborazione saranno gestiti solo inmodalità stateless (vedi Sezione 3.3.1.12)

• org.openspcoop.pdd.identificativoPorta, indica l’identità di default della Porta di Dominio (utile in modalità multi-soggetti).Devono essere indicati i seguenti parametri:



10 / 84

– org.openspcoop.pdd.identificativoPorta.dominio, identificativo di dominio del soggetto di default (default: OpenSPCoop-SPCoopIT).

– org.openspcoop.pdd.identificativoPorta.nome, nome del soggetto di default (default: OpenSPCoop)

– org.openspcoop.pdd.identificativoPorta.tipo, tipo del soggetto di default (default: SPC)

3.3.1.1 Accesso alla Configurazione della Porta di Dominio

Le proprietà org.openspcoop.pdd.config.*, indicano come accedere alla configurazione della Porta di Dominio OpenSPCoopSezione 3.2.5.

Il tipo di configurazione della porta di dominio viene indicato dalla voce org.openspcoop.pdd.config.tipo; attualmente OpenSP-Coop dispone di due tipi di configurazioni:

1. xml: viene fornita attraverso un file XML (vedi Guida Utente XML: Configurazione PdD ). L’informazione su comereperire la configurazione deve essere definita attraverso la voce org.openspcoop.pdd.config.location, specificando il pathnel fileSystem, in caso di un file XML locale (es. /etc/openspcoop/config.xml), o una url, nel caso di file XML remoto (eshttp://repository/config.xml).

2. db: viene fornita attraverso un database SQL. L’informazione su come reperire il database deve essere definita attraversola voce org.openspcoop.pdd.config.location, specificando il nome di un dataSource registrato nell’albero JNDI dell’ap-plication server. Il dataSource viene utilizzato da OpenSPCoop per accedere alle tabelle descritte in Sezione 5.1.2.1 oSezione 5.2.2.1 (a seconda della PddConsole scelta). È possibile fornire informazioni di contesto per la ricerca del data-Source, attraverso una o più voci org.openspcoop.pdd.config.property.*, tramite la definizione di coppie nome/valore doveil nome viene preso al posto del carattere speciale *.

La distribuzione di OpenSPCoop, per default, definisce come tipo di configurazione quella xml e assume che il file xml riesiedanel path /etc/openspcoop/config.xml

L’accesso alla configurazione, soprattutto in caso di configurazione su database, può risultare oneroso. Per limitare gli accessi allaconfigurazione da parte della Porta di Dominio è possibile anteporre alla configurazione un meccanismo di cache configurabiletramite le seguenti voci:

• org.openspcoop.pdd.config.cache.enable, permette di abilitare/disabilitare (true/false) la cache.

• org.openspcoop.pdd.config.cache.dimensione, permette di impostare la dimensione della cache.

• org.openspcoop.pdd.config.cache.algoritmo, permette di impostare l’algoritmo utilizzato con la cache (LRU/MRU).

• org.openspcoop.pdd.config.cache.itemIdleTime, indica il massimo intervallo di tempo (in secondi) che un oggetto in cache puòesistere senza essere acceduto.

• org.openspcoop.pdd.config.cache.itemLifeSecond, permette di impostare la vita (in secondi) di un oggetto inserito in cache.

La distribuzione di OpenSPCoop, per default, abilita il meccanismo di cache sulla configurazione della Porta di Dominio.

La configurazione della Porta di Dominio comprende due macro aree, una riguardante i componenti di integrazione (portedelegate, porte applicative, servizi applicativi), ed una riguardante aspetti puri di configurazione della porta di dominio (perulteriori dettagli vedi Guida Utente della Porta di Dominio OpenSPCoop o Guida Utente XML: Configurazione PdD ). Mentrenella prima macro-area, è necessario avere un meccanismo di refresh delle informazioni mantenute in cache (in seguito allacreazione/cancellazione frequente di elementi di integrazione), nella seconda area è accettabile anche associare alla porta didominio un comportamento per il quale legge le informazioni di configurazioni solo una volta all’avvio, e le mantiene finoal prossimo riavvio. La proprietà org.openspcoop.pdd.config.refresh, permette di impostare proprio questo comportamento:l’accesso alle informazioni presenti nell’area di configurazione può avvenire staticamente (valore false) o dinamicamente (valoretrue). Se la configurazione è dinamica, le informazioni vengono rilette dalla configurazione, in caso di refresh (o cache scaduta).Se la configurazione è statica, le informazioni vengono lette solo una volta all’avvio dell’Application Server. La distribuzione diOpenSPCoop, per default, abilita il refresh.

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s03.html

http://www.openspcoop.org/openspcoop/jsp/?sel=doc-file&guida=utente&rel=1.4&id=index.html

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s03.html


11 / 84

3.3.1.2 Accesso al Registro dei Servizi

Tramite la proprietà org.openspcoop.registroServizi.readObjectStatoBozza (Default: false) è possibile configurare la porta didominio in modo da utilizzare o ignorare accordi di servizio, accordi di cooperazione, servizi spcoop e fruzioni in uno stato dibozza.

3.3.1.3 Accesso al DBMS dei messaggi

L’accesso al database dei messaggi di OpenSPCoop (vedi Sezione 3.2.3), viene definito indicando tramite la voce org.openspcoop.pdd.dataSourceil nome jndi di un dataSource registrato nell’albero JNDI dell’A.S. È possibile fornire informazioni di contesto per la ri-cerca del dataSource, attraverso una o più voci org.openspcoop.pdd.dataSource.property.*, tramite la definizione di coppienome/valore dove il nome viene preso al posto del carattere speciale *. (Default: dataSource=org.openspcoop.dataSource edataSource.property non definite).

La voce org.openspcoop.pdd.repository.tipoDatabase (Opzionale) permette di impostare il tipo di database utilizzato. Questavoce permette di avere ottimizzazioni sul codice SQL utilizzato dalla Porta di Dominio.

La voce org.openspcoop.pdd.repository.forceIndex (Default false) permette di creare queries SQL per ricerche sul database deimessaggi che forzano l’uso di indici.

La voce org.openspcoop.pdd.repository.timer definisce l’intervallo (in secondi) con cui i timer appositi (vedi Sezione 3.3.1.6)scandiscono il repository in cerca di messaggi da eliminare poiché gestiti completamente dalla Porta di Dominio o perché scaduti.L’intervallo di scadenza (in minuti) di un messaggio viene definito attraverso la voce org.openspcoop.pdd.repository.scadenzaMessaggio(Default timer=10 e scadenzaMessaggio=7200).

I messaggi che transitano sulla Porta di Dominio, vengono mantenuti nel repository dei messaggi. Esistono due tipologie differen-ti di repository, impostabili tramite la proprietà org.openspcoop.pdd.repository (Default: tipo=fs, directory=/var/openspcoop/msgRepository):

1. fs: il repository viene mantenuto su fileSystem all’interno di una directory indicata attraverso la proprietà org.openspcoop.pdd.repository.directory.

2. db: il repository viene mantenuto su db (Tabella DEFINIZIONE_MESSAGGI, vedi Sezione 3.2.3). In questo contesto,il tipo di salvataggio/lettura dei messaggi (byte[]) dal db varia a seconda del tipo di adapterJDBC indicato nella proprietàorg.openspcoop.pdd.repository.jdbcAdapter:

• default, setDati e getDati effettuate attraverso i metodi JDBC PreparedStatement.setBytes() ResultSet.getBytes().

• bytes, setDati e getDati effettuate attraverso i metodi JDBC PreparedStatement.setBytes() ResultSet.getBytes().

• stream, setDati e getDati effettuate attraverso i metodi JDBC PreparedStatement.setBinaryStream() ResultSet.getBinaryStream().

• blob, setDati e getDati effettuate attraverso i metodi JDBC PreparedStatement.setByes() ResultSet.getBlob().

Notale keyword utilizzate per la definizione di un JDBC adapter sono definite all’interno del file classNa-me.properties descritto nel seguito di questo paragrafo, e precisano la classe che implementa l’interfacciaorg.openspcoop.core.jdbc.IJDBCAdapter. È possibile fornire adapter personalizzati, semplicemente definendo una op-portuna classe che implementa l’interfaccia JDBCAdapter e registrandola all’interno del file className.properties (vediSezione 3.3.3).

Il repository dei messaggi, oltre a contenere i messaggi in transito sulla porta di dominio, raccoglie anche le buste e-Gov. La se-guente opzione influenza proprio il repository dedicato alle buste e-Gov. La Porta di Dominio oltre a filtrare le buste eGov scadute(rispetto all’elemento ’Scadenza’ della busta e-Gov), può controllare che le buste contengano nell’elemento ’ora-registrazione’una data che non sia scaduta rispetto al parametro indicato nella proprietà org.openspcoop.pdd.repository.scadenzaMessaggio de-scritta in precedenza in questo paragrafo. Questo tipo di controllo è attivabile tramite la proprietà org.openspcoop.pdd.repository.scadenzaMessaggio.filtraBusteEGovScaduteRispettoOraRegistrazione(true/false, default: true). Se il controllo è attivato anche le buste che possiedono un’elemento ’ora-registrazione’ scaduto, ven-gono scartate tramite un messaggio SPCoop Errore, con eccezione che segnala la busta scaduta, così come viene effettivamentefatto se la busta porta nell’header la data di scadenza (elemento ’scadenza’) scaduta.


12 / 84

NotaL’abilitazione o meno di questo controllo influenza il meccanismo di pulizia del repository delle buste e-Gov. Se il controllo vienedisabilitato, le informazioni per effettuare il filtro duplicati vengono mantenute all’infinito, poichè una stessa busta (stesso id e-Gov) può essere gestita dalla Porta di Dominio in un qualsiasi momento, anche anni dopo! Come conseguenza sarà necessariauna manutenzione sistemistica del database per prevenire una crescita del database che comporta un esaurimento di risorse.In definitiva la disabilitazione di questo controllo, abilitato per default, è fortemente sconsigliato.

Le voci org.openspcoop.pdd.repository.messaggioInProcessamento.attesaAttiva e org.openspcoop.pdd.repository.messaggioInProcessamento.checkpermettono rispettivamente di configurare l’attesa attiva, in secondi, effettuata per il completamento dei messaggi precedente-mente già ricevuti (es. buste con stesso id egov) e l’intervallo in millisecondi tra un check e l’altro durante l’attesa attiva. Questiparametri influenzano la gestione dei messaggi già in processamento, che vengono gestiti attraverso una modalità asincrona(profilo oneway o profili asincroni con ricevuta disabilitata).

org.openspcoop.pdd.repository.messaggioAsincronoInProcessamento, la risposta asincrona simmetrica, o la richiesta-stato asin-crona asimmetrica deve essere gestita dal servizio di RicezioneBusteEGov, solo se la precedente richiesta o ricevuta alla ri-chiesta non risulti ancora in processamento nella porta di dominio. Se arriva una risposta/richiestaStato mentre la prece-dente richiesta/ricevutaRichiesta è ancora in gestione, il servizio effettua una attesa attiva configurabile attraverso i parametriorg.openspcoop.pdd.repository.messaggioAsincronoInProcessamento.attesaAttiva e org.openspcoop.pdd.repository.messaggioAsincronoInProcessamento.check

org.openspcoop.pdd.repository.gestoreMessaggi.cache.* permette di anteporre una cache per ottimizzare le performance dellaporta di dominio per quanto riguarda la gestione dei messaggi, effettuata dai moduli dell’infrastruttura di OpenSPCoop, basatasu moduli attivati a catena tramite code JMS (vedi Sezione 3.3.1.16):

• Risoluzione del mapping tra riferimenti messaggi e id e-Gov. Il mapping viene effettuato per localizzare buste e-Gov cheriferiscono altre buste attraverso un riferimento messaggio.

• Algoritmo di Transaction Manager che permette il corretto passaggio della gestione dei messaggi tra i moduli funzionalidell’architettura di OpenSPCoop.

NotaUna cache per la gestione dei messaggi è utile solo se la PdD OpenSPCoop viene distribuita sotto forma di archivio J2EEOpenSPCoop.ear e quindi utilizza le code fornite da un broker JMS. Se si è installato la versione per Servlet Container (Tom-cat) o se si utilizzano i profili di collaborazione in modalità stateless (vedi Sezione 3.3.1.12) le proprietà descritte di seguito,riguardanti la cache, non hanno effetto.

Una cache permetterà di avere maggiori prestazioni. La configurazione della cache avviene attraverso le seguenti voci:

• org.openspcoop.pdd.repository.gestoreMessaggi.cache.enable, permette di abilitare/disabilitare (true/false) la cache.

• org.openspcoop.pdd.repository.gestoreMessaggi.cache.dimensione, permette di impostare la dimensione della cache.

• org.openspcoop.pdd.repository.gestoreMessaggi.cache.algoritmo, permette di impostare l’algoritmo utilizzato con la cache(LRU/MRU).

• org.openspcoop.pdd.repository.gestoreMessaggi.cache.itemIdleTime, indica il massimo intervallo di tempo, in secondi, che unelemento può esistere senza essere acceduto.

• org.openspcoop.pdd.repository.gestoreMessaggi.cache.itemLifeSecond, permette di impostare la vita, in secondi, di un ele-mento inserito in cache.

(Default: config.cache.enable=false)


13 / 84

3.3.1.4 Accesso al broker JMS

NotaSolo la PdD OpenSPCoop distribuita sotto forma di archivio J2EE OpenSPCoop.ear utilizza le code fornite da un broker JMS.Se si è installato la versione per Servlet Container (Tomcat) le proprietà descritte in questo paragrafo non hanno effetto.

L’accesso al broker JMS viene indicato tramite la proprietà org.openspcoop.pdd.queueConnectionFactory che indica il nome jndiutilizzato da OpenSPCoop per accedere ad un pool di connessioni jms registrato nell’albero JNDI dell’A.S. Il pool permetterà dicreare connessioni verso il broker JMS sul quale sono presenti le code descritte in Sezione 3.2.2. È possibile fornire informazionidi contesto per la ricerca del pool di connessioni, attraverso una o più voci org.openspcoop.pdd.queueConnectionFactory.property.*,tramite la definizione di coppie nome/valore dove il nome viene preso al posto del carattere speciale *. (Default: org.openspcoop.jmsPoole queueConnectionFactory.property non definite). È possibile anche indicare il tipo di Acknowledge utilizzato con la sessioneJMS attraverso la proprietà org.openspcoop.pdd.queueConnectionFactory.session.AcknowledgeMode (Default: AUTO_ACKNOWLEDGE).

Le code JMS descritte in Sezione 3.2.2 vengono accedute grazie alle informazioni descritte nelle voci org.openspcoop.pdd.queue..*che indicano i loro nomi JNDI. Le voci indicanti le code sono le seguenti:

• org.openspcoop.pdd.queue.ricezioneContenutiApplicativi, coda del modulo RicezioneContenutiApplicativi che si occupa digestire le richieste di servizio effettuate dai servizi applicativi.

• org.openspcoop.pdd.queue.ricezioneBusteEGov, coda del modulo RicezioneBusteEGov che si occupa di gestire le buste eGovinviate da altre Porte di Dominio.

• org.openspcoop.pdd.queue.inoltroBusteEGov, coda del modulo InoltroBuste eGov che si occupa di inoltrare buste eGov pro-dotte dalla PdD verso altre Porte di Dominio.

• org.openspcoop.pdd.queue.inoltroRisposteEGov, coda del modulo InoltroRisposte eGov che si occupa di gestire eventualibuste eGov di risposta da inoltrare su nuove connessioni http.

• org.openspcoop.pdd.queue.consegnaContenutiApplicativi, coda del modulo ConsegnaContenutiApplicativi che si occupa diinvocare i servizi applicativi erogatori, in seguito all’arrivo di buste eGov.

• org.openspcoop.pdd.queue.imbustamento, coda del modulo Imbustamento che si occupa della creazione di un header eGov perbuste in uscita.

• org.openspcoop.pdd.queue.imbustamentoRisposte, coda del modulo ImbustamentoRisposte che si occupa della creazione di unheader eGov per buste contenenti risposte applicative.

• org.openspcoop.pdd.queue.sbustamento, coda del modulo Sbustamento che si occupa dello sbustamento/gestione dell’headereGov presente nelle buste ricevute.

• org.openspcoop.pdd.queue.sbustamentoRisposte, coda del modulo SbustamentoRisposte che si occupa dello sbustamento/ge-stione dell’header eGov presente nelle buste ricevute in una connection-reply.

È possibile fornire informazioni di contesto per la ricerca delle code jms descritte in Sezione 3.2.2, attraverso una o più vociorg.openspcoop.pdd.queue.property.*, tramite la definizione di coppie nome/valore dove il nome viene preso al posto del caratterespeciale *. (Default: non definite).

3.3.1.5 Configurazione HTTP

Di seguito vengono descritti i parametri di configurazione http che influenzano sia le connessioni in uscita che le connessioni iningresso.

• Connessioni in uscita

Le seguenti proprietà influenzano le connessioni istanziate in fase di consegna ai servizi applicativi e in fase di inoltro dellebuste e-Gov:


14 / 84

– org.openspcoop.pdd.connettori.TIPO_MODULO_FUNZIONALE.connection.timeout, timeout in millisecondi per la crea-zione della connessione.

– org.openspcoop.pdd.connettori.TIPO_MODULO_FUNZIONALE.readConnection.timeout, timeout in millisecondi per lalettura della risposta dalla connessione.

– org.openspcoop.pdd.connettori.TIPO_MODULO_FUNZIONALE.httpTransferLength, tipo di transfer-length http utilizzatoper la spedizione dei messaggi soap (vedi Hypertext Transfer Protocol -- HTTP/1.1: Message Length ):

* content-length (default), viene impostato un header http Content-Length contenente un valore decimale rappresentante siala entity-length sia il transfer-length

* transfer-encoding-chunked, viene impostato un header http Transfer-Encoding con il valore chunked. Con questo tipo ditransfer-length è possibile indicare la dimensione in bytes di ogni singolo chunk tramite la proprietà org.openspcoop.pdd.connettori.TIPO_MODULO_FUNZIONALE.httpTransferLength.chunkLength(Opzionale)

I tipi di moduli funzionali configurabili sono:

– inoltroBusteEGov, connettore utilizzato per la spedizione di buste eGov tra porte di dominio

– consegnaContenutiApplicativi, connettore utilizzato per la spedizione di un contenuto applicativo dalla porta di dominio alservizio applicativo

• Connessioni in entrata

La seguente proprietà influenza le connessioni istanziate in fase di invocazione delle porte delegate da parte dei servizi applica-tivi e in fase di ricezione di buste e-Gov. La proprietà org.openspcoop.pdd.stateless.dataSource.rinegoziamentoConnessione,(default: abilitato) permette di configurare il rapporto tra connessioni HTTP e connessioni verso il database, per i thread cheagiscono in modalità stateless (vedi Sezione 3.3.1.12). Se si abilita il rinegoziamento della connessione, non vi è un vincolotra connessioni HTTP e connessioni sul DB e il numero di connessioni HTTP può essere tranquillamente maggiore. Se inveceil thread che gestisce una richiesta non rinegozia la connessione, vi è un vincolo 1-1 tra connessioni HTTP e connessioni sulDB e tale vincolo deve essere impostato a livello sistemistico nel sistema (nel server http e nel datasource).

Le proprietà org.openspcoop.pdd.services.TIPO_MODULO_FUNZIONALE.httpTransferLength permettono di indicare il ti-po di transfer-length http utilizzato per la spedizione dei messaggi soap di risposta sulla connessione http (vedi HypertextTransfer Protocol -- HTTP/1.1: Message Length ):

– content-length (default), viene impostato un header http Content-Length contenente un valore decimale rappresentante sia laentity-length sia il transfer-length

– transfer-encoding-chunked, viene impostato un header http Transfer-Encoding con il valore chunked

– webserver-default, non viene aggiunto alcun header http a livello applicativo. La gestione del tipo di transfer-length vienelasciata decidere la web server

I tipi di moduli funzionali configurabili sono:

– ricezioneContenutiApplicativi, servizio di ricezione contenuti applicativi (Porta delegata)

– ricezioneBusteEGov, servizio di ricezione buste e-Gov (Porta applicativa)

E’ inoltre possibile personalizzare la gestione dell’header SOAPAction. Il WS-I Basic profile 1.1 (Basic Profile Version 1.1:SOAPAction_HTTP_Header ) indica che per incrementare l’interoperabilita’ tra le implementazioni ws, sia importante utiliz-zare soap action quotate. Anche se il protocollo HTTP permette header con valori non quotati, alcune implementazioni SOAPrichiedono che la SOAPAction header sia quotata. Le regole fissate dal profilo WS-I sono:

• R1109 The value of the SOAPAction HTTP header field in a HTTP request MESSAGE MUST be a quoted string.

• R1119 A RECEIVER MAY respond with a fault if the value of the SOAPAction HTTP header field in a message is not quoted.

Per configurare la Porte di Dominio in modalità compatibile con il WS-I Basic Profile è possibile agire sulle seguenti proprietà:

• org.openspcoop.pdd.services.ricezioneContenutiApplicativi.soapAction.checkQuotedString

• org.openspcoop.pdd.services.ricezioneBusteEGov.soapAction.checkQuotedString

Se si abilitano le opzioni (disabilitate per default), la Porta di Dominio accettera’ solo richieste http con un header http SOAPAc-tion con valore quotato.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4



http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#SOAPAction_HTTP_Header

http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#SOAPAction_HTTP_Header


15 / 84

3.3.1.6 Configurazione dei Timer

La porta di dominio OpenSPCoop affida diverse funzionalità, sia di controllo di consistenza dei dati che di controllo di reperibilitàdelle risorse, a thread schedulati che girano ad intervalli di tempo preconfigurati.

• Controllo di consistenza dei dati del Repository dei Messaggi

I controlli sulla consistenza dei dati vengono gestiti tramite EJB Timers se la PdD OpenSPCoop viene distributa sotto formadi archivio J2EE OpenSPCoop.ear o tramite semplici thread se la PdD viene distribuita come archivio per ServletContaineropenspcoop.war.

– Timer GestoreBusteNonRiscontrate, configurabile tramite le proprietà org.openspcoop.pdd.timer.gestoreBusteNonRiscontrate.*,si occupa di gestire le buste OneWay non riscontrate e le buste asincrone di cui non è stata riscontrata una ricevuta.Attraverso la voce org.openspcoop.pdd.timer.gestoreBusteNonRiscontrate.enable è possibile attivare/disattivare (true/false,default:true) il seguente timer.Attraverso la voce org.openspcoop.pdd.timer.gestoreBusteNonRiscontrate.logQuery è possibile attivare/disattivare (true/fal-se, default:false) i log delle query effettuate dal seguente timer.La proprietà org.openspcoop.pdd.timer.gestoreBusteNonRiscontrate indica il nome JNDI dell’EJB Timer. Proprietà inter-pretata dalla PdD solo in caso di deploy in ambiente J2EE.

– Timer GestoreMessaggi, configurabile tramite le proprietà org.openspcoop.pdd.timer.gestoreMessaggi.*, si occupa pulizia,dal repository, dei messaggi non più utilizzati dalla PdD o scaduti.Attraverso la voce org.openspcoop.pdd.timer.gestoreMessaggi.enable è possibile attivare/disattivare (true/false, default:true)il seguente timer.Attraverso la voce org.openspcoop.pdd.timer.gestoreMessaggi.logQuery è possibile attivare/disattivare (true/false, default:false)i log delle query effettuate dal seguente timer.La proprietà org.openspcoop.pdd.timer.gestoreMessaggi indica il nome JNDI dell’EJB Timer. Proprietà interpretata dallaPdD solo in caso di deploy in ambiente J2EE.

– Timer Consistenza Messaggi, configurabile tramite le proprietà org.openspcoop.pdd.timer.gestorePuliziaMessaggiAnomali.*,si occupa di gestire le inconsistenze presenti nel database.Attraverso la voce org.openspcoop.pdd.timer.gestorePuliziaMessaggiAnomali.enable è possibile attivare/disattivare (true/-false, default:true) il seguente timer.Attraverso la voce org.openspcoop.pdd.timer.gestorePuliziaMessaggiAnomali.logQuery è possibile attivare/disattivare (true/-false, default:false) i log delle query effettuate dal seguente timer.La proprietà org.openspcoop.pdd.timer.gestorePuliziaMessaggiAnomali indica il nome JNDI dell’EJB Timer. Proprietàinterpretata dalla PdD solo in caso di deploy in ambiente J2EE.

– Timer Repository EGov, configurabile tramite le proprietà org.openspcoop.pdd.timer.gestoreRepositoryEGov.*, si occupadi gestire la pulizia del repository delle buste e-Gov.Attraverso la voce org.openspcoop.pdd.timer.gestoreRepositoryEGov.enable è possibile attivare/disattivare (true/false, de-fault:true) il seguente timer.Attraverso la voce org.openspcoop.pdd.timer.gestoreRepositoryEGov.logQuery è possibile attivare/disattivare (true/false,default:false) i log delle query effettuate dal seguente timer.La proprietà org.openspcoop.pdd.timer.gestoreRepositoryEGov indica il nome JNDI dell’EJB Timer. Proprietà interpretatadalla PdD solo in caso di deploy in ambiente J2EE.

In caso di ambiente J2EE è possibile fornire informazioni di contesto per la ricerca JNDI dei timer, attraverso una o piùvoci org.openspcoop.pdd.timer.property.* , con lo scopo di definire coppie nome/valore dove il nome viene preso al posto delcarattere speciale *. (Default: non definite).

L’intervallo di tempo (in secondi) con cui i timer vengono schedulati viene definito dalla proprietà org.openspcoop.pdd.repository.timer.

• Controllo delle risorse utilizzate dalla Porta di Dominio

Oltre ai controlli di consistenza del repository dei messaggi, è possibile anche attivare controlli sulle risorse utilizzate dallaporta di dominio. I controlli sulle risorse di sistema sono attivabili tramite le voci org.openspcoop.pdd.risorse.check.*. Lerisorse che possono essere monitorate sono:

– database dei messaggi della porta di dominio, controllo attivabile tramite l’opzione org.openspcoop.pdd.risorse.check.db,verifica che sia possibile istanziare ed utilizzare connessioni verso il database


16 / 84

– broker JMS, controllo attivabile tramite l’opzione org.openspcoop.pdd.risorse.check.jms, verifica che sia possibile istanziareed utilizzare connessioni e sessioni verso il broker JMS

– configurazione della porta di dominio, controllo attivabile tramite l’opzione org.openspcoop.pdd.risorse.check.configurazione,verifica che sia accessibile la configurazione della Porta di Dominio (controlli differenti a seconda del tipo di configurazioneistanziata); inoltre tramite la proprietà org.openspcoop.pdd.risorse.check.configurazione.validazioneSemantica è possibileassociare al controllo anche una validazione semantica della configurazione (per ulteriori dettagli vedi Sezione 3.3.1.8)

– accesso al registro dei servizi, controllo attivabile tramite l’opzione org.openspcoop.pdd.risorse.check.registri, verifica chesia accessibile il registro dei servizi (controlli differenti a secondo del tipo di configurazione istanziata); esistono duetipologie per il controllo della raggiungibilità del registro (proprietà org.openspcoop.pdd.risorse.check.registri.tipo):

* tutti, l’allarme viene lanciato se non esiste nemmeno un registro raggiungibile

* singolo, l’allarme viene lanciato non appena uno dei registri configurati non risulta accessibile

inoltre tramite la proprietà org.openspcoop.pdd.risorse.check.registri.validazioneSemantica è possibile associare al controlloanche una validazione semantica del registro dei servizi (per ulteriori dettagli vedi Sezione 3.3.1.8)

– tracciamenti personalizzati, controllo attivabile tramite l’opzione org.openspcoop.pdd.risorse.check.tracciamento, verificache siano accessibili le risorse impiegate per i tracciamenti personalizzati in uso sulla Porta di Dominio

– messaggi diagnostici personalizzati, controllo attivabile tramite l’opzione org.openspcoop.pdd.risorse.check.msgdiagnostici,verifica che siano accessibili le risorse impiegate dai messaggi diagnostici personalizzati in uso sulla Porta di Dominio

L’intervallo di tempo (in secondi) con cui i controlli vengono schedulati è impostabile tramite l’opzione org.openspcoop.pdd.risorse.checkInterval.

• Controlli personalizzati delle risorse utilizzate dalla Porta di Dominio

Infine è possibile fornire controlli personalizzabili sulla disponibilità di risorse per la gestione di ulteriori richieste applicativee/o buste eGov, tramite le voci org.openspcoop.pdd.repository.threshold.*. Tramite la voce org.openspcoop.pdd.repository.threshold.tipi(Opzionale) è possibile elencare diversi tipi di controlli da effettuare. Ogni tipo indica il nome di una classe, registrata in clas-sName.properties, che implementa l’interfaccia org.openspcoop.pdd.core.threshold.IThreshold.java (vedi Sezione 3.3.3.11). Èpossibile fornire i parametri di soglia per ogni controllo attraverso la voce org.openspcoop.pdd.repository.threshold.TIPO_THRESHOLD.value.

L’intervallo di tempo (in secondi) con cui i controlli vengono schedulati è impostabile tramite l’opzione org.openspcoop.pdd.repository.threshold.checkInterval.

Attualmente vengono forniti i controlli per i seguenti database:

– mysql, controlla se la dimensione del table space per i database di mysql scende sotto una determinata soglia. Il controllo èregistrato con tipo mysqlFreeSpace.

– postgresql, verifica lo spazio disco occupato attualmente da tutti i database di postgres, controllando che non venga superatoil valore di soglia indicato. Il valore che viene passato al controllo puo essere del tipo valore_soglia[;nome_datasource]. Senome datasource non è indicato verrà utilizzata la connessione verso il database openspcoop. Il valore di soglia è interpretatoin byte a meno che non sia esplicitamente indicata l’unita di misura. Il controllo è registrato con tipo postgresUsedSpace.

3.3.1.7 Configurazione JMX

OpenSPCoop dispone di una gestione tramite console JMX di alcune sue risorse. È possibile attivare tale gestione attraversol’opzione org.openspcoop.pdd.core.jmx.enable (default: true). Gli MBean JMX utilizzabili permetteranno di gestire le seguentifunzionalità:

• type=AccessoRegistroServizi, gestione della cache utilizzata per i dati prelevati dal Registro dei Servizi

• type=AutorizzazioneSPCoop, gestione della cache utilizzata per i dati di autorizzazione SPCoop effettuata dal modulo Rice-zioneBusteEGov

• type=ConfigurazionePdD, gestione della configurazione della Porta di Dominio (livello di log, tracciamento, dump) e gestionedella cache utilizzata per i dati prelevati dalla configurazione

• type=MonitoraggioRisorse, permette di monitorare i messaggi in transito sulla Porta di Dominio e di vedere le risorse (data-base,jms) impegnate dalla porta

• type=RepositoryMessaggi, gestione della cache utilizzata per i dati dei messaggi in transito sulla Porta di Dominio


17 / 84

è possibile indicare Il nome JNDI del MBean Server da utilizzare per la registrazione dei MBean JMX attraverso l’opzioneorg.openspcoop.pdd.core.jmx.jndi.mbeanServer. È possibile fornire informazioni di contesto per la ricerca JNDI, attraverso unao più voci org.openspcoop.pdd.core.jmx.jndi.property.*, tramite la definizione di coppie nome/valore dove il nome viene presoal posto del carattere speciale *. (Default: MBeanServer e proprietà non definite).

3.3.1.8 Validazione Semantica della Configurazione e del Registro dei Servizi

OpenSPCoop dispone di un validatore semantico delle configurazioni. È possibile attivare il validatore tramite le seguentiopzioni:

• org.openspcoop.pdd.startup.config.xml.validazioneSemantica (default: abilitato), opzione utilizzata in caso di configurazionebasata su XML (vedi Sezione 3.2.5.1); se abilitata la validazione viene effettuata allo startup della PdD, e ogni qualvolta vienemodificato il file XML

• org.openspcoop.pdd.startup.config.validazioneSemantica (default: disabilitato), opzione utilizzata in caso di tipi di configu-razione non basati su XML (vedi Sezione 3.2.5.2); indica se abilitare o meno la validazione semantica; se abilitata, la va-lidazione viene effettuata allo startup della PdD e ad intervalli regolari se è stato attivato il timer apposito (vedi proprietàorg.openspcoop.pdd.risorse.check.configurazione.validazioneSemantica in Sezione 3.3.1.6)

• org.openspcoop.pdd.startup.registri.xml.validazioneSemantica (default: abilitato), opzione utilizzata in caso di registro deiservizi basato su XML Sezione 3.2.6; se abilitata, la validazione viene effettuata allo startup della PdD, e ogni qualvolta vienemodificato il file XML

• org.openspcoop.pdd.startup.registri.validazioneSemantica (default: disabilitato), opzione utilizzata nel caso di registri dei ser-vizi non basati su XML Sezione 3.2.6; indica se abilitare o meno la validazione semantica; se abilitata, la validazione viene ef-fettuata allo startup della PdD e ad intervalli regolari se è stato attivato il timer apposito (vedi proprietà org.openspcoop.pdd.risorse.check.registri.validazioneSemanticain Sezione 3.3.1.6)

• org.openspcoop.pdd.startup.registri.validazioneSemantica.checkURI (default: disabilitato), se abilitata viene effettuata la va-lidazione delle URI presenti nelle risorse definite nel registro dei servizi

NotaAll’interno della distribuzione, in tools/validator, viene fornito un validatore semantico della configurazione e del registro deiservizi utilizzabile tramite command line. Istruzioni su come utilizzare questo tool vengono fornite nella distribuzione indoc/validator.readme.

3.3.1.9 Integrazione dei Servizi Applicativi

L’integrazione dei servizi applicativi della Porta di Dominio è altamente personalizzabile. In questa sezione vengono descrittitutti gli aspetti personalizzabili per l’integrazione, dal protocollo SOAP (SOAPFault, Attachments) all’header di integrazione perlo scambio di informazioni tra i servizi applicativi e la porta di dominio fino ad arrivare a WS-Security.

• ErroriApplicativi generati dalla Porta di Dominio

Attraverso la voce org.openspcoop.pdd.erroreApplicativo.fault è possibile indicare il tipo di errore applicativo generato dallaporta di dominio, in caso di errori di processamento o errori utente (default: soap):

– xml, l’errore prodotto sarà inserito all’interno di un SoapBodyElement e seguirà la struttura definita nel documento dispecifica CNIPA Sistema Pubblico di cooperazione: Porta di Dominio v1.0 a pg 41.

– soap, l’errore prodotto è realizzato come un SoapFault con le seguenti caratteristiche:

* FaultActor, valore indicato nella voce org.openspcoop.pdd.erroreApplicativo.faultActor (default: OpenSPCoop).

* FaultString, contiene l’xml che forma il messaggio di errore applicativo come definito nella specifica CNIPA (SistemaPubblico di cooperazione: Porta di Dominio v1.0 a pg 41) se l’opzione org.openspcoop.pdd.erroreApplicativo.fault.detailsnon è abilitata, altrimenti contiene una descrizione dell’errore.

* FaultCode, contiene il codice dell’errore.

http://www.openspcoop.org/openspcoop_v3//doc/spcoop/SPCoop-PortaDominio_v1.0_20051014.pdf




18 / 84

* Details, contiene l’xml che forma il messaggio di errore applicativo come definito nella specifica CNIPA (Sistema Pub-blico di cooperazione: Porta di Dominio v1.0 a pg 41) se l’opzione org.openspcoop.pdd.erroreApplicativo.fault.details èabilitata, altrimenti non sono presenti details.

I codice di errore, sia nel tipo xml che nel tipo soap, differiscono a seconda del tipo di errore applicativo generato dalla portadi dominio (vedi documento Sistema Pubblico di cooperazione: Porta di Dominio v1.0 a pg 41):

– EccezioneBusta, l’errore applicativo viene generato dalla porta di domino in seguito ad un fallimento del protocollo e-Gov. Icodici di errore possono essere uno dei codici EGOV_IT definiti nel documento CNIPA Sistema Pubblico di cooperazione:Busta di E-Gov v1.1

– EccezioneProcessamento, l’errore applicativo viene generato dalla porta di domino in seguito a errori di processamentointerni. I codici di errore, non essendo definiti da un documento di specifica CNIPA, sono proprietari di OpenSPCoop,il quale produce errori di classe 4XX e di classe 5XX (vedi Manuale di Sviluppo: La gestione degli errori nell’Intera-zione con la Porta di Dominio ). Il prefisso dei codici di errore (es. OPENSPCOOP_ORG_500) è definito nella voceorg.openspcoop.pdd.erroreApplicativo.prefixFaultCode (default OPENSPCOOP_ORG_ ). OpenSPCoop produce per de-fault codici di errore specifici a seconda del tipo di errore, all’interno della classe 4XX o 5XX (es. 502, 403 ... ). Questa op-zione può essere disattivata (producendo errori generici 400 e 500) attraverso la voce org.openspcoop.pdd.erroreApplicativo.genericFaultCode(true/false).

• Interscambio di informazioni tra Servizi Applicativi e Porte di Dominio

Un Servizio Applicativo può dover passare/ricevere informazioni SPCoop dalla Porta di Dominio ad esempio per la gestionedei profili asincroni. L’interscambio di informazioni viene attuato tramite header di integrazione di diverse tipologie con loscopo di permettere lo scambio nella maniera più consona all’implementazione del servizio applicativo.

È possibile elencare i tipi di integrazione che si desiderano abilitare tramite le proprietà org.openspcoop.pdd.integrazione.tipo.pde org.openspcoop.pdd.integrazione.tipo.pa, rispettivamento lato porta delegata (il servizio applicativo fornisce informazioni al-la PdD) e lato porta applicativa (la PdD fornisce informazioni al servizio applicativo). I tipi di default sono ’trasporto,urlBased’i quali inseriscono le informazioni di integrazione all’interno dell’header di trasporto e della url di invocazione di un servizioapplicativo. Esistono anche altri tipi built-in come ’soap’ e ’wsa’ per informazioni inserite in un header SOAP proprietario diOpenSPCoop o tramite lo standard WS-Addressing. Per ulteriori dettagli sugli header di integrazione è possibile consultare ildocumento Manuale di Sviluppo: Interscambio di informazioni tra Servizi Applicativi e Porte di Dominio . L’ordine degli hea-der ne definisce il livello di importanza in ordine crescente per l’integrazione tra servizio applicativo e pdd. Per l’integrazionetra pdd e servizio applicativo, invece, definisce solo gli header da impostare.

Header di integrazione personalizzatiÈ possibile aggiungere header di integrazione personalizzati. Per ulteriori dettagli vedi Sezione 3.3.3.7

Le keyword utilizzate negli header di integrazione ’trasporto’ ’urlBased’ e ’soap’ sono personalizzabili attraverso le seguentivoci:

– org.openspcoop.pdd.integrazione.TIPO_INTEGRAZIONE.keyword.tipoMittente, tipo mittente della busta eGov

– org.openspcoop.pdd.integrazione.TIPO_INTEGRAZIONE.keyword.mittente, mittente della busta eGov

– org.openspcoop.pdd.integrazione.TIPO_INTEGRAZIONE.keyword.tipoDestinatario, tipo destinatario della busta eGov

– org.openspcoop.pdd.integrazione.TIPO_INTEGRAZIONE.keyword.destinatario, destinatario della busta eGov

– org.openspcoop.pdd.integrazione.TIPO_INTEGRAZIONE.keyword.tipoServizio, tipo servizio della busta eGov

– org.openspcoop.pdd.integrazione.TIPO_INTEGRAZIONE.keyword.servizio, servizio della busta eGov

– org.openspcoop.pdd.integrazione.TIPO_INTEGRAZIONE.keyword.azione, azione della busta eGov

– org.openspcoop.pdd.integrazione.TIPO_INTEGRAZIONE.keyword.idegov, identificativo e-gov

– org.openspcoop.pdd.integrazione.TIPO_INTEGRAZIONE.keyword.riferimentoMessaggio, riferimento Messaggio

– org.openspcoop.pdd.integrazione.TIPO_INTEGRAZIONE.keyword.idCollaborazione, identificativo di Collaborazione

– org.openspcoop.pdd.integrazione.TIPO_INTEGRAZIONE.keyword.idApplicativo, indentificativo di correlazione applicativa

– org.openspcoop.pdd.integrazione.TIPO_INTEGRAZIONE.keyword.servizioApplicativo, identita del servizio applicativo

L’header di integrazione di tipo soap è inoltre personalizzabile attraverso le seguenti voci:




http://www.openspcoop.org/openspcoop_v3//doc/spcoop/SPCoop-Busta_e-Gov_v1.1_20051014.pdf


http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=sviluppo&rel=1.4&id=ar01s06.html




19 / 84

– org.openspcoop.pdd.integrazione.soap.headerName, nome dell’header soap

– org.openspcoop.pdd.integrazione.soap.headerPrefix, prefisso dell’header soap

– org.openspcoop.pdd.integrazione.soap.headerActor, actor dell’header SOAP di integrazione; il valore viene utilizzato anchecome namespace

La porta di dominio, lato porta delegata, una volta interpretato un header di integrazione, può essere configurata per eliminaretale header dal messaggio che verrà poi spedito alla PdD di Destinazione. Questo comportamento viene indicato nella proprietàorg.openspcoop.pdd.integrazione.pd.readAndDelete (default: true). Se non viene eliminato, l’header verrà aggiornato con ivalori della cooperazione SPCoop individuata dalla porta delegata. La busta che arriverà alla porta applicativa possiederàquindi l’header di integrazione, con alcuni valori non presenti normalmente nella busta eGov quali la correlazione applicativao l’identità del servizio applicativo fruitore.

La porta di dominio, interpreta normalmente un header di integrazione solo lato porta delegata. Tramite la proprietà org.openspcoop.pdd.integrazione.pa.process(default: false), è possibile indicare alla porta di dominio di interpretare l’header di integrazione anche lato porta applicativa.Se questo controllo viene abilitato, in una porta di dominio abilitata come router l’header di integrazione non viene eliminatopoichè il routing non cambia il messaggio, altrimenti l’header di integrazione, una volta interpretato viene eliminato.

• Servizio di Integration Manager

Il servizio di IntegrationManager, descritto nel documento Manuale di Sviluppo: Modalità d’integrazione tramite il servizio diIntegrationManager , è personalizzabile in alcuni aspetti di configurazione avanzata, tramite le seguenti proprietà:

– org.openspcoop.pdd.service.IntegrationManager.nomePortaDelegataUrlBased, modalità di definizione della porta delegataindicata nel metodo ’invocaPortaDelegata’. Di default (value=false) il nome fornito viene utilizzato interamente per indivi-duare la porta delegata da utilizzare. È possibile modificare il comportamento in modo che il nome fornito viene utilizzatoin parte per riconoscere la porta delegata (prefisso) e in parte per l’identificazione dinamica del soggetto/servizio/azione(’url-based’).

– org.openspcoop.pdd.service.IntegrationManager.infoTrasporto, indica se le informazioni di trasporto, presenti durante l’in-vocazione del servizio, devono essere utilizzate per l’integrazione dei servizi applicativi, lato porta delegata. (Default:false)

• Imbustamento SOAP

Impostazioni riguardanti il servizio di imbustamento SOAP (openspcoop/PDtoSOAP/). Tale servizio permette a servizi appli-cativi che non parlano il protocollo SOAP di interfacciarsi alla Porta di Dominio. Per ulteriori dettagli vedi Guida Utente XML:Funzionalità di integrazione, Imbustamento Contenuti Applicativi . Di seguito vengono descritte le proprietà che influenzanotale servizio di imbustamento:

– org.openspcoop.pdd.core.soap.deleteInstructionTargetMachineXml, un contenuto xml fornito per l’imbustamento SOAP,tramite il servizio ’PDtoSOAP’ non deve possedere l’istruzione <?xml. L’opzione permette di effettuere l’eliminazionedi tale istruzione di codifica, se presente. Se deleteInstructionTargetMachineXml=false e l’istruzione <?xml è presentel’imbustamento SOAP non avrà successo, e sarà generato un errore. (Default:false)

– org.openspcoop.pdd.core.soap.tunnelSOAP, keyword da utilizzare come nome di un header HTTP o come nome di proprietàin stile FormBased per richiedere il servizio di TunnelSOAP offerto da OpenSPCoop. Il valore della proprietà deve essereimpostato a true. Il tunnel può essere attivato per una richiesta, tramite il servizio di imbustamento (servizio ’PDtoSOAP’),utilizzando l’header http o l’url del servizio, impostando la keyword indicata dalla proprietà. Il tunnel può essere attivatoanche per una risposta presente nell’http-reply (in profili sincroni) sempre tramite l’header http della risposta, impostando lakeyword indicata dalla proprietà. (Default: OpenSPCoopTunnelSOAP)

– org.openspcoop.pdd.core.soap.tunnelSOAP.mimeType, Se viene richiesto il servizio di imbustamento, il contenuto inviatoviene codificato in Base64 con mime-type application/openspcoop se non viene fornito un mime-type attraverso questa pro-prietà. Se invece viene fornito un mime-type verrà utilizzato il DataContentHandler associato al mime type, che deve esserestato registrato in META-INF/mailcap all’interno dell’archivio OpenSPCoop (Default: OpenSPCoopTunnelSOAPMimeTy-pe)

• WS-Security

È possibile configurare alcuni aspetti di gestione degli header di integrazione WS-Security prodotti dalla porta di dominio.

Attraverso l’opzione org.openspcoop.pdd.wssecurity.actorDefault.enable è possibile indicare alla porta di dominio se aggiun-gere un actor di default nel caso in cui la configurazione WSS lo comprenda. L’impostazione di un actor di default per l’headerWSS introdotto dalla PdD è fondamentale per non avere conflitti durante la gestione, se anche i servizi applicativi fruitori ederogatori gestiscono a loro volta un header wssecurity a livello applicativo (e non utilizzano un actor). Attraverso l’opzione



http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s05.html#imbustamentoContenutiApplicativi

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s05.html#imbustamentoContenutiApplicativi


20 / 84

org.openspcoop.pdd.wssecurity.actorDefault.valore è possibile definire l’eventuale actor di default introdotto dalla porta didominio (Default: enable=true e valore=openspcoop).

• HandlerBypassHeaderElement

NotaLe proprietà descritte di seguito non sono più utilizzate a meno di usufruire dei servizi deprecati openspcoop/services/PD eopenspcoop/services/PA.

È possibile configurare alcuni aspetti di gestione degli header presenti nei messaggi SOAP ricevuti dalla porta di dominio. Nelcaso in cui un msg SOAP, ricevuto da un servizio di OpenSPCoop, possieda un header con l’attributo mustUnderstand=1 e nonsia presente l’actor, il servizio Axis provoca erroneamente un SoapFault, perché pensa che debba gestire l’header, e non possie-de informazioni per farlo. Il filtro, inserito in testa ai servizi axis di OpenSPCoop (con un handler) permette di bypassare il pro-blema segnalando come processed l’ header. L’opzione org.openspcoop.pdd.services.BypassMustUnderstandHandler.allHeaders(default false) impostata a true abilita l’utilizzo del filtro per qualsiasi HeaderElement che possiede mustUnderstand=1 e nonpossiede un actor. Se si desidera invece abilitare un filtro più selettivo verso gli header da gestire, che possiedono mustUnder-stand=1 e non possiedono un actor, è possibile operare con la proprietà org.openspcoop.pdd.services.BypassMustUnderstandHandler.headerfornendo nome dell’header e namespace uri. Esempi di filtri abilitati per default sono i seguenti:

– org.openspcoop.pdd.services.BypassMustUnderstandHandler.header.Security, abilita gli header di WS-Security (namespaceuri: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd).

– org.openspcoop.pdd.services.BypassMustUnderstandHandler.header.Sequence, abilita gli header di WS-Reliability (name-space uri: http://schemas.xmlsoap.org/ws/2005/02/rm).

3.3.1.10 Autorizzazione Buste e-Gov in ingresso

La porta di dominio può essere configurata per attuare o meno un controllo di autorizzazione delle buste e-Gov in ingresso. È pos-sibile indicare uno dei seguenti controlli di autorizzazione tramite la proprietà org.openspcoop.pdd.autorizzazioneSPCoop.tipo(default: none):

• none, non viene effettuato alcun controllo.

• spcoop, vengono utilizzate le adesioni ad un servizio registrate nel registro dei servizi come meccanismo di autorizzazione allafruizione di un servizio. Se il soggetto mittente della busta e-Gov risulta registrato come fruitore del servizio nel registro deiservizi, allora tale soggetto è autorizzato.

• pddConsole, vengono utilizzate le informazioni presenti nel database dell’applicazione pddConsole che possiede un registrodei servizi locale (vedi Sezione 5.1).

Per ulteriori dettagli sul meccanismo di autorizzazione delle buste e-Gov è possibile consultare i documenti Guida Utente:Funzionalità avanzate, Autorizzazione SPCoop e Guida Utente XML: Funzionalità avanzate, Autorizzazione delle buste eGovin ingresso

NotaIl tipo di autorizzazione effettuata dal servizio di ricezione buste eGov indica il nome di una classe, registrata in classNa-me.properties, che implementa l’interfaccia org.openspcoop.pdd.core.autorizzazione.IAutorizzazioneOpenSPCoop.java. Perulteriori dettagli su come creare un meccanismo di autorizzazione personalizzato vedi Sezione 3.3.3.5.

È possibile anteporre una cache al processo di autorizzazione delle buste e-Gov. La configurazione della cache avviene attraversole seguenti voci:

• org.openspcoop.pdd.autorizzazioneSPCoop.cache.enable, permette di abilitare/disabilitare (true/false) la cache.

• org.openspcoop.pdd.autorizzazioneSPCoop.cache.dimensione, permette di impostare la dimensione della cache.



http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s05.html#autorizzazioneSPCoop



21 / 84

• org.openspcoop.pdd.autorizzazioneSPCoop.cache.algoritmo, permette di impostare l’algoritmo utilizzato con la cache (LRU/M-RU).

• org.openspcoop.pdd.autorizzazioneSPCoop.cache.itemIdleTime, indica il massimo intervallo di tempo, in secondi, che unelemento può esistere senza essere acceduto.

• org.openspcoop.pdd.cautorizzazioneSPCoop.cache.itemLifeSecond, permette di impostare la vita, in secondi, di un elementoinserito in cache.

(Default: config.cache.enable=false)

3.3.1.11 Protocollo e-Gov

La gestione del protocollo e-Gov attuata dalla Porta di Dominio è altamente configurabile.

• Contatore Seriale per ID e-Gov

La proprietà org.openspcoop.egov.id.tipo, permette di gestire la modalità della costruzione del numero seriale utilizzato negliIdentificativi EGov. Esistono le seguenti modalita: (default: static)

– db, viene utilizzato il contatore presente nella tabella ID_EGOV del database di OpenSPCoop. La colonna viene accedutacon un livello di isolamento serializable. (vedi Sezione 3.2.3)

– static, viene utilizzato un field statico di una classe java.

Il metodo static è più efficente rispetto al corrispettivo metodo su database. Presenta però delle limitazioni in contesti diinstallazione in cluster della porta di dominio. In tale contesto, poichè l’informazione è memorizzata staticamente due portedi dominio installate su due application server distinti, possono produrre gli stessi contatori seriali e quindi potenzialmente glistessi id e-Gov. Per utilizzare quindi la tipologia static in installazioni in cluster bisogna:

1. Scegliere un identificativo numerico progressivo, a partire da 0 (0>=NUMERO_PROGRESSIVO<=99), per ciascunaistanza del software OpenSPCoop nel cluster

2. Impostare nella proprietà org.openspcoop.egov.id.prefix di ogni OpenSPCoop il corrispettivo numero progressivo scelto

Se la proprietà org.openspcoop.egov.id.prefix viene impostata, il numero seriale inserito nell id e-gov, composto normalmenteda 7 cifre generate tutte in maniera sequenziale e univoca, verrà composto invece dal numero progressivo impostato nellaproprietà e solo le rimanenti cifre verranno generate in maniera sequenziale e univoca (es1. prefix=3, seriale=3XXXXXX)(es2. prefix=13, seriale=13XXXXX).

• Repository delle Buste e-Gov.

La proprietà org.openspcoop.egov.repository.gestore influenza la gestione del repository delle buste e-Gov, in particolare ilsistema di marcatura delle buste e-Gov rispetto all’attuale utilizzo della porta di dominio. La tabella RepositoryEGov deldatabase di OpenSPCoop (vedi Sezione 3.2.3) contiene tre campi booleani utilizzati per la marcatura:

– HISTORY: busta ancora in uso per funzionalità di confermaRicezione(OUTBOX)/FiltroDuplicati(INBOX)

– PROFILI: busta ancora in uso in profili di collaborazione

– PDD: busta ancora in uso da funzionalità della porta di dominio (es. message box)

La gestione di questi booleani può essere personalizzata per il database utilizzato, per migliorare le performance in presenzadi indici. La gestione è configurabile attraverso la proprietà org.openspcoop.egov.repository.gestore. Attuali tipi possibili sono

– default: gestione dei tre booleani singolarmente istanziati come tre distinti INTEGER (utilizzabile in qualsiasi tipo didatabase)

– bytewise: gestione dei tre booleani compattati in un unico campo INTEGER e trattati con una maschera di bit attraversooperatori or e and (utilizzabile per database postgresql e mysql)

– oracle: gestione dei tre booleani specifica per il database Oracle. Sono compattati in un unico campo RAW e trattati conuna maschera di bit attraverso operatori ’BIT_OR’ e ’BIT_AND’ della libreria ’utl_raw’


22 / 84

Ottimizzazione di operazioni su bitUn tipo di gestione diversa da quella di default richiede una creazione della tabella con opportuni campi di gestione per ibooleani. (Esempio di inizializzazione, diversa da quella di default, per i tipi di gestione esistenti sono forniti, commentati, nelfile OpenSPCoop.sql descritto inSezione 3.2.3).

NotaÈ possibile fornire implementazioni diverse della gestione, per ulteriori dettagli vedi Sezione 3.3.3.12.

• Protocollo e-Gov

Le seguenti opzioni permettono di personalizzare la gestione della busta e-Gov e il comportamento della Porta di Dominiorispetto alle buste gestite:

– org.openspcoop.egov.oneway.http202 (Default: true), permette di definire il contenuto http di risposta per un profilo oneway(e per asincroni in modalità asincrona). È possibile far ritornare una reply http vuota con codice http 202 (opzione=true) oun messaggio soap con body vuoto con codice http 200 (opzione=false).org.openspcoop.egov.oneway.http202.bodyEmptyWithHeader.enable (Default: true), in un contesto di invocazione della por-ta delegata, con org.openspcoop.egov.oneway.http202=true e header di integrazione impostato a ’soap’ (o con un’altra inte-grazione che richieda un header soap di integrazione), se il profilo di collaborazione è oneway (e per asincroni in modalitàasincrona) viene potenzialmente costruito dalla porta un messaggio Soap con body vuoto ma con un header soap. Questaopzione indica se ritornare al servizio applicativo tali messaggi, o se in caso in cui il soap body è vuoto, il messaggio nondeve essere ritornato (carico http di risposta vuoto e codice http 202).

– org.openspcoop.egov.soggetti.tipi (Default: SPC,TEST,AOO), elenco dei tipi associabili ad un soggetto SPCoop

– org.openspcoop.egov.servizi.tipi (Default: SPC,TEST,URL,WSDL,LDAP,UDDI,ebXMLRegistry), elenco dei tipi associa-bili ad un servizio SPCoop

– org.openspcoop.egov.filtroDuplicati.letturaRegistro (Default: true), se abilitata, la porta di dominio non si fida della bustaeGov ricevuta, ma controlla il registro dei servizi per verificare se deve effettuare il filtro-duplicati

– org.openspcoop.egov.confermaRicezione.letturaRegistro (Default: true), se abilitata, la porta di dominio non si fida dellabusta eGov ricevuta, ma controlla il registro dei servizi per verificare se deve generare un riscontro. Se la gestione deiriscontri viene richiesta nell’accordo ma non nella busta (attributo confermaRicezione) viene generato un errore.

– org.openspcoop.egov.consegnaInOrdine.letturaRegistro (Default: true), se abilitata, la porta di dominio non si fida dellabusta eGov ricevuta, ma controlla il registro dei servizi per verificare se deve gestire la consegna in ordine. Se la consegnain ordine viene richiesta nell’accordo ma non nella busta (elemento sequenza) viene generato un errore.

– org.openspcoop.egov.strutturaHeaderNonCorretta.generazioneRispostaSPCoop (Default: false), in caso di header eGov construttura non corretta è possibile indicare se interpretare comunque l’header e generare una possibile risposta o ritornare soloun SOAPFault EGOV_IT_001. Per default viene generato solo un SoapFault

– org.openspcoop.egov.manifestAttachments.role.*, le proprietà permettono di definire il valore inserito/atteso nell’attributorole di un elemento Riferimento presente in un manifest egov (in base al ruolo funzionale). Le opzioni sono le seguenti

* org.openspcoop.egov.manifestAttachments.role.richiesta (default: Richiesta)

* org.openspcoop.egov.manifestAttachments.role.risposta (default: Risposta)

* org.openspcoop.egov.manifestAttachments.role.allegato (default: Allegato)

– org.openspcoop.egov.validazione.readQualifiedAttribute (Default: false), permette di far accettare/processare alla porta didominio delle buste eGov che possiedono attributi qualificati.

– L’identificativo egov presente in una busta è formato da 5 parti:

<nome_mittente>_<pdd_mittente>_<numero_seriale>_<data>_<ora>Esempio: MinisteroFruitore_MinisteroFruitoreSPCoopIT_0000001_2009-07-22_10:59

* nome_mittente, deve corrispondere al nome mittente della busta eGov

* pdd_mittente, deve corrispondere all’identificativo porta del soggetto mittente

* numero_seriale, si tratta di un numero sequenziale gestito dalla PdD e composto da 7 cifre

* data, data in cui viene emessa la busta eGov


23 / 84

* ora, ora in cui viene emessa la busta eGovLa PdD OpenSPCoop valida per default ogni singola parte di un identificativo eGov. È possibile istruire la PdD in modo chenon validi le prime due parti (nome e identificativo porta del mittente) tramite l’opzione org.openspcoop.egov.validazione.idegov.validazioneCompleta(Default: true).

– org.openspcoop.egov.asincroni.attributiCorrelati.enable (Default: true), indica la porta deve generare gli attributi ’tipo’ e’servizioCorrelato’ nell’elemento ’ProfiloCollaborazione’ della richiesta asincrona simmetrica e della ricevuta alla richiestaasincrona asimmetrica

– org.openspcoop.egov.collaborazione.enable (Default: true), indica se la porta deve generare/gestire l’elemento Collabora-zione della busta

– org.openspcoop.egov.consegnaInOrdine.enable (Default: true), indica se la porta deve gestire la consegna in ordine (Conse-gnaAffidabile+Collaborazione+Sequenza)

– org.openspcoop.egov.trasmissione.enable (Default: true), indica se la porta deve generare la lista trasmissioni nella busta– org.openspcoop.egov.riscontri.enable (Default: true), indica se la porta deve gestire i riscontri:

* produzione busta di richiesta servizio con elemento ProfiloTrasmissione che possiede l’attributo confermaRicezione=true

* produzione di una busta di risposta contenente il riscontro

* validazione e gestione di buste che contengono riscontri– org.openspcoop.egov.filtroduplicati.generazioneSPCoopErrore (Default: false), indica se la porta deve generare un messag-

gio SPCoopErrore se viene ricevuto un messaggio duplicato in presenza di un profilo di collaborazione OneWay o profiliAsincroni (in modalità asincrona)

– org.openspcoop.egov.spcoopErrore.ignoraNonGravi.enable (Default: false), la Porta di Dominio considera le busta che con-tengono una lista eccezioni con eccezioni di qualsiasi tipo, un errore SPCoop (con associato SOAPFault). Attraverso l’opzio-ne è possibile indicare alla porta che liste eccezioni, con eccezioni non gravi, possono essere processate come un messaggioSPCoop normale, non di errore. Solo in presenza di eccezioni di livello GRAVE, il msg deve essere un msg SPCoopErrore(con associato SOAPFault). Le eccezioni di livello non GRAVE vengono registrate attraverso un msg diagnostico di livelloinfoSpcoop.

– org.openspcoop.egov.spcoop.validazione.ignoraEccezioniNonGravi (Default: false), la validazione di una busta SPCoop,risulta non riuscita se viene rilevata una eccezione di qualsiasi livello. Se si desidera, invece, ritenere una busta SPCoopmalformata solo se la validazione rileva eccezioni di livello GRAVE, deve essere abilitata la seguente opzione

Certificazione CNIPA e linee guida 1.1Le opzioni indicate permettono la gestione di tutte le funzionalità e-Gov descritte nel documento Sistema Pubblico di Coo-perazione: Busta EGov 1.1 . Tali opzioni vengono interpretate dalla Porta di Dominio solo se il servizio fruito/erogato vienegestito tramite profilo eGov1.1; se invece è stato scelto il profilo eGov1.1-lineeGuida1.1 (per ulteriori dettagli vedi GuidaUtente della Porta di Dominio OpenSPCoop: Profili e Compatibilità ) viene automaticamente impostato una gestione dellabusta come descritto nel documento Sistema Pubblico di Cooperazione: Linee Guida all’uso della Busta EGov 1.1 . In questocontesto la porta di dominio gestisce la busta come se le opzioni fossero impostate ai seguenti valori:

– org.openspcoop.egov.soggetti.tipi=SPC

– org.openspcoop.egov.servizi.tipi=SPC

– org.openspcoop.egov.asincroni.attributiCorrelati.enable=false

– org.openspcoop.egov.collaborazione.enable=false , viene generato l’id di collaborazione solo per i profili di collaborazioneasincroni, dove ogni richiesta/risposta contiene una collaborazione che possiede l’identificativo e-Gov della richiesta.

– org.openspcoop.egov.consegnaInOrdine.enable=false

– org.openspcoop.egov.riscontri.enable=false

– org.openspcoop.egov.filtroduplicati.generazioneSPCoopErrore=true

– org.openspcoop.egov.spcoopErrore.ignoraNonGravi.enable=true

– org.openspcoop.egov.spcoop.validazione.ignoraEccezioniNonGravi=true , inoltre un eventuale profilo di gestione’eGov1.1-lineeGuida1.1’ segnalerà attraverso Eccezioni di livello info eventuali elementi non conformi alle linee guida



http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=utente&rel=1.4&id=ar01s07.html#profiloGestione

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=utente&rel=1.4&id=ar01s07.html#profiloGestione

http://www.openspcoop.org/openspcoop_v3//doc/spcoop/LineeGuidaBustaEGov_V11.pdf


24 / 84

3.3.1.12 Gestione stateless/stateful dei messaggi

Dalla versione 1.2 sono state realizzate numerose ottimizzazioni nella gestione dei profili di collaborazione, finalizzate prin-cipalmente a limitare l’eccessivo uso del database operato dalla versione 1.0. La principale ottimizzazione è stata introdottatramite l’uso del parametro stateless sulle porte delegate e applicative, o agendo sulla configurazione globale della PdD tramitele proprietà descritte in questo paragrafo.

• org.openspcoop.pdd.stateless.default.*, le porta di dominio può gestire i profili di collaborazione Oneway, Sincrono e Asin-crono in modalita stateless. In questa modalità la gestione avviene senza il salvataggio delle informazioni sul database el’attivazione di diversi MDB funzionali, ma tramite un unico thread. È possibile impostare il comportamento stateless nelcontesto di una porta delegata o applicativa (vedi Guida Utente XML: Configurazione della Porta di Dominio, Porta Delegata, vedi Guida Utente XML: Configurazione della Porta di Dominio, Porta Applicativa e Guida Utente XML: Funzionalità diintegrazione, Modalità di gestione Stateless/Stateful );

Le opzioni org.openspcoop.pdd.stateless.default.oneway, org.openspcoop.pdd.stateless.default.sincrono e org.openspcoop.pdd.stateless.default.asincronipermettono di definire il tipo di gestione di default assunto dalla porta nel caso in cui la modalità di gestione (stateless/stateful)non venga specificata nella porta delegata e/o applicativa.

• org.openspcoop.pdd.stateless.router, (Default: abilitato) la porta di dominio attivata come router può gestire le buste in transitoin modalità stateless. In questa modalità la gestione avviene senza il salvataggio delle informazioni sul database e l’attivazionedi diversi MDB funzionali, ma tramite un unico thread.

• org.openspcoop.pdd.stateful.oneway, la porta di dominio può gestire un profilo oneway con una modalità di trasmissionesincrona, dove la risposta al client non viene restituita fino a che la porta di dominio non ha finito di gestire la richiesta,o una modalità di trasmissione asincrona, dove la porta di dominio si prende in carico di consegnare la richiesta e sbloccasubito il client. La modalità di trasmissione sincrona viene utilizzata se la porta delegata/applicativa viene configurata comestateless, altrimenti viene utilizzata la modalità asincrona. È possibile avere anche un approccio ibrido dove la gestione avvienein modalità stateless ma la modalità di trasmissione è asincrona. Questo comportamento viene configurato dalla seguenteproprietà:

– org.openspcoop.pdd.stateful.oneway=1.0, gestione asincrona effettuata come nella versione 1.0 di OpenSPCoop attraversol’attivazione a cascata degli MDB funzionali.

– org.openspcoop.pdd.stateful.oneway=1.1 (Default), gestione asincrona effettuata con modalità stateless.

3.3.1.13 Consegna asincrona dei messaggi

La consegna asincrona, impostabile per il profilo Oneway sulle porte delegate e applicative tramite il parametro stateless=disabilitato,indica alla Porta di Dominio di prendere in carico il messaggio e sbloccare subito il client. La consegna del messaggio verràeffettuata dalla porta di dominio in un secondo momento, e in caso di errore tale consegna verrà ripetuta ad intervalli regolarifino a che non si abbia una consegna con successo.

I tentativi di riconsegna del messaggio possono essere effettuati ad intervalli regolari o calcolati tramite un algoritmo che impostaun ritardo crescente sulla base del numero di riconsegne. La proprietà org.openspcoop.pdd.connettore.ritardo.stato, permette diabilitare l’algoritmo che ritarda le riconsegne dei messaggi (default: disabilitato).

Se si abilita l’algoritmo di ritardo nelle riconsegne dei messaggi la proprietà org.openspcoop.pdd.connettore.ritardo.* permettedi personalizzarlo. L’algoritmo viene descritto dalla seguente formula:

DataProssimaRiconsegnaSecondi = DataPrecedenteSpedizioneSecondi + CadenzaRispedizione + ( ←↩FattoreRitardo^FattoreCrescita(numeroRitentativoConsegna) )

Quindi l’intervallo di tempo tra un invio ed il successivo viene calcolato sommando la cadenza di rispedizione al fattore di ritardoincrementato esponenzialmente o linearmente del numero di tentativi già effettuati. Descriviamo adesso i parametri per impostarei valori della formula:

• CadenzaRispedizione, la cadenza di rispedizione viene impostata nella porta di dominio (vedi voce ’gestione-errore’ del do-cumento Guida Utente XML: ConfigurazionePdD, Gestione Errore e l’esempio descritto nel documento Guida Utente XML:Gestione avanzata dell’errore nell’invocazione di un Servizio Applicativo )

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s03.html#portaDelegata


http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s03.html#portaApplicativa

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s05.html#statelessEsempio

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s05.html#statelessEsempio

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s03.html#gestioneErrore

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s05.html#gestioneErroreAvanzato

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s05.html#gestioneErroreAvanzato


25 / 84

• FattoreRitardo, impostabile tramite la proprietà org.openspcoop.pdd.connettore.ritardo.fattore, indica l’intervallo di ritardoper le ri-consegne di messaggi in secondi (default: 2).

• FattoreCrescita, impostabile tramite la proprietà org.openspcoop.pdd.connettore.ritardo.operazione, indica l’algoritmo di cre-scita, esponenziale(*) o lineare(+) (default: *)

• Limite di Crescita, impostabile tramite la proprietà org.openspcoop.pdd.connettore.ritardo.limite, indica il limite del numerodi tentativi utilizzato come esponente per il fattore di ritardo (default: infinito)

Ad esempio, per un messaggio al quarto tentativo di spedizione, data una CadenzaRispedizione di 150000 secondi, la proprie-tà org.openspcoop.pdd.connettore.ritardo=2 e org.openspcoop.pdd.connettore.operazione=* la data del prossimo tentativo dispedizione verrà calcolata come: dataPrecedenteSpedizioneSecondi + 150000 + (2*2*2*2).

3.3.1.14 Sincronizzazione temporale

Per la sincronizzazione temporale la Porta di Dominio può adottare due tipologie (specificabili tramite la proprietà org.openspcoop.pdd.tempo.tipo,default: spc)

• spc, indica che la porta di dominio possiede una sorgente temporale sincronizzata attraverso un server centrale certificatodall’infrastruttura SPC

• locale, indica che la porta di dominio utilizza una sorgente temporale (locale o anche remota) non sincronizzata attraverso unserver centrale certificato dall’infrastruttura SPC

Il tipo di gestione scelta viene indicata anche all’interno delle buste e-Gov.

La sorgente temporale utilizzata dalla Porta di Dominio viene definita dalla proprietà org.openspcoop.pdd.date.tipo (default:system):

• system, viene utilizzato il metodo System.currentTimeMillis per la lettura della data di sistema.

• java, viene utilizzata la classe java.util.Date per la lettura della data dalla JVM.

• ntp, la data viene letta da un server NTP (Network Time Protocol) RFC 1305. È possibile indicare l’indirizzo del server attraver-so la voce org.openspcoop.pdd.date.property.ntp.server. Inoltre è possibile configurare un timeout (org.openspcoop.pdd.date.property.ntp.timeout)e abilitare una cache che limita il numero di letture al secondo verso il server (voci org.openspcoop.pdd.date.property.ntp.cache.enablee org.openspcoop.pdd.date.property.ntp.cache.refresh).

• tcpTime e udpTime, la data viene letta da un server TPC/UDP Time RFC 868. È possibile indicare l’indirizzo del server attraver-so la voce org.openspcoop.pdd.date.property.time.server (per il server TCP è possibile indicare anche la porta attraverso la voceorg.openspcoop.pdd.date.property.time.porta). Inoltre è possibile configurare un timeout (org.openspcoop.pdd.date.property.time.timeout)e abilitare una cache che limita il numero di letture al secondo verso il server (voci org.openspcoop.pdd.date.property.time.cache.enablee org.openspcoop.pdd.date.property.time.cache.refresh).

NotaÈ possibile personalizzare il meccanismo di lettura temporale della Porta di Dominio. Per ulteriori dettagli vedi Sezione 3.3.3.13.

In caso di sincronizzazione verso un server remoto, può succedere che tale server risulti temporaneamente non disponibile persvariati motivi. Nell’arco di tempo in cui non vi è la sincronizzazione temporale, la data del sistema potrebbe disallinearsi equindi la Porta di Dominio potrebbe produrre o ricevere buste e-Gov che portino una data disallineata rispetto alle altre Porte diDominio. In questo contesto è utile avere un intervallo temporale di tolleranza per accettare buste che portano date future rispettoalla data del sistema dove è installata la Porta di Dominio. Per abilitare l’intervallo temporale di tolleranza, si può impostareun valore maggiore di 0 nella proprietà org.openspcoop.pdd.date.intervalloTolleranza, in modo da far accettare alla Porta diDominio messaggi riportanti date future rispetto alla data del sistema, ma che comunque rientrino nell’intervallo di tolleranza(minuti) stabilito. Per default l’intervallo di tolleranza è disabilitato.


26 / 84

3.3.1.15 Dump dei messaggi

La porta di dominio può essere configurata per effettuare dump dei messaggi in transito. Per ulteriori dettagli vedi Sezione 3.3.2

Tramite la proprietà org.openspcoop.pdd.logger.dump.allAttachments (Default: true), viene indicata alla porta di dominio lamodalità di dump. Se tale proprietà viene attivata vengono registrati tutti gli attachments (in caso di dump attivo), altrimenti sologli attachments visualizzabili quali ad es. xml,text-plain

3.3.1.16 Tuning dei componenti architetturali

L’infrastruttura di OpenSPCoop, prima dell’introduzione della modalità operativa stateless dei profili (vedi Sezione 3.3.1.12),era esclusivamente realizzata come un insieme di moduli funzionali implementati tramite MDB, che si scambiavano i messaggitramite code JMS. In questa architettura, era possibile effettuare il tuning di diversi aspetti, in modo da adattare la configurazioneal sistema su cui veniva installata la Porta di Dominio. Questi parametri di configurazione, nell’attuale versione, sono ancora utilisolo in presenza di un utilizzo della Porta di Dominio in un ambiente J2EE (OpenSPCoop.ear) con gestione stateful dei profili dicollaborazione.

• org.openspcoop.pdd.nodeReceiver.*, contiene una configurazione avanzata dei moduli ’RicezioneContenutiApplicativì e ’Ri-cezioneBusteEGov’ dell’architettura di OpenSPCoop. Possono essere personalizzati gli aspetti quali:

– org.openspcoop.pdd.nodeReceiver, tipo di ricezione. Esistono attualmente due tipi ’db’ e ’jms’, entrambi registrati inclassName.properties, che implementano l’interfaccia org.openspcoop.pdd.core.node.INodeReceiver (vedi Sezione 3.3.3)

– org.openspcoop.pdd.nodeReceiver.timeout, timeout di attesa di una risposta in millisecondi (default: 3 Minuti=210000).

– org.openspcoop.pdd.nodeReceiver.check, frequenza di check in millisecondi (default:10)

– org.openspcoop.pdd.nodeReceiver.checkDB, in caso di cache per la gestione dei messaggi abilitata (voce org.openspcoop.pdd.repository.gestoreMessaggi.cache.enable;vedi Sezione 3.3.1.3), per migliorare le performance, se le informazioni su di un messaggio non sono presenti nella cachesi assumono anche non presenti nel database. La cache può comunque svuotarsi velocemente se la dimensione è troppopiccola rispetto al numero di messaggi in parallelo gestiti. Quindi ogni X volte (assumendo X il valore di questa proprietà,se check=10 ogni X*10 millisecondi) viene controllato anche il database, oltre alla cache.

– org.openspcoop.pdd.nodeReceiver.singleConnection, indicazione sul rilascio delle connessioni (true/false) durante la rice-zione di una risposta applicativa

È possibile specializzare il timeout di ricezione per il nodo funzionale:

– org.openspcoop.pdd.nodeReceiver.ricezioneContenutiApplicativi.timeout, timeout utilizzato per il servizio RicezioneConte-nutiApplicativi.

– org.openspcoop.pdd.nodeReceiver.ricezioneBusteEGov.timeout, timeout utilizzato per il servizio RicezioneBusteEGov.

• org.openspcoop.pdd.nodeSender (opzione non modificabile manualmente dall’utente), permette di configurare la modalitàdi attivazione dei moduli dell’architettura di OpenSPCoop. Esistono attualmente due tipi ’db’ e ’jms’, entrambi registrati inclassName.properties, che implementano l’interfaccia org.openspcoop.pdd.core.node.INodeSender. Il tipo jms (Default) attivai moduli attraverso spedizione di messaggi in code JMS; i moduli sono implementati tramite MDB in ascolto sulle code. Il tipodb registra i messaggi su database; ogni modulo ha un thread che si occupa di fare ricerca attiva sul database per localizzareeventuali messaggi da gestire. Verrà modificata automaticamente dal task ant build o build_threads a seconda del tipo diOpenSPCoop costruito.

• org.openspcoop.pdd.core.TransactionManager, contiene una configurazione avanzata del Transaction Manager di OpenSP-Coop. Possono essere personalizzati gli aspetti quali:

– org.openspcoop.pdd.core.TransactionManager.timeout, timeout di attesa attiva, per la validazione di un messaggio ricevutoda una coda interna, in secondi (default: 2 Minuti=120).

– org.openspcoop.pdd.core.TransactionManager.check, intervallo in millisecondi tra un check e l’altro durante l’attesa attiva;(default: 10)

– org.openspcoop.pdd.core.TransactionManager.checkDB, in caso di cache per la gestione dei messaggi abilitata (voce org.openspcoop.pdd.repository.gestoreMessaggi.cache.enable),per migliorare le performance, se le informazioni su di un messaggio non sono presenti nella cache si assumono anche nonpresenti nel database. La cache può cmq svuotarsi velocemente se la dimensione è troppo piccola rispetto al numero di msgin parallelo gestiti. Quindi ogni X volte (assumendo X il valore di questa proprietà, se check=10 ogni X*10 millisecondi)viene controllato anche il database, oltre alla cache.


27 / 84

– org.openspcoop.pdd.core.TransactionManager.singleConnection, indicazione sul rilascio delle connessioni (true/false) du-rante la validazione della transazione del messaggio.

• org.openspcoop.pdd.jdbc.serializable, contiene una configurazione avanzata della gestione del livello serializable per le con-nessioni al database interno di OpenSPCoop. Possono essere personalizzati gli aspetti quali:

– org.openspcoop.pdd.jdbc.serializable.timeout, timeout di attesa attiva, per la gestone della serializzazione della operazionesul database, in secondi (default: 1 Minuto=60).

– org.openspcoop.pdd.jdbc.serializable.check, intervallo in millisecondi tra un check e l’altro durante l’attesa attiva; l’inter-vallo varia casualmente nell’intervallo [0,check] (default: 100)

3.3.2 Logging

La Porta di Dominio è configurabile, su molte funzionalità di logging, tramite il file logger.log4j.properties ed inoltre disponedi appender proprietari per quanto riguarda la memorizzazione di tracce e messaggi diagnostici. Nelle sotto-sezioni di questoparagrafo vengono affrontate tutte le tipologie di logging.

Il sistema di log, configurato tramite il file logger.log4j.properties utilizza il framework Apache Log4J . Il file contiene diverseCategory (log4j.category.*, ad esempio log4j.category.openspcoop.tracciamento per le tracce) che rappresentano un Logger uti-lizzato dalla Porta di Dominio per emettere log di un certo tipo (es. per emettere tracce). Ad ogni Category sono associabili unoo più Appender (log4j.appender.*, ad esempio log4j.appender.openspcoop.tracciamento.rollingFile per le tracce) che rappresen-tano i tipi di repository su cui memorizzare i log. I tipi di repository utilizzabili tramite il framework sono svariati, da filesystem,a database, ad e-mail etc...

Nel file logger.log4j.properties vengono forniti, a titolo di esempio, diversi tipi di Log4J Appender per le Category utilizzatedalla Porta di Dominio OpenSPCoop. I Log4J Appender non sono però associati per default alle rispettive Category a meno deltipo RollingFileAppender, il quale si occupa di emettere i log associati alla category su filesystem, ruotando i log ogni volta cheil singolo file di log supera la dimensione stabilita. Ad esempio per la category sul tracciamento si ha l’associazione tramite laseguente riga:

log4j.category.openspcoop.tracciamento=ALL,openspcoop.tracciamento.rollingFile

Di seguito vengono descritti i Log4J Appender riportati a titolo di esempio all’interno del file di configurazione:

• FileAppender (log4j.appender.openspcoop.<CategoryName>.file), si occupa di emettere i log associati alla category su filesy-stem nel file indicato tramite la voce log4j.appender.openspcoop.<CategoryName>.file.File.

• RollingFileAppender, (log4j.appender.openspcoop.<CategoryName>.rollingFile), si occupa di emettere i log associati alla ca-tegory su filesystem nel file indicato tramite la voce log4j.appender.openspcoop.<CategoryName>.rollingFile.File. Quando ladimensione del file di log raggiunge la dimensione indicata dalla proprietà log4j.appender.openspcoop.<CategoryName>.rollingFile.MaxFileSizeil file di log viene ruotato.

• DailyRollingFileAppender, (log4j.appender.openspcoop.tracciamento.dateRollingFile), si occupa di emettere i log associati al-la category su filesystem nel file indicato tramite la voce log4j.appender.openspcoop.<CategoryName>.dateRollingFile.File.Tramite la proprietà log4j.appender.openspcoop.<CategoryName>.dateRollingFile.DatePattern può essere indicato il mecca-nismo di rotazione del log:

– yyyy-MM, ruotazione effettuata il primo giorno di ogni mese

– yyyy-ww, ruotazione effettuata all’inizio della settimana

– yyyy-MM-dd, ruotazione effettuata alla mezzanotte di ogni giorno

– yyyy-MM-dd-a, ruotazione effettuata alla mezzanotte e a mezzogiorno di ogni giorno

– yyyy-MM-dd-HH, ruotazione effettuata all’inizio di ogni ora

– yyyy-MM-dd-HH-mm, ruotazione effettuata all’inizio di ogni minuto

– yyyy-MM-dd-HH-mm-ss, ruotazione effettuata all’inizio di ogni secondo

• JDBCAppender, (log4j.appender.openspcoop.<CategoryName>.jdbc), si occupa di emettere i log associati alla category suun database relazionale. I dati di accesso al database come la url di connessione al DB, la tabella utilizzata per il logging,l’username e la password necessari per la connessione devono essere forniti nella configurazione dell’appender.

http://logging.apache.org/log4j/


28 / 84

• SysLogAppender (log4j.appender.openspcoop.<CategoryName>.syslog), si occupa di emettere i log associati alla category suun syslog server. I dati di accesso al syslog server, come la url di connessione e la facility da utilizzare, devono essere fornitenella configurazione dell’appender.

3.3.2.1 Messaggi Diagnostici

I messaggi diagnostici emessi dalla Porta di Dominio sono conformi allo schema xsd descritto nella specifica Sistema pubblicodi cooperazione: Porta di Dominio, versione 1.0 a pg 41.

I messaggi diagnostici possono essere archiviati tramite due tipologie di salvataggio diverse:

• Appender Log4J.

La porta di dominio consegna i singoli xml, formanti un messaggio diagnostico, alla Category Log4J con nome opensp-coop.msgDiagnostico, la quale, nella configurazione di default, si occupa di registrare il log all’interno del file /var/opensp-coop/log/msgDiagnostico.log

I Log4J Appender associabili a questa Category sono quelli offerti dal framework Log4J (alcuni descritti in Sezione 3.3.2)con l’estensione di un Appender built-in di OpenSPCoop. Questo appender personalizzato si occupa di salvare le singoleinformazioni di un messaggio diagnostico su un DBMS. Il database utilizzato include tutte le tabelle necessarie alla rac-colta dei messaggi diagnostici e delle tracce. Tale database viene definito dal file presente nella distribuzione in deploy/pdd/-SQL_table/TIPO_DATABASE/Tracciamento.sql. In particolare il Log4J Appender built-in di OpenSPCoop si occupa di estrarredall’xml di un messaggio diagnostico le informazioni presenti e salvarle nei campi della tabella msgdiagnostici.

Il Log4J Appender built-in di OpenSPCoop è definito dalla classe org.openspcoop.pdd.logger.MsgDiagnosticoLog4JAppender.Le proprietà configurabili per questo appender sono le seguenti:

– DataSource, indica il nome JNDI del datasource da utilizzare per accedere al database contenente la tabella msgdiagnostici.

– DBUrl, DBDriver, DBUser e DBPwd, proprietà da utilizzare in alternativa alla proprietà DataSource, indica i parametridi connessione (rispettivamente connection-url, driver jdbc, username e password) per accedere al database contenente latabella msgdiagnostici.

– FileRejected, indica un path sul filesystem dove verranno salvati i messaggi diagnostici, in caso di fallimento del salvataggiosu database (Default: /var/openspcoop/log/msgDiagnosticoRejected.log).

Il livello di filtraggio dei log, non deve essere impostato nella Category Log4J openspcoop.msgDiagnostico (nella quale deveessere permesso qualsiasi tipo di log: ALL), ma nella configurazione di OpenSPCoop tramite la voce Livello SPCoop dellasezione di configurazione dei messaggi diagnostici. Si rimanda alla Guida Utente XML: Configurazione Porta di Dominio,Messaggi Diagnostici e Guida Utente della Porta di Dominio: Configurazione dei parametri SPCoop per ulteriori dettagli.

• OpenSPCoop Appender.

La porta di dominio consegna i singoli xml, formanti un messaggio diagnostico, agli OpenSPCoopAppender attivati nellasezione Messaggi Diagnostici della configurazione della Porta di Dominio, per ulteriori dettagli vedi Guida Utente XML:Configurazione Porta di Dominio, Messaggi Diagnostici .

Gli OpenSPCoop Appender sono personalizzabili a seconda dello storage che si desidera utilizzare per il salvataggio delleinformazioni. Come creare un appender personalizzabile è illustrato nella Sezione 3.3.3.8. OpenSPCoop possiede un OpenSP-CoopAppender built-in per il salvataggio dei messaggi diagnostici su database (registrato con tipo dbDiagnosticoAppender);lo stesso database utilizzato dal Log4J Appender org.openspcoop.pdd.logger.MsgDiagnosticoLog4JAppender (deploy/pdd/-SQL_table/TIPO_DATABASE/Tracciamento.sql). L’OpenSPCoopAppender, a differenza del Log4J Appender possiede peròdue vantaggi fondamentali:

– performance, l’OpenSPCoopAppender viene invocato direttamente dalla Porta di Dominio OpenSPCoop, mentre il Log4JAppender viene invocato dal framework Log4J dopo che la Porta di Dominio ha invocato la Category Lo4J.

– informazioni aggiuntive, la category Log4J viene invocata dalla Porta di Dominio fornendogli l’xml del messaggio diagno-stico definito dal CNIPA, e quindi le uniche informazioni presenti possono essere solo quelle definite dal documento dispecifica. Mentre l’OpenSPCoopAppender è una implementazione di un’interfaccia java dove sono stati definiti i parame-tri passati, che sono quelli presenti nel messaggio diagnostico CNIPA, con l’aggiunta di informazioni extra riguardanti lacooperazione applicativa per cui vengono emessi i diagnostici. Le informazioni aggiuntive sono contenute in parte nellastessa tabella msgdiagnostici dove sono memorizzate anche le informazioni obbligatorie di un messaggio diagnostico. Taliinformazioni aggiuntive riguardano:



http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s03.html#msgDiagnosticiConfigurazione


http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=utente&rel=1.4&id=ar01s05.html#configurazioneParametriSPCoop




29 / 84

* idegov, id-eGov della richiesta

* idegov_risposta, id-eGov della risposta

Inoltre vengono registrate ulteriori informazioni riguardanti l’intera cooperazione applicativa, contrassegnata dall’identifica-tivo e-Gov. Tali informazioni extra vengono memorizzate in tabelle ulteriori (msgdiag_correlazione e msgdiag_correlazione_sa)e sono accessibili tramite l’identificativo e-Gov della singola cooperazione applicativa:

* porta, nome della porta delegata o applicativa (registrata nella configurazione della porta di dominio) utilizzata per lacooperazione

* tipo_fruitore e fruitore, identificativo del tipo e nome SPCoop del soggetto fruitore della cooperazione applicativa

* tipo_erogatore e erogatore, identificativo del tipo e nome SPCoop del soggetto erogatore della cooperazione applicativa

* tipo_servizio e servizio, identificativo del tipo e nome SPCoop del servizio erogato dal soggetto erogatore

* azione, identificativo dell’azione SPCoop erogata dal servizio

* id_correlazione_applicativa, identificativo di correlazione applicativa (se la correlazione applicativa è abilitata)

* servizio_applicativo, identificativo del servizio applicativo (registrato nella configurazione della Porta di Dominio) frui-tore o erogatore (a seconda del valore della colonna delegata)

L’OpenSPCoopAppender built-in di OpenSPCoop è definito dalla classe org.openspcoop.pdd.logger.MsgDiagnosticoOpenSPCoopAppenderDB.Le proprieà configurabili per questo appender sono le seguenti:

– datasource, indica il nome JNDI del datasource da utilizzare per accedere al database contenente la tabella msgdiagnostici.

– context-<NOME_JNDI>, indica una proprietà da utilizzare nel contesto JNDI per la lookup del datasource. Il nome dellaproprietà sarà quello indicato dopo il prefisso context

– correlazione, [true/false] (Default: true). Indica se devono essere registrate su database anche le informazioni extra.

Il livello di filtraggio dei messaggi diagnostici si definisce nella configurazione di OpenSPCoop tramite la voce Livello SPCoopdella sezione di configurazione dei messaggi diagnostici. Si rimanda alla Guida Utente XML: Configurazione Porta di Dominio,Messaggi Diagnostici e Guida Utente della Porta di Dominio: Configurazione dei parametri SPCoop per ulteriori dettagli.

3.3.2.2 Tracce e-Gov

Le tracce emesse dalla Porta di Dominio sono conformi allo schema xsd descritto nella specifica Sistema pubblico di coopera-zione: Porta di Dominio, versione 1.0 a pg 40.

Le tracce possono essere archiviate tramite due tipologie di salvataggio diverse:

• Appender Log4J.

La porta di dominio consegna i singoli xml, formanti una traccia, alla Category Log4J con nome openspcoop.tracciamento, laquale, nella configurazione di default, si occupa di registrare il log all’interno del file /var/openspcoop/log/tracciamento.log

I Log4J Appender associabili a questa Category sono quelli offerti dal framework Log4J (alcuni descritti in Sezione 3.3.2) conl’estensione di un Appender built-in di OpenSPCoop. Questo appender personalizzato si occupa di salvare le singole informa-zioni di una traccia su un DBMS. Il database utilizzato include tutte le tabelle necessarie alla raccolta dei messaggi diagnostici edelle tracce. Tale database viene definito dal file presente nella distribuzione in deploy/pdd/SQL_table/TIPO_DATABASE/Tracciamento.sql.In particolare il Log4J Appender built-in di OpenSPCoop si occupa di estrarre dall’xml di una traccia le informazioni presentie salvarle nei campi delle tabelle tracce,tracce_riscontri,tracce_eccezioni,tracce_trasmissioni.

Il Log4J Appender built-in di OpenSPCoop è definito dalla classe org.openspcoop.pdd.logger.TracciamentoLog4JAppender.Le proprietà configurabili per questo appender sono le seguenti:

– DataSource, indica il nome JNDI del datasource da utilizzare per accedere al database contenente la tabella tracce.

– DBUrl, DBDriver, DBUser e DBPwd, proprietà da utilizzare in alternativa alla proprietà DataSource, indica i parametridi connessioni (rispettivamente connection-url, driver jdbc, username e password) per accedere al database contenente latabella tracce.

– tipoDatabase, indica il tipo di database dove verranno registrate le informazioni sulle tracce emesse dalla Porta di Dominio.I tipi di database gestiti sono mysql/postgresql/oracle (Default: postgresql).

– FileRejected, indica un path sul filesystem dove verranno salvate le tracce, in caso di fallimento del salvataggio su database(Default: /var/openspcoop/log/tracciamentoRejected.log).







30 / 84

L’abilitazione a registrare o meno le tracce non riguarda il livello di filtraggio dei log. Tale abilitazione non deve quindi essereimpostato nella Category Log4J openspcoop.tracciamento (nella quale deve essere permesso qualsiasi tipo di log: ALL), manella configurazione di OpenSPCoop tramite la voce Tracciamento Buste e-Gov della sezione di configurazione del traccia-mento. Si rimanda alla Guida Utente XML: Configurazione Porta di Dominio, Tracciamento delle Buste e-Gov e Guida Utentedella Porta di Dominio: Configurazione dei parametri SPCoop per ulteriori dettagli.

• OpenSPCoop Appender.

La porta di dominio consegna i singoli xml, formanti una traccia, agli OpenSPCoopAppender attivati nella sezione Traccia-mento Buste e-Gov della configurazione della Porta di Dominio, per ulteriori dettagli vedi Guida Utente XML: ConfigurazionePorta di Dominio, Tracciamento delle Buste e-Gov .

Gli OpenSPCoop Appender sono personalizzabili a seconda dello storage che si desidera utilizzare per il salvataggio delle infor-mazioni. Come creare un appender personalizzabile è illustrato nella Sezione 3.3.3.9. OpenSPCoop possiede un OpenSPCoo-pAppender built-in per il salvataggio delle tracce su database (registrato con tipo dbTracciamentoAppender); lo stesso databaseutilizzato dal Log4J Appender org.openspcoop.pdd.logger.TracciamentoLog4JAppender (deploy/pdd/SQL_table/TIPO_DATABASE/Tracciamento.sql).L’OpenSPCoopAppender, a differenza del Log4J Appender possiede però due vantaggi fondamentali:

– performance, l’OpenSPCoopAppender viene invocato direttamente dalla Porta di Dominio OpenSPCoop, mentre il Log4JAppender viene invocato dal framework Log4J dopo che la Porta di Dominio ha invocato la Category Lo4J.

– informazioni aggiuntive, la category Log4J viene invocata dalla Porta di Dominio fornendogli l’xml della traccia definitadal CNIPA, e quindi le uniche informazioni presenti possono essere solo quelle definite dal documento di specifica. Mentrel’OpenSPCoopAppender è una implementazione di un’interfaccia java dove sono stati definiti i parametri passati, che sonoquelli presenti nella traccia CNIPA, con l’aggiunta di informazioni extra riguardanti la cooperazione applicativa per cuivengono emesse le tracce. Le informazioni aggiuntive sono contenute nella stessa tabella tracce dove sono memorizzateanche le informazioni obbligatorie. Tali informazioni aggiuntive riguardano:

* location, indirizzo IP di provenienza o di inoltro della busta e-Gov riguardante la traccia

* correlazione_applicativa, identificativo di correlazione applicativa (se la correlazione applicativa è abilitata)

* sa_fruitore, identificativo del servizio applicativo fruitore (registrato nella configurazione della Porta di Dominio) in casodi cooperazione applicativa tramite porta delegata

L’OpenSPCoopAppender built-in di OpenSPCoop è definito dalla classe org.openspcoop.pdd.logger.TracciamentoOpenSPCoopAppenderDB.Le proprieà configurabili per questo appender sono le seguenti:

– datasource, indica il nome JNDI del datasource da utilizzare per accedere al database contenente la tabella msgdiagnostici.

– context-<NOME_JNDI>, indica una proprietà da utilizzare nel contesto JNDI per la lookup del datasource. Il nome dellaproprietà sarà quello indicato dopo il prefisso context-

– tipoDatabase, indica il tipo di database dove verranno registrate le informazioni sulle tracce emesse dalla Porta di Dominio.I tipi di database gestiti sono mysql/postgresql/oracle (Default: postgresql).

L’abilitazione a registrare o meno le tracce si definisce nella configurazione di OpenSPCoop tramite la voce TracciamentoBuste e-Gov della sezione di configurazione del tracciamento. Si rimanda alla Guida Utente XML: Configurazione Porta diDominio, Tracciamento delle Buste e-Gov e Guida Utente della Porta di Dominio: Configurazione dei parametri SPCoop perulteriori dettagli.

3.3.2.3 Log della Porta di Dominio

La porta di dominio emette diverse log che esulano dalla raccolta delle tracce e dai messaggi diagnostici definiti dai documentidi specifica del CNIPA. Tali tipologie di log vengono descritte di seguito e si riferiscono una ad una a Category Log4J impostatenel file logger.log4j.properties:

• Msg Diagnostici in formato Human Readable.

La porta di dominio emette dei messaggi diagnostici oltre che nella forma standard descritta in Sezione 3.3.2.1, anche inun formato human readable. Ogni messaggio diagnostico viene tradotto dalla struttura XML definita in Sistema pubblicodi cooperazione: Porta di Dominio, versione 1.0 , in un formato contenente una prima riga formata da una intestazioneche permette di identificare la cooperazione applicativa in corso (id e-Gov, mittente, destinatario, servizio, azione ...) e una

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s03.html#tracciamentiConfigurazione











31 / 84

seconda riga contenente il testo del messaggio diagnostico. La traduzione viene consegnata alla Category Log4J con no-me openspcoop.portaDiDominio, la quale, nella configurazione di default, si occupa di registrare il log all’interno del file/var/openspcoop/log/openspcoop.log

Il livello di filtraggio dei log, non deve essere impostato nella Category Log4J openspcoop.portaDiDominio (nella quale deveessere permesso qualsiasi tipo di log: ALL), ma nella configurazione di OpenSPCoop tramite la voce Livello OpenSPCoopdella sezione di configurazione dei messaggi diagnostici. Si rimanda alla Guida Utente XML: Configurazione Porta di Dominio,Messaggi Diagnostici e Guida Utente della Porta di Dominio: Configurazione dei parametri SPCoop per ulteriori dettagli.

• Servizio di Integration Manager.

I messaggi diagnostici emessi dal servizio di IntegrationManager, dopo essere stati tradotti in un formato leggibile, a differenzadei messaggi emessi da tutti gli altri moduli/servizi di OpenSPCoop, non vengono consegnati alla Category Log4J descrittain precedenza, ma vengono consegnati alla Category Log4J con nome openspcoop.integrationManager, la quale si occupa diregistrare il log all’interno del file /var/openspcoop/log/openspcoop_integrationManager.log.

Il livello di filtraggio dei log, non deve essere impostato nella Category Log4J openspcoop.integrationManager (nella qualedeve essere permesso qualsiasi tipo di log: ALL), ma nella configurazione di OpenSPCoop tramite la voce Livello OpenSPCoopdella sezione di configurazione dei messaggi diagnostici. Si rimanda alla Guida Utente XML: Configurazione Porta di Dominio,Messaggi Diagnostici e Guida Utente della Porta di Dominio: Configurazione dei parametri SPCoop per ulteriori dettagli.

• Informazioni supplementari di funzionamento della PdD

Le informazioni sul funzionamento della PdD, nelle sue parti architetturali (core di OpenSPCoop), sono informazioni aggiun-tive che non rientrano nello scopo dei messaggi diagnostici. Tali informazioni vengono consegnate alla Category Log4J connome openspcoop.core, la quale si occupa di registrare il log all’interno del file /var/openspcoop/log/openspcoop_core.log.

Il livello di log di questa category è possibile impostarla agendo direttamente sulla Category Log4J impostando il livellodesiderato.

3.3.2.4 Dump dei messaggi applicativi

I messaggi che transitano sulla Porta di Dominio vengono gestiti dalla Porta di Dominio solo per processare o creare gli headerdella protocollo e-Gov. Una volta aggiunto o eliminato l’header e-Gov, il messaggio viene inoltrato al servizio applicativo internoo alla Porta di Dominio Erogatore, senza salvare in alcun modo il contenuto applicativo dei messaggi transitati.

In ambienti di test, dove vi possono essere ancora problemi durante l’integrazione tra i servizi applicativi e la porta di domino,o dove è utile comunque conoscere nei dettagli i messaggi che la Porta di Dominio riceve od inoltra, potrebbe essere utile ilsalvataggio del contenuto applicativo. In questi contesti è utilizzabile la funzionalità di dump dei contenuti applicativi attivabiletramite la voce Tracciamento -> Dump della sezione di configurazione del tracciamento. Si rimanda alla Guida Utente XML:Configurazione Porta di Dominio, Tracciamento e Guida Utente della Porta di Dominio: Configurazione dei parametri SPCoopper ulteriori dettagli.

I contenuti dei messaggi in transito sulla Porta di Dominio, se è attiva la funzionalità di dump, vengono consegnati alla CategoryLog4J con nome openspcoop.dump, la quale si occupa di registrare il log all’interno del file /var/openspcoop/log/dump.log.

Il livello di filtraggio dei log, non deve essere impostato nella Category Log4J openspcoop.dump (nella quale deve essere per-messo qualsiasi tipo di log: ALL), ma nella configurazione di OpenSPCoop tramite la voce Dump della sezione di configurazionedelle tracce.

3.3.3 Personalizzazione dei componenti della Porta di Dominio

Tutti i componenti della Porta di Dominio, che verranno descritti in questa sezione, sono completamente personalizzabili. Ivari componenti sono definiti da interfacce java e vengono forniti, con la Porta di Dominio OpenSPCoop, tramite implemen-tazioni built-in disponibili registrate nel file className.properties. La registrazione permette di associare ad ogni componenteun tipo utilizzabile all’interno della configurazione della Porta di Dominio. I seguenti paragrafi descriveranno come realizzarecomponenti personalizzati.












32 / 84

3.3.3.1 Implementazione personalizzata del servizio Consegna Contenuti Applicativi

Un connettore viene utilizzato dalla porta di dominio per la consegna dei contenuti applicativi o per l’inoltro di buste e-Gov.Implementa un protocollo di trasporto su cui inoltrare un messaggio destinato ad un servizio applicativo o ad una porta didominio. Per ulteriori dettagli vedi Guida Utente XML: Connettore

Un connettore può essere definito semplicemente implementando l’interfaccia definita nella distribuzione in /src/org/opensp-coop/pdd/core/connettori/IConnettore.java. La classe personalizzata, una volta creata, deve essere registrata nel file deploy/pd-d/properties/className.properties inserendo una proprietà, dopo la lista dei connettori built-in forniti con la Porta di DominioOpenSPCoop:

# ------------- Connettori ----------# connettore httporg.openspcoop.connettore.http=org.openspcoop.pdd.core.connettori.ConnettoreHTTP# connettore httpsorg.openspcoop.connettore.https=org.openspcoop.pdd.core.connettori.ConnettoreHTTPS# connettore jmsorg.openspcoop.connettore.jms=org.openspcoop.pdd.core.connettori.ConnettoreJMS# connettore saajorg.openspcoop.connettore.saaj=org.openspcoop.pdd.core.connettori.ConnettoreSAAJ# connettore nullorg.openspcoop.connettore.null=org.openspcoop.pdd.core.connettori.ConnettoreNULL# connettore nullEchoorg.openspcoop.connettore.nullEcho=org.openspcoop.pdd.core.connettori.ConnettoreNULLEcho# connettore personalizzatoorg.openspcoop.connettore.tipo_connettore_personalizzato=package.personalizzato. ←↩

ImplementazioneConnettorePersonalizzato

La classe package.personalizzato.ImplementazioneConnettorePersonalizzato può quindi essere referenziata come tipo di connet-tore, all’interno della configurazione della porta di dominio, semplicemente usando la keyword tipo_connettore_personalizzato.

3.3.3.2 Autenticazione personalizzata dei Servizi Applicativi

Il meccanismo di autenticazione dei servizi applicativi, viene utilizzato dalla Porta di Dominio per comprendere l’identità delservizio applicativo fruitore che sta invocando la porta delegata. Per ulteriori dettagli vedi Guida Utente XML: Funzionalità diIntegrazione, autenticazione dei servizi applicativi

Un meccanismo di autenticazione dei servizi applicativi può essere definito semplicemente implementando l’interfaccia defini-ta nella distribuzione in /src/org/openspcoop/pdd/core/autenticazione/IAutenticazione.java. La classe personalizzata, una vol-ta creata, deve essere registrata nel file deploy/pdd/properties/className.properties inserendo una proprietà, dopo la lista deimeccanismi di autenticazione built-in forniti con la Porta di Dominio OpenSPCoop:

# ------------- Autenticazione ----------# autenticazione basicorg.openspcoop.autenticazione.basic=org.openspcoop.pdd.core.autenticazione. ←↩

AutenticazioneBASIC# autenticazione sslorg.openspcoop.autenticazione.ssl=org.openspcoop.pdd.core.autenticazione.AutenticazioneSSL# autenticazione personalizzataorg.openspcoop.autenticazione.tipo_autenticazione_sa_personalizzata=package.personalizzato. ←↩

ImplementazioneAutenticazioneSAPersonalizzata

La classe package.personalizzato.ImplementazioneAutenticazioneSAPersonalizzata può quindi essere referenziata come tipo diautenticazione dei servizi applicativi, all’interno della configurazione della porta di dominio, semplicemente usando la keywordtipo_autenticazione_sa_personalizzata.

3.3.3.3 Autorizzazione personalizzata dei Servizi Applicativi

Il meccanismo di autorizzazione, viene utilizzato dalla Porta di Dominio per permettere ai soli servizi applicativi autorizzatidi invocare una porta delegata. Per ulteriori dettagli vedi Guida Utente XML: Funzionalità di Integrazione, autorizzazione deiservizi applicativi

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s03.html#connettore

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s05.html#autenticazioneServApp

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s05.html#autenticazioneServApp

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s05.html#autorizzazioneServApp

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s05.html#autorizzazioneServApp


33 / 84

Un meccanismo di autorizzazione dei servizi applicativi può essere definito semplicemente implementando l’interfaccia defi-nita nella distribuzione in /src/org/openspcoop/pdd/core/autorizzazione/IAutorizzazione.java. La classe personalizzata, una vol-ta creata, deve essere registrata nel file deploy/pdd/properties/className.properties inserendo una proprietà, dopo la lista deimeccanismi di autorizzazione built-in forniti con la Porta di Dominio OpenSPCoop:

# ------------- Autorizzazione ----------# autorizzazione OpenSPCooporg.openspcoop.autorizzazione.openspcoop=org.openspcoop.pdd.core.autorizzazione. ←↩

AutorizzazioneOpenSPCoop# autorizzazione personalizzataorg.openspcoop.autorizzazione.tipo_autorizzazione_sa_personalizzata=package.personalizzato. ←↩

ImplementazioneAutorizzazioneSAPersonalizzata

La classe package.personalizzato.ImplementazioneAutorizzazioneSAPersonalizzata può quindi essere referenziata come tipo diautorizzazione dei servizi applicativi, all’interno della configurazione della porta di dominio (Porta Delegata), semplicementeusando la keyword tipo_autorizzazione_sa_personalizzata.

3.3.3.4 Autorizzazione Contenuti dei Servizi Applicativi

Il meccanismo di autorizzazione dei contenuti, viene utilizzato dalla Porta di Dominio per verificare il contenuto applicativoutilizzato dai servizi applicativi al momento dell’invocazione di una porta delegata. Per ulteriori dettagli su come associareil tipo di autorizzazione-contenuti alla Porta Delegata vedi Guida Utente XML: Configurazione XML della Porta di DominioOpenSPCoop, Porta Delegata

Un meccanismo di autorizzazione dei contenuti inviato dai servizi applicativi può essere definito semplicemente implementan-do l’interfaccia definita nella distribuzione in /src/org/openspcoop/pdd/core/autorizzazione/IAutorizzazioneContenuto.java. Laclasse personalizzata, una volta creata, deve essere registrata nel file deploy/pdd/properties/className.properties inserendo unaproprietà, dopo la lista dei meccanismi di autorizzazione per contenuto built-in forniti con la Porta di Dominio OpenSPCoop(meccanismi built-in forniti solo come esempio di implementazione di tale interfaccia e non utilizzabili in contesti reali):

# ------------ Autorizzazione per contenuto dei Servizi Applicativi -----------# autorizzazione esempio OKorg.openspcoop.autorizzazioneContenuto.esempioOK=org.openspcoop.pdd.core.autorizzazione. ←↩

AutorizzazioneContenutoOK# autorizzazione esempio KOorg.openspcoop.autorizzazioneContenuto.esempioKO=org.openspcoop.pdd.core.autorizzazione. ←↩

AutorizzazioneContenutoKO# autorizzazione personalizzataorg.openspcoop.autorizzazioneContenuto.tipo_autorizzazione_contenuto_personalizzata=package ←↩

.personalizzato.ImplementazioneAutorizzazioneContenutoPersonalizzata

La classe package.personalizzato.ImplementazioneAutorizzazioneContenutoPersonalizzata può quindi essere referenziata cometipo di autorizzazione-contenuto dei servizi applicativi, all’interno della configurazione della porta di dominio (Porta Delegata),semplicemente usando la keyword tipo_autorizzazione_contenuto_personalizzata.

3.3.3.5 Autorizzazione personalizzata buste eGov in ingresso

Il meccanismo di autorizzazione, viene utilizzato dalla Porta di Dominio per permettere ai soli soggetti spcoop autorizzati di invo-care un servizio spcoop erogato sulla porta. Per ulteriori dettagli vedi Guida Utente XML: Funzionalità Avanzate, Autorizzazionedelle buste eGov in ingresso

Un meccanismo di autorizzazione delle buste e-Gov può essere definito semplicemente implementando l’interfaccia definitanella distribuzione in /src/org/openspcoop/pdd/core/autorizzazione/IAutorizzazioneSPCoop.java. La classe personalizzata, unavolta creata deve essere registrata nel file deploy/pdd/properties/className.properties inserendo una proprietà, dopo la lista deimeccanismi di autorizzazione built-in forniti con la Porta di Dominio OpenSPCoop:

# ------------ Autorizzazione SPCoop -----------# autorizzazione spcooporg.openspcoop.autorizzazioneSPCoop.spcoop=org.openspcoop.pdd.core.autorizzazione. ←↩

AutorizzazioneSPCoopRegistro






34 / 84

# autorizzazione pddConsoleorg.openspcoop.autorizzazioneSPCoop.pddConsole=org.openspcoop.pdd.core.autorizzazione. ←↩

AutorizzazionePdDConsole# autorizzazione personalizzataorg.openspcoop.autorizzazioneSPCoop.tipo_autorizzazione_personalizzata=package. ←↩

personalizzato.ImplementazioneAutorizzazionePersonalizzata

La classe package.personalizzato.ImplementazioneAutorizzazionePersonalizzata può quindi essere referenziata come tipo di au-torizzazione delle buste e-Gov, all’interno della configurazione della porta di dominio (vedi Sezione 3.3.1.10), semplicementeusando la keyword tipo_autorizzazione_personalizzata.

3.3.3.6 Autorizzazione Contenuti delle buste eGov in ingresso

Il meccanismo di autorizzazione dei contenuti, viene utilizzato dalla Porta di Dominio per verificare il contenuto applicativopresente nelle buste e-Gov in ingresso sulla porta applicativa. Per ulteriori dettagli su come associare il tipo di autorizzazione-contenuti alla Porta Applicativa vedi Guida Utente XML: Configurazione XML della Porta di Dominio OpenSPCoop, PortaApplicativa

Un meccanismo di autorizzazione del contenuto presente nelle buste eGov può essere definito semplicemente implementandol’interfaccia definita nella distribuzione in /src/org/openspcoop/pdd/core/autorizzazione/IAutorizzazioneContenutoSPCoop.java.La classe personalizzata, una volta creata, deve essere registrata nel file deploy/pdd/properties/className.properties inserendouna proprietà, dopo la lista dei meccanismi di autorizzazione per contenuto built-in forniti con la Porta di Dominio OpenSPCoop(meccanismi built-in forniti solo come esempio di implementazione di tale interfaccia e non utilizzabili in contesti reali):

# ------------ Autorizzazione SPCoop per contenuto -----------# autorizzazione esempio OKorg.openspcoop.autorizzazioneContenutoSPCoop.esempioOK=org.openspcoop.pdd.core. ←↩

autorizzazione.AutorizzazioneContenutoSPCoopOK# autorizzazione esempio KOorg.openspcoop.autorizzazioneContenutoSPCoop.esempioKO=org.openspcoop.pdd.core. ←↩

autorizzazione.AutorizzazioneContenutoSPCoopKO# autorizzazione personalizzata

org.openspcoop.autorizzazioneContenutoSPCoop. ←↩tipo_autorizzazione_contenuto_egov_personalizzata=package.personalizzato. ←↩ImplementazioneAutorizzazioneContenutoEGovPersonalizzata

La classe package.personalizzato.ImplementazioneAutorizzazioneContenutoEGovPersonalizzata può quindi essere referenziatacome tipo di autorizzazione-contenuto portato nelle buste e-Gov, all’interno della configurazione della porta di dominio (PortaApplicativa), semplicemente usando la keyword tipo_autorizzazione_contenuto_egov_personalizzata.

3.3.3.7 Header di Integrazione dei Servizi Applicativi personalizzati

Un Servizio Applicativo può dover passare/ricevere informazioni SPCoop dalla Porta di Dominio ad esempio per la gestione deiprofili asincroni. L’interscambio di informazioni viene attuato tramite header di integrazione di diverse tipologie con lo scopo dipermettere lo scambio nella maniera più consona all’implementazione del servizio applicativo. Per ulteriori dettagli vedi GuidaUtente XML: Funzionalità Integrazione, header di integrazione per i servizi applicativi e Sezione 3.3.1.9

Gli header di integrazione si differenziano in due tipologie;

• ServiziApplicativi -> PdD (PortaDelegata), header utilizzati dai servizi applicativi, al momento dell’invocazione della portadelegata, per fornire informazioni di integrazioni alla porta di dominio. Tali header possono essere definiti implementandol’interfaccia in /src/org/openspcoop/pdd/integrazione/IGestoreIntegrazionePDSoap.java.

• PdD -> ServiziApplicativi (PortaApplicativa), header utilizzati dalla porta di dominio, al momento dell’invocazione del servi-zio applicativo, per fornirgli informazioni di integrazione. Tali header possono essere definiti implementando l’interfaccia in/src/org/openspcoop/pdd/integrazione/IGestoreIntegrazionePASoap.java.

Le classi personalizzate, una volta create devono essere registrate nel file deploy/pdd/properties/className.properties inserendouna proprietà, dopo la lista degli header di integrazione built-in forniti con la Porta di Dominio OpenSPCoop:



http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s05.html#integrazioneHeaderServiziApplicativi

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s05.html#integrazioneHeaderServiziApplicativi


35 / 84

# ------------- Integrazione tra Servizi Applicativi e PdD ----------org.openspcoop.integrazione.pd.trasporto=org.openspcoop.pdd.core.integrazione. ←↩

GestoreIntegrazionePDTrasportoorg.openspcoop.integrazione.pd.urlBased=org.openspcoop.pdd.core.integrazione. ←↩

GestoreIntegrazionePDUrlBasedorg.openspcoop.integrazione.pd.soap=org.openspcoop.pdd.core.integrazione. ←↩

GestoreIntegrazionePDSoaporg.openspcoop.integrazione.pd.wsa=org.openspcoop.pdd.core.integrazione. ←↩

GestoreIntegrazionePDWSAddressing# integrazione personalizzataorg.openspcoop.integrazione.pd.tipo_integrazione_pd_personalizzata=package.personalizzato. ←↩

ImplementazioneIntegrazionePersonalizzataPD

# ------------ Integrazione tra PdD e Servizi Applicativiorg.openspcoop.integrazione.pa.trasporto=org.openspcoop.pdd.core.integrazione. ←↩

GestoreIntegrazionePATrasportoorg.openspcoop.integrazione.pa.urlBased=org.openspcoop.pdd.core.integrazione. ←↩

GestoreIntegrazionePAUrlBasedorg.openspcoop.integrazione.pa.soap=org.openspcoop.pdd.core.integrazione. ←↩

GestoreIntegrazionePASoaporg.openspcoop.integrazione.pa.wsa=org.openspcoop.pdd.core.integrazione. ←↩

GestoreIntegrazionePAWSAddressing# integrazione personalizzataorg.openspcoop.integrazione.pa.tipo_integrazione_pa_personalizzata=package.personalizzato. ←↩

ImplementazioneIntegrazionePersonalizzataPA

Le classi package.personalizzato.ImplementazioneIntegrazionePersonalizzataPD e ImplementazioneIntegrazionePersonalizzata-PA possono quindi essere referenziatate come tipo di header di integrazione all’interno della configurazione della porta di domi-nio, semplicemente usando le proprie keyword tipo_integrazione_pd_personalizzata e tipo_integrazione_pa_personalizzata.

3.3.3.8 OpenSPCoopAppender personalizzato per i Messaggi Diagnostici

Un OpenSPCoopAppender permette di memorizzare le informazioni portate nei messaggi diagnostici emessi dalla porta didominio, con l’aggiunta di informazioni aggiuntive inerenti alla cooperazione. Per ulteriori dettagli vedi Sezione 3.3.2.1

Un OpenSPCoopAppender dedicato alla memorizzazione dei messaggi diagnostici può essere definito semplicemente implemen-tando l’interfaccia definita nella distribuzione in /src/org/openspcoop/pdd/logger/IMsgDiagnosticoOpenSPCoopAppender.java.La classe personalizzata, una volta creata, deve essere registrata nel file deploy/pdd/properties/className.properties inserendouna proprietà, dopo la lista degli openspcoop appender built-in forniti con la Porta di Dominio OpenSPCoop:

# ----------- MsgDiagnostico Appender Personalizzati ----------org.openspcoop.msgdiagnosticoAppender.dbDiagnosticoAppender=org.openspcoop.pdd.logger. ←↩

MsgDiagnosticoOpenSPCoopAppenderDB# openspcoop appender personalizzatoorg.openspcoop.msgdiagnosticoAppender.tipo_appender_personalizzato_msg_diagnostici=package. ←↩

personalizzato.ImplementazioneMsgDiagnosticoAppenderPersonalizzato

La classe package.personalizzato.ImplementazioneMsgDiagnosticoAppenderPersonalizzato può quindi essere referenziata cometipo di openspcoop appender per i messaggi diagnostici all’interno della configurazione della porta di dominio (vedi Sezio-ne 3.3.2.1), semplicemente usando la keyword tipo_appender_personalizzato_msg_diagnostici.

3.3.3.9 OpenSPCoopAppender personalizzato per le Tracce

Un OpenSPCoopAppender permette di memorizzare le informazioni portate nelle tracce emesse dalla porta di dominio, conl’aggiunta di informazioni aggiuntive inerenti alla cooperazione. Per ulteriori dettagli vedi Sezione 3.3.2.2

Un OpenSPCoopAppender dedicato alla memorizzazione delle tracce può essere definito semplicemente implementando l’inter-faccia definita nella distribuzione in /src/org/openspcoop/pdd/logger/ITracciamentoOpenSPCoopAppender.java. La classe per-sonalizzata, una volta creata, deve essere registrata nel file deploy/pdd/properties/className.properties inserendo una proprietà,dopo la lista degli openspcoop appender built-in forniti con la Porta di Dominio OpenSPCoop:


36 / 84

# ----------- Tracciamento Appender Personalizzati ----------org.openspcoop.tracciamentoAppender.dbTracciamentoAppender=org.openspcoop.pdd.logger. ←↩

TracciamentoOpenSPCoopAppenderDB# openspcoop appender personalizzatoorg.openspcoop.tracciamentoAppender.tipo_appender_personalizzato_tracce=package. ←↩

personalizzato.ImplementazioneTracciamentoAppenderPersonalizzato

La classe package.personalizzato.ImplementazioneTracciamentoAppenderPersonalizzato può quindi essere referenziata cometipo di openspcoop appender per le tracce all’interno della configurazione della porta di dominio (vedi Sezione 3.3.2.2), sempli-cemente usando la keyword tipo_appender_personalizzato_tracce.

3.3.3.10 Implementazione personalizzata del servizio Ricezione Contenuti Applicativi

Un servizio di ricezione contenuti applicativi può essere implementato seguendo il seguente schema Java:

org.apache.axis.Message messaggioDiRichiesta = prelevato/costruito dal punto di ingresso ←↩personalizzato

// Parametri della porta delegata invocataParametriPortaDelegata parPD = new ParametriPortaDelegata();parPD.setLocation(nomePortaDelegata);parPD.setUrlInvocazionePD(urlDiInvocazione); // utile per identificazioni url-BasedparPD.setParameters(parametriNomeValore); // utile per identificazioni url-Based stile formparPD.setParametersTrasporto(parametriNomeValoreTrasporto); // utile per profili asincroni

// Credenziali utilizzate nella richiestaCredenziali credenziali = new Credenziali();// es. Basiccredenziali.setUsername(username);credenziali.setPassword(password);

// Contesto di RichiestaRicezioneContenutiApplicativiContext context = new RicezioneContenutiApplicativiContext();context.setCredenziali(credenziali);context.setIdModulo(ID_MODULO); // ID_MODULO, deve iniziare col prefisso ←↩

RicezioneContenutiApplicativicontext.setGestioneRisposta(true); // true se deve essere ritornato un SoapMessage di ←↩

risposta, false altrimenticontext.setInvocazionePDPerRiferimento(false); // true se deve essere effettuata una ←↩

invocazione per riferimento, false altrimenticontext.setMessage(messaggioDiRichiesta);context.setParPD(parPD);

// Invocazione...RicezioneContenutiApplicativi gestoreRichiesta = new RicezioneContenutiApplicativi(context) ←↩

;org.apache.axis.Message risposta = gestoreRichiesta.process();String spcoopID = context.getSPCoopID(); // id eGov della richiesta processata

Esempi di implementazione di servizi di Ricezione Contenuti Applicativi sono le classi:

• org.openspcoop.pdd.services.RicezioneContenutiApplicativiDirect

• org.openspcoop.pdd.services.RicezioneContenutiApplicativiWS

• org.openspcoop.pdd.services.RicezioneContenutiApplicativiHTTPtoSOAP


37 / 84

3.3.3.11 Threshold personalizzati per il controllo delle risorse

È possibile fornire controlli personalizzati sulla disponibilità di risorse per la gestione di ulteriori richieste applicative e/o busteeGov. Per ulteriori dettagli vedi Sezione 3.3.1.6.

Un Threshold personalizzato può essere definito semplicemente implementando l’interfaccia definita nella distribuzione in /sr-c/org/openspcoop/pdd/threshold/IThreshold.java. La classe personalizzata, una volta creata, deve essere registrata nel file de-ploy/pdd/properties/className.properties inserendo una proprietà, dopo la lista dei threshold built-in forniti con la Porta diDominio OpenSPCoop:

# ------------ Threshold -------------org.openspcoop.threshold.mysqlFreeSpace=org.openspcoop.pdd.core.threshold.MySQLThresholdorg.openspcoop.threshold.postgresUsedSpace=org.openspcoop.pdd.core.threshold. ←↩

PostgreSQLThreshold# threshold personalizzatoorg.openspcoop.threshold.tipo_threshold_personalizzato=package.personalizzato. ←↩

ImplementazioneThresholdPersonalizzato

La classe package.personalizzato.ImplementazioneThresholdPersonalizzato può quindi essere referenziata come tipo di thre-shold all’interno della configurazione della porta di dominio (vedi Sezione 3.3.1.6), semplicemente usando la keyword ti-po_threshold_personalizzato.

3.3.3.12 Marcatura personalizzata delle Buste nel repository e-Gov

Il meccanismo di marcatura delle buste e-Gov influenza la gestione del repository delle buste e-Gov. Per ulteriori dettagli vediSezione 3.3.1.11.

Un meccanismo personalizzato può essere definito semplicemente implementando l’interfaccia definita nella distribuzione in/src/org/openspcoop/egov/IGestoreRepositoryEGov.java. La classe personalizzata, una volta creata, deve essere registrata nelfile deploy/pdd/properties/className.properties inserendo una proprietà, dopo la lista dei marcatori built-in forniti con la Portadi Dominio OpenSPCoop:

# ----------- Gestore Repository EGov ----------------------org.openspcoop.repositoryEGov.default=org.openspcoop.egov.GestoreRepositoryEGovDefaultorg.openspcoop.repositoryEGov.bytewise=org.openspcoop.egov.GestoreRepositoryEGovBytewiseorg.openspcoop.repositoryEGov.oracle=org.openspcoop.egov.GestoreRepositoryEGovOracle# marcatore personalizzatoorg.openspcoop.repositoryEGov.tipo_marcatore_personalizzato=package.personalizzato. ←↩

ImplementazioneMarcatoreRepositoryEGOVPersonalizzato

La classe package.personalizzato.ImplementazioneMarcatoreRepositoryEGOVPersonalizzato può quindi essere referenziata co-me tipo di marcatore all’interno della configurazione della porta di dominio (vedi Sezione 3.3.1.11), semplicemente usando lakeyword tipo_marcatore_personalizzato.

3.3.3.13 Sincronizzazione temporale personalizzata

È possibile personalizzare la sorgente temporale utilizzata dalla Porta di Dominio descritta in Sezione 3.3.1.14

Un meccanismo personalizzato può essere definito semplicemente implementando l’interfaccia definita nella distribuzione in/src/org/openspcoop/utils/date/IDate.java. La classe personalizzata, una volta creata, deve essere registrata nel file deploy/pd-d/properties/className.properties inserendo una proprietà, dopo la lista delle sorgenti temporali built-in forniti con la Porta diDominio OpenSPCoop:

# ----------- Date -------------------------------------org.openspcoop.date.system=org.openspcoop.utils.date.SystemDateorg.openspcoop.date.java=org.openspcoop.utils.date.JavaDateorg.openspcoop.date.ntp=org.openspcoop.utils.date.NTPDateorg.openspcoop.date.tcpTime=org.openspcoop.utils.date.TCPTimeDateorg.openspcoop.date.udpTime=org.openspcoop.utils.date.UDPTimeDate# sorgente personalizzata


38 / 84

org.openspcoop.date.tipo_sorgente_personalizzata=package.personalizzato. ←↩ImplementazioneDatePersonalizzata

La classe package.personalizzato.ImplementazioneDatePersonalizzata può quindi essere referenziata come tipo di sorgente tem-porale all’interno della configurazione della porta di dominio (vedi Sezione 3.3.1.14), semplicemente usando la keyword ti-po_sorgente_personalizzata.

3.3.4 Interoperabilità rispetto ad altre implementazioni di Porta di Dominio

Per allinearsi al documento Sistema Pubblico di Cooperazione: Linee Guida all’uso della Busta EGov 1.1 , dalla versione 1.1è stato introdotto il concetto di profilo del soggetto con cui si deve cooperare, come descritto in Realese Notes: Versione 1.1,Nuove Linee Guida per l’uso della Busta e-Gov . La porta di dominio OpenSPCoop può essere configurata tramite il registro deiservizi per poter interoperare con Porte di Dominio che sono conforme alle nuove linee guida per la certificazione, ma anche conporte di dominio che non si sono ancora allineate alle nuove specifiche.

Il documento di specifica Sistema Pubblico di Cooperazione: Linee Guida all’uso della Busta EGov 1.1 ha eliminato diversedisambiguità presenti nelle precedenti versioni della specifica (Sistema Pubblico di Cooperazione: Busta EGov 1.1 ). Ciò nono-stante, nei contesti in cui si deve cooperare con porte di dominio che non si sono ancora allineate alle linee guida, potrebberoessere presenti tali disambiguità. La Porta di Dominio OpenSPCoop permette di affrontare tali disambiguità agendo sulle pro-prietà definite in Sezione 3.3.1 in modo da configurare il comportamente della Porta di Dominio per adeguarne l’interoperabilitàcon la porta di dominio con cui si deve cooperare. L’aspetto negativo di questa configurazione, però, è dovuto al fatto che laconfigurazione riflette in tutte le cooperazioni che verranno intraprese dalla porta di dominio in modalità non linee guida. Quindise abbiamo due porte di dominio diverse con cui interoperare (non ancora allineate alle linee guida), che presentano lo stessoproblema di interoperabilità, ma soluzione diversa, come fare?

In questi contesti è possibile personalizzare il comportamento della nostra porta di dominio, in funzione della porta di dominiocon cui si deve interoperare. Per farlo è necessario configurare nel registro dei servizi la porta di domimio con cui si deve coo-perare, e associarla al soggetto che gestisce. Nella configurazione della porta di dominio deve essere specificato nell’elementoimplementazione una keyword che la identifica (es. OraclePDD). Dopodichè è possibile indicare nel file presente in deploy/pd-d/properties/pdd.properties le proprietà della configurazione che si vuole ridefinire quando si deve interoperare con la porta didominio indicata dalla keyword. Le proprietà ridefinibili riguardano:

• Validazione Buste e-Gov, è possibile ridefinire la validazione e-Gov della configurazione delle porta di dominio, descritta inGuida Utente XML della Porta di Dominio: Configurazione, validazione e-Gov :

– stato, ridefinibile tramite la proprietà @[email protected]=abilitato/disabilitato/warningOnly

– controllo, ridefinibile tramite la proprietà @[email protected]=normale/rigido

– profiloCollaborazione, ridefinibile tramite la proprietà @[email protected]=abilitato/disabilitato

– manifestAttachments, ridefinibile tramite la proprietà @[email protected]=abilitato/disabilitato

Inoltre è possibile anche ridefinire le seguenti proprietà descritte in Sezione 3.3.1.11 riguardanti la validazione della bustae-Gov:

– org.openspcoop.egov.filtroDuplicati.letturaRegistro, ridefinibile tramite la proprietà @[email protected]=true/false

– org.openspcoop.egov.confermaRicezione.letturaRegistro, ridefinibile tramite la proprietà @Implementazione@.validazioneEGov.confermaRicezione.letturaRegistro=true/false

– org.openspcoop.egov.consegnaInOrdine.letturaRegistro, ridefinibile tramite la proprietà @Implementazione@.validazioneEGov.consegnaInOrdine.letturaRegistro=true/false

– org.openspcoop.egov.validazione.readQualifiedAttribute, ridefinibile tramite la proprietà @[email protected]=true/false

– org.openspcoop.egov.validazione.idegov.validazioneCompleta, ridefinibile tramite la proprietà @[email protected]=true/false

• Generazione Buste e-Gov, è possibile definire come vengono prodotti dalla Porta di Dominio alcuni elementi della busta e-Gov,ridefinendo le proprietà descritte in Sezione 3.3.1.11:

– org.openspcoop.egov.asincroni.attributiCorrelati.enable, ridefinibile tramite la proprietà @[email protected]=true/false

– org.openspcoop.egov.collaborazione.enable, ridefinibile tramite la proprietà @[email protected]=true/false

– org.openspcoop.egov.consegnaInOrdine.enable, ridefinibile tramite la proprietà @[email protected]=true/false

– org.openspcoop.egov.trasmissione.enable, ridefinibile tramite la proprietà @[email protected]=true/false


http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=relnotes&rel=1.4&id=ar01s03.html#lineeGuida




http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s03.html#validazioneEGov


39 / 84

– org.openspcoop.egov.riscontri.enable, ridefinibile tramite la proprietà @[email protected]=true/false– org.openspcoop.egov.filtroduplicati.generazioneSPCoopErrore, ridefinibile tramite la proprietà @Implementazione@.bustaEGov.filtroduplicati.generazioneSPCoopErrore=true/false– org.openspcoop.egov.manifestAttachments.role.richiesta, ridefinibile tramite la proprietà @[email protected]=ValoreDesiderato– org.openspcoop.egov.manifestAttachments.role.risposta, ridefinibile tramite la proprietà @[email protected]=ValoreDesiderato– org.openspcoop.egov.manifestAttachments.role.allegato, ridefinibile tramite la proprietà @[email protected]=ValoreDesiderato

Inoltre, sempre riguardante la generazione della busta e-gov è ridefinibile la proprietà org.openspcoop.pdd.tempo.tipo, descrittain Sezione 3.3.1.14, tramite la proprietà @[email protected]=spc/locale .

• Validazione contenuti applicativi, è possibile definire come deve essere effettuata la validazione dei contenuti applicativi de-scritta in Guida Utente XML della Porta di Dominio: Configurazione, validazione contenuti applicativi e Guida Utente dellaPorta di Dominio: Funzionalità avanzate, validazione XSD :

– stato, ridefinibile tramite la proprietà @[email protected]=abilitato/disabilitato/warningOnly– tipo, ridefinibile tramite la proprietà @[email protected]=wsdl/openspcoop/xsd

• WS-Security, è possibile definire come deve essere gestito il protocollo di WS-Security ridefinendo le proprietà descritte inSezione 3.3.1.9:

– org.openspcoop.pdd.wssecurity.actorDefault.enable, ridefinibile tramite la proprietà @[email protected]=true– org.openspcoop.pdd.wssecurity.actorDefault.valore, ridefinibile tramite la proprietà @[email protected]=ValoreDesiderato

4 Registro dei Servizi

Attualmente OpenSPCoop mette a disposizione quattro versioni del registro dei servizi (vedi Manuale Registro dei Servizi ):

• Registro dei Servizi XML, il registro è realizzato tramite un singolo file xml.

• Registro dei Servizi DB, il registro è realizzata come un database relazionale.

• Registro dei Servizi WEB, il registro è realizzato come un sito web che mantiene un insieme di oggetti descritti in xml eaccessibili via http.

• Registro dei Servizi UDDI, il registro è realizzato tramite un registro in tecnologia UDDI che indicizza un insieme di oggettidescritti in xml, mantenuti in un repository accessibile via http.

La versione XML del Registro dei Servizi, descritta nella Guida Utente XML , non viene descritta ulteriormente in questa sezione,poichè non richiede alcun tipo di compilazione dei sorgenti e installazione, al di fuori del copiare il file XML nella directory diconfigurazione della porta di dominio, operazione descritta anche nel quick start in Sezione 3.2.6.

Le altre versioni del registro dei servizi sono gestibili tramite un’interfaccia web descritta in questa sezione. L’interfaccia creagli oggetti sempre sul registro dei servizi basato su DBMS e inoltre, se configurata, i dati vengono inoltrati al registro dei serviziWEB o UDDI.

Infine qualsiasi tipologia del registro dei servizi può essere estesa tramite una interfaccia WebService, descritta in (InterfacciaWS per il Registro dei Servizi ).

4.1 Interfaccia Web del Registro dei Servizi

4.1.1 Compilazione dei sorgenti

4.1.1.1 Interfaccia Web per Application Server J2EE

I sorgenti dell’interfaccia web del registro dei servizi sono disponibili all’interno della distribuzione nella directory tools/-web_interfaces/regserv/src. Per procedere con la compilazione è necessario utilizzare l’utility Ant sul path tools/web_interfaces/regserv,eseguendo il seguente comando:

ant clean build

La compilazione produce come risultato un archivio regserv.war all’interno della directory dist installabile in un applicationserver J2EE.

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s03.html#validazione-contenuti-applicativi



http://www.openspcoop.org/openspcoop_v3/jsp?sel=doc-file&guida=registro&rel=1.4&id=index.html





40 / 84

4.1.1.2 Interfaccia Web per Servlet Container

I sorgenti dell’interfaccia web del registro dei servizi sono disponibili all’interno della distribuzione nella directory tools/-web_interfaces/regserv/src. Per procedere con la compilazione è necessario utilizzare l’utility Ant sul path tools/web_interfaces/regserv,eseguendo il seguente comando:

ant clean build_tomcat

La compilazione produce come risultato un archivio regserv.war all’interno della directory dist installabile in un servlet container.

NotaLa versione per Servlet Container non gestisce i registri dei servizi di tipologia WEB e UDDI.

4.1.2 Installazione

I paragrafi di questa sezione descrivono come procedere con l’installazione dell’interfaccia web nell’application server JBoss4.2.X / 5.x o nel servlet container Tomcat 5.x.

L’applicazione viene fornita sotto forma di archivio regserv.war come risultato della compilazione dei sorgenti descritta inSezione 4.1.1.1 e Sezione 4.1.1.2.

4.1.2.1 Configurazione del Database

L’interfaccia web del registro dei servizi richiede l’installazione di un database relazionale nel quale devono essere registrate letabelle utilizzate per la raccolta degli accordi di servizio e soggetti. Attualmente lo sviluppo di OpenSPCoop viene effettuato sutre tipi di database: Postgres v8, MySQL v5 e Oracle10gExpress.

Le tabelle SQL richieste dall’interfaccia web sono descritte all’interno del file tools/web_interfaces/regserv/deploy/sql/TIPO_DATABASE/RegistroServizi.sql.

NotaL’interfaccia deve possedere i diritti per leggere ed inserire elementi nelle tabelle.


1. Creazione Utente

[user@localhost]$ suParola d’ordine: XXX[root@localhost]# su - postgres-bash-3.1$ createuser -PEnter name of role to add: regservEnter password for new role: regservConferma password: regservShall the new role be a superuser? (y/n) nShall the new role be allowed to create databases? (y/n) nShall the new role be allowed to create more new roles? (y/n) nCREATE ROLE


[user@localhost]$ suParola d’ordine: XXX[root@localhost]# su - postgres-bash-3.1$createdb -O regserv regservCREATE DATABASE


41 / 84

3. Abilitazione accesso dell’utente al Database, è possibile abilitare l’accesso editando il file /var/lib/pgsql/data/pg_hba.conf(come super utente). Abilitiamo quindi l’utente regserv ad accedere al db regserv, aggiungendo le seguenti righe al file:

local regserv regserv md5host regserv regserv 127.0.0.1 255.255.255.255 md5


[user@localhost]$ psql regserv regserv < tools/web_interfaces/regserv/deploy/sql/ ←↩TIPO_DATABASE/RegistroServizi.sql

Password for user regserv: regserv


4.1.2.2 Pool di Connessioni

L’interfaccia web richiede l’installazione di un pool di connessioni verso il DBMS che possieda come nome JNDI: org.openspcoop.dataSource.regserv.

Un datasource di esempio per l’application server JBoss viene fornito in tools/web_interfaces/regserv/deploy/datasource/jboss/regserv-ds.xml. Il file permette di creare la risorsa nella propria installazione dell’A.S., attraverso la configurazione e la successiva copiadel file in JBOSS_DIR/server/default/deploy.


Un datasource di esempio per l’application server Tomcat viene fornito in tools/web_interfaces/regserv/deploy/datasource/tomcat/regserv.xml.Il file permette di creare la risorsa nella propria installazione di Tomcat, attraverso la configurazione e la successiva copia del filein TOMCAT_DIR/Catalina/ (es. /etc/tomcat5/Catalina/localhost/).

NotaPer ulteriori informazioni su come utilizzare un datasource registrato con nome JNDI diverso dal default vedi Sezione 4.1.3.2.


4.1.2.3 Configurazione delle code JMS

L’interfaccia web utilizzabile per ambienti J2EE necessita di alcune code JMS se si vuole utilizzarla per configurare registridei servizi di tipologia WEB e UDDI. Se si sta installando la versione per Servlet Container (Tomcat) non si deve seguire leindicazioni descritte in questo paragrafo.

All’interno della distribuzione nella in tools/web_interfaces/regserv/deploy/code_jms/BROKER/regserv-destinations-service.xmlvengono fornite le configurazioni delle code JMS per la loro creazione in JBoss 4.x e in JBoss 5.x:

• tools/web_interfaces/regserv/deploy/code_jms/jbossMQ/regserv-destinations-service.xml, le code sono istanziabili in JBoss4.x attraverso la copia del file in JBOSSDIR/server/default/deploy/jms

• tools/web_interfaces/regserv/deploy/code_jms/jbossMessaging/regserv-destinations-service.xml, le code sono istanziabili inJBoss 5.x attraverso la copia del file in JBOSSDIR/server/default/deploy/messaging


42 / 84

4.1.2.4 Configurazione Iniziale

L’interfaccia web del Registro dei Servizi di OpenSPCoop è preconfigurato per gestire un database di tipo postgresql e un Registrodei Servizi DB.

Se si desidera cambiare il tipo di database o la tipologia del registro dei servizi si deve agire sui file di proprietà presenti all’internodell’archivio: regserv.war/WEB-INF/classes.

Per ulteriori dettagli su come modificare il tipo di database è possibile vedere Sezione 4.1.3.2.

Per ulteriori dettagli su come modificare la tipologia di registro dei servizi gestito dall’interfaccia è possibile vedere Sezio-ne 4.1.3.1.

4.1.2.5 Deploy del Software

Per la versione J2EE è sufficiente copiare il file dist/regserv.war nella directory di deploy dell’application server: JBOSS_DIR/server/ISTANZA/deploy(es. /var/lib/jbossas/server/default/deploy).

Per la versione ServletContainer è sufficiente copiare il file dist/regserv.war nella directory di deploy del servlet container:TOMCAT_DIR/webapps (es. /var/lib/tomcat5/webapps).

Una volta effettuato il deploy, l’applicazione dovrebbe essere disponibile all’indirizzo:

• http://localhost:8080/regserv/login.do

Per effettuare il login di accesso è possibile utilizzare come login amministratore e come password secret. Una volta accedutiall’interfaccia sarà possibile cambiare la password dell’amministratore.

L’applicazione produce dei log che registrano le operazioni effettuate nel file /var/openspcoop/log/InterfacciaRegistro.log. Perulteriori informazioni su come personalizzare i log vedi Sezione 4.1.3.4.

NotaI SQL utilizzati per l’installazione dell’interfaccia grafica hanno creato un utente amministratore che possiede un profilo divisualizzazione linee guida 1.1 (per ulteriori dettagli vedi Realese Notes: Versione 1.1, Nuove Linee Guida per l’uso dellaBusta e-Gov ). Accedendo con tale utente verranno visualizzate solo le informazioni utili per la gestione di servizi SPCoopconformi al documento Sistema Pubblico di Cooperazione: Linee Guida all’uso della Busta EGov 1.1 . Se si desidera avereuna visualizzazione completa è possibile agire sulla tipologia dell’utente nella sezione Configurazione -> Utente -> TipologiaInterfaccia.

4.1.3 Configurazione

L’interfaccia web del Registro dei Servizi di OpenSPCoop è preconfigurato per gestire un database di tipo postgresql e un Registrodei Servizi DB. Il prodotto è tuttavia altamente configurabile agendo sui file di proprietà presenti all’interno dell’archivio inregserv.war/WEB-INF/classes.

In questa sezione verrano descritti alcuni aspetti di configurazione avanzata riguardante:

• Tipologia del Registro dei Servizi

• Accesso al DBMS

• Accesso al broker JMS

• Logging

• Personalizzazione dell’interfaccia





43 / 84

4.1.3.1 Tipologia del Registro dei Servizi

L’applicazione web gestisce per default un Registro dei Servizi DB. Se si vuole modificare la tipologia del registro dei servizi sideve agire sul file di configurazione infoGeneral.cfg. Le proprietà da modificare, all’interno del file di configurazione, variano aseconda della tipologia di registro dei servizi scelto:

• registro basato su db, gli elementi registrati sono mantenuti su un database relazionale; in questo caso non sono necessariulteriori passi di configurazione oltre quelli descritti in Sezione 4.1.3.2;

• registro basato su Web, gli elementi registrati sono mantenuti su un repository web accessibile tramite http; in questo caso, percompletare l’installazione è necessario:

– indicare il tipo di registro impostando la proprietà la proprietà TipoRegistro al valore web.

– creare una coda JMS per le comunicazioni tra l’applicazione e il backend del registro come descritto in Sezione 4.1.2.3indicare il nome della coda tramite la proprietà RegistroQueue (per default: queue/OperazioniGestoreRegserv)configurare il contesto JNDI per poter effettuare la lookup della coda JMS, come descritto in Sezione 4.1.3.3 (per default ilcontesto è correttamente impostato per la ricerca della coda JMS fornita nella distribuzione)

– configurare l’applicazione per la gestione del repository web; l’applicazione deve poter accedere in scrittura a un’area datiesportata via http (tramite un server dedicato, quale ad es. apache, tomcat etc...), dove saranno mantenuti i contenuti delregistro. L’applicazione va configurata indicando come accedere all’area dati tramite le seguenti proprietà:

* WebPathPrefix, corrispondente alla radice dell’area dati in cui mantenere i contenuti del registro

* WebUrlPrefix, corrispondente alla URL con cui tale area dati è raggiungibile via http

• registro basato su UDDI, gli elementi registrati sono mantenuti su un repository web accessibile tramite http e indicizzatitramite un Registro UDDI; in questo caso, per completare l’installazione, oltre ai passi indicati per la configurazione delregistro basato su Web, è anche necessario:

– installare un registro UDDI (OpenSPCoop è stato testato con il prodotto Juddy );

– installare le tassonomie definite in OpenSPCoop, per farlo è sufficiente aggiungere al database creato in fase di installazionedi Juddy, quanto definito nel file deploy/pdd/uddi/tassonomia_openspcoop.sql;

– configurare l’applicazione per la gestione del registro UDDI; l’applicazione viene configurata per poter accedere in pubbli-cazione al registro UDDI, tramite le proprietà UddiInquiryURL, UddiPublishURL, UddiUser e UddiPassword. Esempi divalori validi per la configurazione di default di Juddy sono già presenti, commentati, nel file infoGeneral.cfg.

4.1.3.2 Accesso al DBMS

L’accesso al database dove vengono conservati gli accordi e i soggetti (vedi Sezione 4.1.2.1), viene definito tramite il file diconfigurazione datasource.properties dove viene indicato, tramite la voce dataSource, il nome jndi di un dataSource registratonell’albero JNDI dell’A.S. È possibile fornire informazioni di contesto per la ricerca del dataSource, attraverso una o più vocidataSource.property.*, tramite la definizione di coppie nome/valore dove il nome viene preso al posto del carattere speciale *.(Default: dataSource=org.openspcoop.dataSource.regserv e dataSource.property non definite).

Il tipo di database viene indicato nel file di configurazione infoGeneral.cfg tramite la voce tipoDatabase. I tipi di database gestitisono: postgresql/mysql/oracle (default: postgresql).


Questa configurazione è necessaria solo per una tipologia di registro dei servizi WEB o UDDI.

L’accesso al broker JMS viene indicato, all’interno del file queue.properties, tramite la proprietà ConnectionFactory. Tale pro-prietà indica il nome jndi utilizzato dall’interfaccia web per accedere ad una connection factory registrata nell’albero JNDIdell’A.S. Il pool permetterà di creare connessioni e effettuare lookup verso il broker JMS sul quale è presente la coda descrittain Sezione 4.1.2.3. È possibile fornire informazioni di contesto per la ricerca delle risorse, attraverso una o più voci Connec-tionFactory.property.*, tramite la definizione di coppie nome/valore dove il nome viene preso al posto del carattere speciale *.(Default: ConnectionFactory e ConnectionFactory.property non definite).

http://ws.apache.org/juddi/


44 / 84

4.1.3.4 Logging

L’interfaccia web è configurabile, per quanto riguarda le funzionalità di logging, tramite il file tracer.log4j.properties.

Il sistema di log utilizza il framework Apache Log4J .

Il file contiene delle Category (log4j.category.*) che rappresentano un Logger utilizzato dall’interfaccia per emettere log di uncerto tipo. Ad ogni Category sono associabili uno o più Appender (log4j.appender.*, ad esempio log4j.appender.tracer.file) cherappresentano una risorse su cui memorizzare i log. Le risorse utilizzabili tramite il framework sono svariate, da filesystem, adatabase, ad e-mail etc...

Le category presenti riguardano le seguenti tipologie di log:

• Informazioni di debug sull’interfaccia, l’interfaccia emette informazioni di debug tramite la category log4j.category.tracer.Per default tale category emette log sul file /var/openspcoop/log/InterfacciaRegistro.log con verbosità DEBUG.

• Informazioni di auditing (per ulteriori dettagli vedi Release Notes: Versione 1.3, funzionalità di auditing sulle console grafiche), l’interfaccia emette informazioni di auditing tramite la category log4j.category.audit. Per default tale category emette log sulfile /var/openspcoop/log/AuditingRegistro.log con verbosità DEBUG.

4.1.3.5 Personalizzazione dell’interfaccia

Le proprietà presenti nel file infoGeneral.cfg permettono di personalizzare l’interfaccia web. Di seguito vengono riportate taliproprietà, catalogate funzionalmente:

• Package CNIPA, gli accordi di servizio parte comune e specifica e gli accordi di cooperazione possono essere importati/esportatiin package CNIPA (vedi Release Notes: Versione 1.3, Import/Export degli accordi nel registro dei servizi compatibili conClientSICA ).

Tale funzionalità è attiva nell’interfaccia se l’opzione IMPORTA_ESPORTA assume il valore true (Default: true, valoripossibili: true/false).

• Ciclo di vita degli accordi, l’interfaccia grafica del registro dei servizi permette agli utenti di gestire il ciclo di vita degli accordidi servizio e di coooperazione. Per ulteriori dettagli vedi Release Notes: Versione 1.2, Ciclo di vita degli accordi

Tale funzionalità è attiva nell’interfaccia se l’opzione workflowStatoDocumenti assume il valore true (Default: true, valoripossibili: true/false).

• Gestione accordi di servizio, nella versione 1.0 di OpenSPCoop un Accordo di Servizio poteva corrispondere ad un unicoPortType del WSDL del Servizio. Questo limite è stato superato nella versione 1.1, introducendo la gestione esplicita deiPortType all’interno dell’Accordo. Per ulteriori dettagli vedi Release Notes: Versione 1.1, Accordi di Servizio multiservizio .

La proprietà ShowAccordiAzioni indica all’interfaccia se visualizzare la colonna Azioni di un accordo di servizio parte comune.Tale colonna permette di gestire le azioni associate ad un accordo come veniva effettuato nella versione 1.0 di OpenSPCoop.Questa modalità di gestione è stata deprecata poichè non permetteva la creazione di un unico accordo di servizio per un WSDLche possiede più di un port-type, e per questo per default tale opzione è disabilitata (Default: no, valori possibili: yes/no).

La proprietà ShowAccordiPortTypes indica all’interfaccia se visualizzare la colonna Servizi di un accordo di servizio partecomune. Tale colonna permette di gestire più di un port type, associati ad un accordo, come descritto in Release Notes:Versione 1.1, Accordi di Servizio multiservizio (Default: yes, valori possibili: yes/no).

• Soggetto referente e versione, dalla versione 1.1 di OpenSPCoop per un accordo di servizio parte comune è obbligatorio definireun soggetto referente ed una versione. Tale comportamente è modificabile tramite l’opzione backward_compatibility_1.1(Default: false, valori possibili: true/false).

• Gestione correlazione asincrona, la correlazione tra la cooperazione asincrona di richiesta e quella di risposta può esserespecificata direttamente nell’accordo di servizio parte comune. L’accordo di servizio parte specifica viene automaticamentegestito come correlato o meno, in base alle informazioni ereditate dalla parte comune; per ulteriori dettagli vedi Release Notes:Versione 1.3, Miglioramenti principali attuati sulle console grafiche .

Tale funzionalità di correlazione direttamente nell’accordo di servizio parte comune è attiva nell’interfaccia se l’opzioneaccordi.showCorrelazioneAsincrona assume il valore true (Default: true, valori possibili: true/false).


http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=relnotes&rel=1.4&id=index.html#auditing


http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=relnotes&rel=1.4&id=index.html#importExportSICA


http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=relnotes&rel=1.4&id=ar01s02.html#workflow

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=relnotes&rel=1.4&id=ar01s03.html#accordoNEWPortTypes



http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=relnotes&rel=1.4&id=index.html#miglioramentiConsole



45 / 84

• Gestione accordi di cooperazione, gli accordi di cooperazione e i servizi composti vengono gestiti dall’interfaccia web solo sel’opzione ShowAccordiCooperazione è abilitata (Default: yes, valori possibili: yes/no).

• Gestione WSBL, gli accordi di servizio parte comune permettono di caricare anche i documenti riguardanti la specifica diconversazione.

Tale funzionalità è attiva nell’interfaccia se l’opzione GestioneWSBL assume il valore yes (Default: yes, valori possibili:yes/no).

• Gestione connettori, i soggetti SPCoop e i gli accordi di servizio parte specifica contengono gli endpoint dove sono erogati iservizi. Tali endpoint possono essere semplici url http o connettori più complessi (es. JMS). L’interfaccia grafica è configurabileper visualizzare i tipi di connettori graditi tramite l’opzione TIPOLOGIA_CONNETTORI:

– HTTP, i connettori sono sempre semplici url http

– ALL, i connettori assumono anche tipologie diverse da http

Un utente che possiede un profilo di visualizzazione linee guida 1.1 (per ulteriori dettagli vedi Realese Notes: Versione 1.1,Nuove Linee Guida per l’uso della Busta e-Gov ) visualizzerà sempre solo url http, qualsiasi sia il valore della proprietàTIPOLOGIA_CONNETTORI. Per poter visualizzare tipologie diverse da http, quindi, oltre che abilitare la proprietà si deveimpostare all’utente una visualizzazione completa agendo nella sezione Configurazione -> Utente -> Tipologia Interfaccia.

• Configurazione personalizzate, l’interfaccia permette di utilizzare dei componenti personalizzati dall’utente, per quanto ri-guarda connettori e meccanismi di autenticazione/autorizzazione dei servizi applicativi. Questo poichè oltre alla possibilità diselezionare un componente built-in, è permesso anche di indicarne uno creato e registrato dall’utente. Per ulteriori dettagli vediSezione 3.3.3.1,Sezione 3.3.3.2 e Sezione 3.3.3.3.

Tale funzionalità è attiva nell’interfaccia se l’opzione ConfigurazioniPersonalizzate assume il valore true (Default: false, valoripossibili: true/false).

• Terminologia degli Accordi di Servizio, la terminologia sugli accordi di servizio presente nelle interfacce grafiche è stataadeguata ai documenti CNIPA, dalla versione 1.3. Per ulteriori dettagli vedi Release Notes: Versione 1.3, Miglioramentiprincipali attuati sulle console grafiche

La proprietà registroServizi.terminologia permette di indicare la terminologia da far utilizzare all’interfaccia (Default: sica):

– sica, i termini utilizzati saranno AccordiServizioParteComune, AccordiServizioParteSpecifica, AccordiCooperazione, Ac-cordiServizioComposti e Adesioni

– openspcoop, i termini utilizzati saranno AccordiServizio, ServizioSPCoop, AccordiCooperazione, AccordiServizio + opzio-ne composto e Fruitori

• Pulsante Aggiungi nel menù dell’interfaccia, l’interfaccia è modificabile per poter far comparire o meno il punsante Aggiungidirettamente all’interno delle sezioni del menù. Il pulsante viene visualizzato se la proprietà menu.visualizzazioneLinkAggiungiassume il valore true (Default: false).

• Pulsante Aggiungi nell’elenco degli oggetti, l’interfaccia è modificabile per poter far comparire o meno il punsante Aggiungi al-l’interno dell’elenco degli oggetti gestiti dall’interfaccia. Il pulsante viene visualizzato se la proprietà elenchi.visualizzaPulsanteAggiungiassume il valore true (Default: true).

• Visibilità utenti, un utente che ha i permessi di gestione dei servizi ’S’ (Release Notes: Versione 1.3, Introduzione deiPermessi per l’accesso alle funzionalità delle console grafiche ) puo avere due tipologie di visibilità degli oggetti presentinell’applicazione web:

– locale, visione dei soli oggetti da lui creati

– globale, visione complessiva di tutti gli oggetti esistenti

Tale funzionalità è configurabile nell’interfaccia tramite l’opzione visibilitaOggetti (Default: globale).





http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=relnotes&rel=1.4&id=index.html#permessi



46 / 84

4.2 Interfaccia WebService del Registro dei Servizi


4.2.1.1 Interfaccia WebService

I sorgenti dell’interfaccia web service del registro dei servizi sono disponibili all’interno della distribuzione nella directory tool-s/ws/registry_search/src. Per procedere con la compilazione è necessario utilizzare l’utility Ant sul path tools/ws/registry_search,eseguendo il seguente comando:

ant clean build

La compilazione produce come risultato un archivio openspcoopRegistroServiziSearch.war all’interno della directory dist.

4.2.2 Installazione

I paragrafi di questa sezione descrivono come procedere con l’installazione dell’interfaccia web service di un registro dei servizi,che estende una qualsiasi tipologia di registro dei servizi. Come prerequisito è quindi richiesta una installazione di una tipologiadi registro dei servizi descritta in Sezione 4

L’applicazione viene fornita sotto forma di archivio openspcoopRegistroServiziSearch.war come risultato della compilazione deisorgenti descritta in Sezione 4.2.1.1.


L’interfaccia web service del Registro dei Servizi di OpenSPCoop è preconfigurata per gestire un registro basato su database ditipo postgresql.

Se si desidera cambiare il tipo di database o la tipologia del registro dei servizi si deve agire sui file di proprietà presenti all’internodell’archivio: openspcoopRegistroServiziSearch.war/WEB-INF/classes.

Per ulteriori dettagli su come modificare la tipologia di registro dei servizi o il tipo di database gestito dall’interfaccia ws èpossibile vedere Sezione 4.2.3.1.


Per la versione J2EE è sufficiente copiare il file dist/openspcoopRegistroServiziSearch.war nella directory di deploy dell’appli-cation server: JBOSS_DIR/server/ISTANZA/deploy (es. /var/lib/jbossas/server/default/deploy).

Per la versione ServletContainer è sufficiente copiare il file dist/openspcoopRegistroServiziSearch.war nella directory di deploydel servlet container: TOMCAT_DIR/webapps (es. /var/lib/tomcat5/webapps).


• http://localhost:8080/openspcoopRegistroServiziSearch/Search

Per ottenere il WSDL dell’interfaccia web service è possibile utilizzare la seguente url:

• http://localhost:8080/openspcoopRegistroServiziSearch/Search?wsdl

L’applicazione produce dei log che registrano le operazioni effettuate nel file /var/openspcoop/log/WSRegistrySearch.log. Perulteriori informazioni su come personalizzare i log vedi Sezione 4.2.3.2.

Nella distribuzione, in tools/ws/registry_search/deploy/stub_ws/openspcoop_registroServiziSearch_stub.jar viene fornito un ar-chivio jar contenente degli stub utilizzabili per la creazione di un client Java basato sul framework soap Axis 1.4

http://ws.apache.org/axis/


47 / 84


L’interfaccia web service del Registro dei Servizi di OpenSPCoop è preconfigurata per gestire un registro su database di tipo post-gresql. Il prodotto è tuttavia configurabile agendo sui file di proprietà presenti all’interno dell’archivio in openspcoopRegistroServiziSearch.war/WEB-INF/classes.



• Logging


L’applicazione web service si interfaccia per default ad un Registro dei Servizi DB di tipo postgresql. Se si vuole modificare latipologia del registro dei servizi si deve agire sul file di configurazione infoGeneral.cfg. Le proprietà da modificare, all’interno delfile di configurazione, variano a seconda della tipologia di registro dei servizi scelto, impostabile tramite la proprietà tipoRegistro:

• DB (registro basato su db), gli accordi di servizio sono mantenuti su un database relazionale; devono essere indicati il tipo didatabase e le informazioni per accedervi tramite le seguenti proprietà

– tipoDatabase, indica il tipo di database scelto tra postgresql, mysql e oracle.– dataSource, nome jndi di un dataSource registrato nell’albero JNDI dell’A.S. è possibile fornire informazioni di contesto

per la ricerca del dataSource, attraverso una o più voci dataSource.property.*, tramite la definizione di coppie nome/valoredove il nome viene preso al posto del carattere speciale *. (Default: dataSource=org.openspcoop.dataSource.regserv edataSource.property non definite).

• XML (registro basato su file xml), gli accordi di servizio sono mantenuti su un file xml; deve essere indicato il path doveè posto il file xml tramite la proprietà locationRegistroServizi. È possibile indicare sia un path locale su file system (es./etc/openspcoop/registroServizi.xml) che una url di un repository remoto (es. http://localhost:8080/registroServizi.xml).

• WEB (registro basato su Web), gli accordi di servizio sono mantenuti su un repository web accessibile tramite http; deve essereindicato come accedere all’area dati del repository web tramite le seguenti proprietà

– pathPrefix, corrispondente al path della directory contenente l’area dati in cui mantenere i contenuti del registro– urlPrefix, corrispondente alla URL con cui l’area dati è raggiungibile via http

• UDDI (registro basato su UDDI), gli accordi di servizio sono mantenuti su un repository web accessibile tramite http e indiciz-zati tramite un Registro UDDI; deve essere indicato come accedere all’area dati del repository web e come accedere al registroUDDI tramite le seguenti proprietà

– pathPrefix, corrispondente al path della directory contenente l’area dati in cui mantenere i contenuti del registro– urlPrefix, corrispondente alla URL con cui l’area dati è raggiungibile via http– inquiryURL, corrispondente alla URL con cui è possibile interrogare il registro UDDI– publishURL, corrispondente alla URL con cui è possibile pubblicare oggetti sul registro UDDI– userid, username necessaria all’autenticazione sul registro UDDI– password, password necessaria all’autenticazione sul registro UDDI

4.2.3.2 Logging

L’interfaccia web è configurabile, per quanto riguarda le funzionalità di logging, tramite il file tracerRegservSearch.log4j.properties.






48 / 84

• Informazioni di debug sull’interfaccia ws, l’interfaccia emette informazioni di debug tramite la category log4j.category.ws_logger.Per default tale category emette log sul file /var/openspcoop/log/WSRegistrySearch.log con verbosità DEBUG.

5 Pdd Console

La Porta di Dominio OpenSPCoop supporta due tipologie di configurazione, una basata su file xml e una basata su databaserelazionale, come descritto in Sezione 3.2.5. In questa sezione verrà descritto come installare e configurare il software necessarioalla configurazione basata su database relazionale, tralasciando completamente la configurazione basata su file xml che nonnecessita chiaramente di alcuna interfaccia di gestione.

La tipologia di configurazione basata su database si addice per ambienti reali dove gli scenari possono essere dinamici e il numerodi soggetti e servizi da gestire risulta elevato poichè tale configurazione può essere gestita tramite una interfaccia web di gestione.

Esistono attualmente due tipi di interfacce di gestione, utilizzabili a seconda del contesto reale di utilizzo:

• PdD e Registro Servizi gestiti localmente, questo modello rappresenta la soluzione più semplice nei casi in cui è richiesta ladotazione di una Porta di Dominio per un singolo ente la cui gestione avviene localmente in completa autonomia. Per ulterioridettagli vedi Architettura Logica OpenSPCoop: La configurazione minima

L’interfaccia di gestione permette di inserire sia i dati di integrazione tra la Porta di Dominio e i servizi applicativi, sia i datiriguardanti gli accordi di servizio. Questa interfaccia è descritta in questa sezione nel paragrafo Sezione 5.1

• PdD gestita localmente e Registro Servizi centralizzato, in questo scenario abbiamo un’architettura in cui ciascun ente gestisceautonomamente la configurazione della propria Porta di Dominio. Invece il Registro dei Servizi è unico, quindi condiviso datutte le porte di dominio, e gestito centralmente, ad esempio da un unico soggetto (es. un Centro Servizi Territoriale). Perulteriori dettagli vedi Architettura Logica OpenSPCoop: Porte di Dominio Locali con Registro Centrale

L’interfaccia di gestione permette di inserire solo i dati di integrazione tra la Porta di Dominio e i servizi applicativi. I da-ti riguardanti gli accordi di servizio non vengono gestiti, ma dovranno essere conosciuti per essere inseriti dall’utente neicomponenti di integrazione. Questa interfaccia è descritta in questa sezione nel paragrafo Sezione 5.2

Le PddConsole, oltre a gestire la configurazione della Porta di Dominio, possono essere utilizzate per fini diagnostici o dimonitoraggio:

• tracce, è possibile consultare le tracce emesse dalla porta di dominio

L’interfaccia effettua le ricerche consultando il database delle tracce descritto in Sezione 3.3.2.2.

• messaggi diagnostici, è possibile consultare i messaggi diagnostici emessi dalla porta di dominio

L’interfaccia effettua le ricerche consultando il database dei messaggi diagnostici descritto in Sezione 3.3.2.1.

• monitoraggio applicativo, è possibile visualizzare i messaggi in transito nella Porta di Dominio che sono in attesa di essereconsegnati

L’interfaccia effettua le ricerche consultando il database dei messaggi descritto in Sezione 3.2.3.

5.1 PddConsole con Registro dei Servizi locale



I sorgenti dell’interfaccia web sono disponibili all’interno della distribuzione nella directory tools/web_interfaces/control_station/src.Per procedere con la compilazione è necessario utilizzare l’utility Ant sul path tools/web_interfaces/control_station, eseguendoil seguente comando:

ant clean build_pddConsole

La compilazione produce come risultato un archivio pddConsole.war all’interno della directory dist installabile in un applicationserver J2EE.

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=archLogica&rel=1.4&id=ar01s02.html

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=archLogica&rel=1.4&id=ar01s04.html


49 / 84


I sorgenti dell’interfaccia web sono disponibili all’interno della distribuzione nella directory tools/web_interfaces/control_station/src.Per procedere con la compilazione è necessario utilizzare l’utility Ant sul path tools/web_interfaces/control_station, eseguendoil seguente comando:


La compilazione produce come risultato un archivio pddConsole.war all’interno della directory dist installabile in un servletcontainer.

5.1.2 Installazione


L’applicazione viene fornita sotto forma di archivio pddConsole.war come risultato della compilazione dei sorgenti descritta inSezione 5.1.1.1 e Sezione 5.1.1.2.


L’interfaccia web richiede l’installazione di un database relazionale nel quale devono essere registrate le tabelle utilizzate per laraccolta dei componenti di integrazione e degli accordi di servizio. Attualmente lo sviluppo di OpenSPCoop viene effettuato sutre tipi di database: Postgres v8, MySQL v5 e Oracle10gExpress.

Le tabelle SQL richieste dall’interfaccia web sono descritte all’interno del file tools/web_interfaces/control_station/deploy/sql/TIPO_DATABASE/single_pdd/PddConsole.sql.



1. Creazione Utente

[user@localhost]$ suParola d’ordine: XXX[root@localhost]# su - postgres-bash-3.1$ createuser -PEnter name of role to add: pddConsoleEnter password for new role: pddConsoleConferma password: pddConsoleShall the new role be a superuser? (y/n) nShall the new role be allowed to create databases? (y/n) nShall the new role be allowed to create more new roles? (y/n) nCREATE ROLE


[user@localhost]$ suParola d’ordine: XXX[root@localhost]# su - postgres-bash-3.1$createdb -O pddConsole pddConsoleCREATE DATABASE

3. Abilitazione accesso dell’utente al Database, è possibile abilitare l’accesso editando il file /var/lib/pgsql/data/pg_hba.conf(come super utente). Abilitiamo quindi l’utente pddConsole ad accedere al db pddConsole, aggiungendo le seguenti righeal file:


50 / 84

local pddConsole pddConsole md5host pddConsole pddConsole 127.0.0.1 255.255.255.255 md5


[user@localhost]$ psql pddConsole pddConsole < tools/web_interfaces/control_station/ ←↩deploy/sql/TIPO_DATABASE/single_pdd/PddConsole.sql

Password for user pddConsole: pddConsole


NotaIl database include le tabelle per la memorizzazione delle tracce e dei messaggi diagnostici emessi dalla porta di dominio, lequali vengono interrogate dall’interfaccia tramite le funzionalità di diagnostica, per effettuare le ricerce richieste dall’utente.Se la porta di dominio è configurata per registrare le tracce e i messaggi diagnostici su database differenti da quello creato inquesta sezione, si deve configurare l’interfaccia a consultare tale database invece di quello creato in questo paragrafo; ulterioridettagli sono disponibili in Sezione 5.1.3.2 e Sezione 5.1.3.3.Se si desidera, invece, configurare la porta di dominio per utilizzare il database creato in questa sezione come storage su cuiconservare le tracce e i messaggi diagnostici emessi è possibile consultare le sezioni Sezione 3.3.2.1 e Sezione 3.3.2.2.


L’interfaccia web richiede l’installazione di un pool di connessioni verso il DBMS che possieda come nome JNDI: org.openspcoop.dataSource.pddConsole.

Un datasource di esempio per l’application server JBoss viene fornito in tools/web_interfaces/control_station/deploy/datasource/jboss/pddConsole-ds.xml. Il file permette di creare la risorsa nella propria installazione dell’A.S., attraverso la configurazione e la successiva copiadel file in JBOSS_DIR/server/default/deploy.


Un datasource di esempio per l’application server Tomcat viene fornito in tools/web_interfaces/control_station/deploy/datasource/tomcat/pddConsole.xml.Il file permette di creare la risorsa nella propria installazione di Tomcat, attraverso la configurazione e la successiva copia del filein TOMCAT_DIR/Catalina/ (es. /etc/tomcat5/Catalina/localhost/).




L’interfaccia web è preconfigurata per gestire un database di tipo postgresql.

Se si desidera cambiare il tipo di database si deve agire sui file di proprietà presenti all’interno dell’archivio: pddConsole.war/WEB-INF/classes.



51 / 84


Per la versione J2EE è sufficiente copiare il file dist/pddConsole.war nella directory di deploy dell’application server: JBOSS_DIR/server/ISTANZA/deploy(es. /var/lib/jbossas/server/default/deploy).

Per la versione ServletContainer è sufficiente copiare il file dist/pddConsole.war nella directory di deploy del servlet container:TOMCAT_DIR/webapps (es. /var/lib/tomcat5/webapps).


• http://localhost:8080/pddConsole/login.do


L’applicazione produce dei log che registrano le operazioni effettuate nel file /var/openspcoop/log/ControlStationCore.log. Perulteriori informazioni su come personalizzare i log vedi Sezione 5.1.3.5.



L’interfaccia web PddConsole con registro dei servizi locale è preconfigurata per gestire un database di tipo postgresql. Ilprodotto è tuttavia altamente configurabile agendo sui file di proprietà presenti all’interno dell’archivio in pddConsole.war/WEB-INF/classes.


• Accesso al DBMS

• Accesso al database delle tracce

• Accesso al database dei messaggi diagnostici

• Accesso al database dei messaggi in transito sulla Porta di Dominio

• Logging



L’accesso al database dove vengono conservati i componenti di integrazione e gli accordi (vedi Sezione 5.1.2.1), viene definitotramite il file di configurazione datasource.properties dove viene indicato, tramite la voce dataSource, il nome jndi di un data-Source registrato nell’albero JNDI dell’A.S. È possibile fornire informazioni di contesto per la ricerca del dataSource, attraversouna o più voci dataSource.property.*, tramite la definizione di coppie nome/valore dove il nome viene preso al posto del caratterespeciale *. (Default: dataSource=org.openspcoop.dataSource.pddConsole e dataSource.property non definite).






52 / 84

5.1.3.2 Accesso al database delle tracce

La porta di dominio OpenSPCoop, come descritto in Sezione 3.3.2.2, può essere configurata per registrare le tracce su undatabase. Tale db può essere lo stesso dove vengono conservati i messaggi in transito sulla porta di dominio (Sezione 3.2.3),oppure può essere utilizzato il db dedicato alla PddConsole (Sezione 5.1.2.1) o infine è possibile utilizzare un database dedicato.

L’interfaccia PddConsole deve essere configurata, tramite il file di configurazione infoGeneral.cfg, per accedere al databaseutilizzato dalla porta di dominio per registrare le tracce:

• Se tale db risulta lo stesso dell’interfaccia web, allora è sufficente impostare la proprietà tracce.sameDBWebUI al valore true(Comportamento di default).

• Se la Porta di Dominio utilizza un db diverso da quello dell’interfaccia web, allora si deve impostare la proprietà trac-ce.sameDBWebUI al valore false.

L’accesso al database viene indicato, tramite la voce tracce.dataSource, in modo da fornire il nome jndi di un dataSourceregistrato nell’albero JNDI dell’A.S. È possibile fornire informazioni di contesto per la ricerca del dataSource, attraverso unao più voci tracce.dataSource.property.*, tramite la definizione di coppie nome/valore dove il nome viene preso al posto delcarattere speciale *.

La voce tracce.tipoDatabase (interpretata solo se tracce.sameDBWebUI=false) permette di impostare il tipo di database utiliz-zato: postgresql/mysql/oracle

La voce tracce.configurazioneCustomAppender abilita la gestione degli OpenSPCoopAppender (Sezione 3.3.2.2) all’internodella sezione di configurazione delle tracce e-Gov (Default: false)

5.1.3.3 Accesso al database dei messaggi diagnostici

La porta di dominio OpenSPCoop, come descritto in Sezione 3.3.2.1, può essere configurata per registrare i messaggi diagnosticisu un database. Tale db può essere lo stesso dove vengono conservati i messaggi in transito sulla porta di dominio (Sezione 3.2.3),oppure può essere utilizzato il db dedicato alla PddConsole (Sezione 5.1.2.1) o infine è possibile utilizzare un database dedicato.

L’interfaccia PddConsole deve essere configurata, tramite il file di configurazione infoGeneral.cfg, per accedere al databaseutilizzato dalla porta di dominio per registrare i messaggi diagnostici:

• Se tale db risulta lo stesso dell’interfaccia web, allora è sufficente impostare la proprietà msgDiagnostici.sameDBWebUI alvalore true (Comportamento di default).

• Se la Porta di Dominio utilizza un db diverso da quello dell’interfaccia web, allora si deve impostare la proprietà msgDiagno-stici.sameDBWebUI al valore false.

L’accesso al database viene indicato, tramite la voce msgDiagnostici.dataSource, in modo da fornire il nome jndi di un data-Source registrato nell’albero JNDI dell’A.S. È possibile fornire informazioni di contesto per la ricerca del dataSource, attra-verso una o più voci msgDiagnostici.dataSource.property.*, tramite la definizione di coppie nome/valore dove il nome vienepreso al posto del carattere speciale *.

La voce msgDiagnostici.tipoDatabase (interpretata solo se msgDiagnostici.sameDBWebUI=false) permette di impostare il tipodi database utilizzato: postgresql/mysql/oracle

La voce msgDiagnostici.configurazioneCustomAppender abilita la gestione degli OpenSPCoopAppender (Sezione 3.3.2.1) al-l’interno della sezione di configurazione dei messaggi diagnostici (Default: false)

5.1.3.4 Accesso al database dei messaggi in transito sulla Porta di Dominio

L’interfaccia PddConsole deve essere configurata, tramite il file di configurazione infoGeneral.cfg, per accedere al databaseutilizzato dalla porta di dominio per gestire i messaggi in transito (Sezione 3.2.3)

L’accesso al database viene indicato, tramite la voce singlePdD.monitor.dataSource, in modo da fornire il nome jndi di un data-Source registrato nell’albero JNDI dell’A.S. È possibile fornire informazioni di contesto per la ricerca del dataSource, attraversouna o più voci singlePdD.monitor.dataSource.property.*, tramite la definizione di coppie nome/valore dove il nome viene presoal posto del carattere speciale *. (Default: org.openspcoop.dataSource e proprietà di contesto non definite)

La voce singlePdD.monitor.tipoDatabase permette di impostare il tipo di database utilizzato: postgresql/mysql/oracle (Default:postgresql)


53 / 84

5.1.3.5 Logging





• Informazioni di debug sull’interfaccia, l’interfaccia emette informazioni di debug tramite la category log4j.category.ctrlcore.Per default tale category emette log sul file /var/openspcoop/log/ControlStationCore.log con verbosità DEBUG.

• Informazioni di debug sull’accesso al database, l’interfaccia emette informazioni di debug, riguardanti l’accesso al database,tramite le categories log4j.category.DRIVER_DB_CONFIGURAZIONE, log4j.category.DRIVER_DB_REGISTRO e log4j.category.DRIVER_DB_PDD_CONSOLE.Per default tali categories emettono log, con verbosità DEBUG, rispettivamente sui file /var/openspcoop/log/DriverConfigura-zioneDB.log, /var/openspcoop/log/DriverRegistroServiziDB.log e /var/openspcoop/log/DriverControlStationDB.log.

• Informazioni di auditing (per ulteriori dettagli vedi Release Notes: Versione 1.3, funzionalità di auditing sulle console grafiche), l’interfaccia emette informazioni di auditing tramite la category log4j.category.audit. Per default tale category emette log sulfile /var/openspcoop/log/AuditingControlStation.log con verbosità DEBUG.

NotaLe altre categories presenti nel file tracer.log4j.properties non vengono interpretate dalla versione della PddConsole descritta inquesta sezione; verrano utilizzate per la gestione remota delle Pdd e del Registro dei Servizi descritto nella sezione Sezione 6




















54 / 84

















• generazioneAutomaticaPorteDelegate, all’aggiunta di una adesione in un accordo di servizio parte specifica, viene creataautomaticamente il componente di integrazione (PortaDelegata) necessario ad un servizio applicativo per poter effettivamentefruire del servizio SPCoop.

Tale funzionalità è attiva nell’interfaccia se l’opzione generazioneAutomaticaPorteDelegate assume il valore true (Default:true, valori possibili: true/false).

• org.openspcoop.pdd.server, la Porta di Dominio può essere compilata per poter funzionare in ambienti J2EE o servlet container,come descritto in Sezione 3. Se l’ambiente scelto non è J2EE, determinate funzionalità non sono disponibili e quindi nondevono essere configurabili tramite PddConsole. La proprietà org.openspcoop.pdd.server permette proprio di indicare qualeambiente viene utilizzato dalla Porta di Dominio e quindi visualizzare correttamente gli aspetti gestibili da interfaccia web.(Default: dipendenti dalla compilazione scelta, valori possibili: j2ee/web)








55 / 84

• pa.SPCoopProperties.valoriPredefiniti, la porta applicativa permette di configurare delle proprietà relative a informazioni SP-Coop, che verranno utilizzate dalla Porta di Dominio per propagare le informazioni presenti nella busta eGov all’internodell’header di trasporto utilizzato per invocare un servizio applicativo (vedi Guida Utente XML: Configurazione PdD, SPCoopProperty ).

L’inserimento delle proprietà da parte dell’utente, può essere pilotato tramite un insieme di valori ammissibili o può esserelasciato libero. Tale comportamento è configurato dalla proprietà pa.SPCoopProperties.valoriPredefiniti. (Default: true, valoripossibili: true/false).



• Visualizzazione del numero di elementi di una lista, l’interfaccia è modificabile per poter far comparire o meno il totale deglielementi presenti in un elenco, nei link di accesso all’elenco stesso. Il numero di elementi viene visualizzato se la proprietàcontaListe assume il valore true (Default: true, valori possibili: true/false).

• Soggetti Virtuali, la Porta di Dominio OpenSPCoop può essere configurata, per casi eccezionali, per processare buste destinatea soggetti non in gestione nella porta. Tali soggetti virtuali vengono definiti direttamente nella porta applicativa.

Tale funzionalità è configurabile nell’interfaccia tramite l’opzione SoggettoVirtuale (Default: no, valori possibili: yes/no).





NotaLa proprietà singlePdD presente nel file infoGeneral.cfg non deve essere modificata. Tale proprietà indica all’interfaccia dilavorare in una modalità di gestione della porta di dominio e del registro dei servizi locale; se modificata l’interfaccia funzioneràin modalità di gestione remota delle Pdd e del Registro dei Servizi descritto nella sezione Sezione 6

NotaLe altre proprietà presenti nel file infoGeneral.cfg non vengono interpretate dalla versione della PddConsole descritta in questasezione; verrano utilizzate per la gestione remota delle Pdd e del Registro dei Servizi descritto nella sezione Sezione 6

5.2 PddConsole con Registro dei Servizi centralizzato



I sorgenti dell’interfaccia web sono disponibili all’interno della distribuzione nella directory tools/web_interfaces/pdd/src. Perprocedere con la compilazione è necessario utilizzare l’utility Ant sul path tools/web_interfaces/pdd, eseguendo il seguentecomando:

ant clean build

La compilazione produce come risultato un archivio pdd.war all’interno della directory dist installabile in un application serverJ2EE.

http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=doc-file&guida=manualexml&rel=1.4&id=ar01s03.html#SPCoopProperties





56 / 84


I sorgenti dell’interfaccia web sono disponibili all’interno della distribuzione nella directory tools/web_interfaces/pdd/src. Perprocedere con la compilazione è necessario utilizzare l’utility Ant sul path tools/web_interfaces/pdd, eseguendo il seguentecomando:


La compilazione produce come risultato un archivio pdd.war all’interno della directory dist installabile in un servlet container.

5.2.2 Installazione


L’applicazione viene fornita sotto forma di archivio pdd.war come risultato della compilazione dei sorgenti descritta in Sezio-ne 5.2.1.1 e Sezione 5.2.1.2.


L’interfaccia web richiede l’installazione di un database relazionale nel quale devono essere registrate le tabelle utilizzate per laraccolta dei componenti di integrazione e degli accordi di servizio. Attualmente lo sviluppo di OpenSPCoop viene effettuato sutre tipi di database: Postgres v8, MySQL v5 e Oracle10gExpress.

Le tabelle SQL richieste dall’interfaccia web sono descritte all’interno del file tools/web_interfaces/pdd/deploy/sql/TIPO_DATABASE/ConfigurazionePdD.sql.



1. Creazione Utente

[user@localhost]$ suParola d’ordine: XXX[root@localhost]# su - postgres-bash-3.1$ createuser -PEnter name of role to add: pddEnter password for new role: pddConferma password: pddShall the new role be a superuser? (y/n) nShall the new role be allowed to create databases? (y/n) nShall the new role be allowed to create more new roles? (y/n) nCREATE ROLE


[user@localhost]$ suParola d’ordine: XXX[root@localhost]# su - postgres-bash-3.1$createdb -O pdd pddCREATE DATABASE

3. Abilitazione accesso dell’utente al Database, è possibile abilitare l’accesso editando il file /var/lib/pgsql/data/pg_hba.conf(come super utente). Abilitiamo quindi l’utente pdd ad accedere al db pdd, aggiungendo le seguenti righe al file:


57 / 84

local pdd pdd md5host pdd pdd 127.0.0.1 255.255.255.255 md5


[user@localhost]$ psql pdd pdd < tools/web_interfaces/pdd/deploy/sql/TIPO_DATABASE/ ←↩ConfigurazionePdD.sql

Password for user pdd: pdd


NotaIl database include le tabelle per la memorizzazione delle tracce e dei messaggi diagnostici emessi dalla porta di dominio, lequali vengono interrogate dall’interfaccia tramite le funzionalità di diagnostica, per effettuare le ricerce richieste dall’utente.Se la porta di dominio è configurata per registrare le tracce e i messaggi diagnostici su database differenti da quello creato inquesta sezione, si deve configurare l’interfaccia a consultare tale database invece di quello creato in questo paragrafo; ulterioridettagli sono disponibili in Sezione 5.2.3.2 e Sezione 5.2.3.3.Se si desidera, invece, configurare la porta di dominio per utilizzare il database creato in questa sezione come storage su cuiconservare le tracce e i messaggi diagnostici emessi è possibile consultare le sezioni Sezione 3.3.2.1 e Sezione 3.3.2.2.


L’interfaccia web richiede l’installazione di un pool di connessioni verso il DBMS che possieda come nome JNDI: org.openspcoop.dataSource.pdd.

Un datasource di esempio per l’application server JBoss viene fornito in tools/web_interfaces/pdd/deploy/datasource/jboss/config-ds.xml. Il file permette di creare la risorsa nella propria installazione dell’A.S., attraverso la configurazione e la successiva copiadel file in JBOSS_DIR/server/default/deploy.


Un datasource di esempio per l’application server Tomcat viene fornito in tools/web_interfaces/pdd/deploy/datasource/tomcat/pdd.xml.Il file permette di creare la risorsa nella propria installazione di Tomcat, attraverso la configurazione e la successiva copia del filein TOMCAT_DIR/Catalina/ (es. /etc/tomcat5/Catalina/localhost/).




L’interfaccia web è preconfigurata per gestire un database di tipo postgresql.

Se si desidera cambiare il tipo di database si deve agire sui file di proprietà presenti all’interno dell’archivio: pdd.war/WEB-INF/classes.



58 / 84


Per la versione J2EE è sufficiente copiare il file dist/pdd.war nella directory di deploy dell’application server: JBOSS_DIR/server/ISTANZA/deploy(es. /var/lib/jbossas/server/default/deploy).

Per la versione ServletContainer è sufficiente copiare il file dist/pdd.war nella directory di deploy del servlet container: TOM-CAT_DIR/webapps (es. /var/lib/tomcat5/webapps).


• http://localhost:8080/pdd/login.do


L’applicazione produce dei log che registrano le operazioni effettuate nel file /var/openspcoop/log/InterfacciaPdD.log. Perulteriori informazioni su come personalizzare i log vedi Sezione 5.2.3.5.



L’interfaccia web PddConsole con registro dei servizi centralizzato è preconfigurata per gestire un database di tipo postgresql.Il prodotto è tuttavia altamente configurabile agendo sui file di proprietà presenti all’interno dell’archivio in pdd.war/WEB-INF/classes.


• Accesso al DBMS

• Accesso al database delle tracce

• Accesso al database dei messaggi diagnostici

• Accesso al database dei messaggi in transito sulla Porta di Dominio

• Logging



L’accesso al database dove vengono conservati i componenti di integrazione (vedi Sezione 5.2.2.1), viene definito tramite il filedi configurazione datasource.properties dove viene indicato, tramite la voce dataSource, il nome jndi di un dataSource registratonell’albero JNDI dell’A.S. È possibile fornire informazioni di contesto per la ricerca del dataSource, attraverso una o più vocidataSource.property.*, tramite la definizione di coppie nome/valore dove il nome viene preso al posto del carattere speciale *.(Default: dataSource=org.openspcoop.dataSource.pdd e dataSource.property non definite).






59 / 84

5.2.3.2 Accesso al database delle tracce

La porta di dominio OpenSPCoop, come descritto in Sezione 3.3.2.2, può essere configurata per registrare le tracce su undatabase. Tale db può essere lo stesso dove vengono conservati i messaggi in transito sulla porta di dominio (Sezione 3.2.3),oppure può essere utilizzato il db dedicato alla PddConsole (Sezione 5.2.2.1) o infine è possibile utilizzare un database dedicato.

L’interfaccia PddConsole deve essere configurata, tramite il file di configurazione infoGeneral.cfg, per accedere al databaseutilizzato dalla porta di dominio per registrare le tracce:

• Se tale db risulta lo stesso dell’interfaccia web, allora è sufficente impostare la proprietà tracce.sameDBWebUI al valore true(Comportamento di default).

• Se la Porta di Dominio utilizza un db diverso da quello dell’interfaccia web, allora si deve impostare la proprietà trac-ce.sameDBWebUI al valore false.

L’accesso al database viene indicato, tramite la voce tracce.dataSource, in modo da fornire il nome jndi di un dataSourceregistrato nell’albero JNDI dell’A.S. È possibile fornire informazioni di contesto per la ricerca del dataSource, attraverso unao più voci tracce.dataSource.property.*, tramite la definizione di coppie nome/valore dove il nome viene preso al posto delcarattere speciale *.

La voce tracce.tipoDatabase (interpretata solo se tracce.sameDBWebUI=false) permette di impostare il tipo di database utiliz-zato: postgresql/mysql/oracle

La voce tracce.configurazioneCustomAppender abilita la gestione degli OpenSPCoopAppender (Sezione 3.3.2.2) all’internodella sezione di configurazione delle tracce e-Gov (Default: false)

5.2.3.3 Accesso al database dei messaggi diagnostici

La porta di dominio OpenSPCoop, come descritto in Sezione 3.3.2.1, può essere configurata per registrare i messaggi diagnosticisu un database. Tale db può essere lo stesso dove vengono conservati i messaggi in transito sulla porta di dominio (Sezione 3.2.3),oppure può essere utilizzato il db dedicato alla PddConsole (Sezione 5.2.2.1) o infine è possibile utilizzare un database dedicato.

L’interfaccia PddConsole deve essere configurata, tramite il file di configurazione infoGeneral.cfg, per accedere al databaseutilizzato dalla porta di dominio per registrare i messaggi diagnostici:

• Se tale db risulta lo stesso dell’interfaccia web, allora è sufficente impostare la proprietà msgDiagnostici.sameDBWebUI alvalore true (Comportamento di default).

• Se la Porta di Dominio utilizza un db diverso da quello dell’interfaccia web, allora si deve impostare la proprietà msgDiagno-stici.sameDBWebUI al valore false.

L’accesso al database viene indicato, tramite la voce msgDiagnostici.dataSource, in modo da fornire il nome jndi di un data-Source registrato nell’albero JNDI dell’A.S. È possibile fornire informazioni di contesto per la ricerca del dataSource, attra-verso una o più voci msgDiagnostici.dataSource.property.*, tramite la definizione di coppie nome/valore dove il nome vienepreso al posto del carattere speciale *.

La voce msgDiagnostici.tipoDatabase (interpretata solo se msgDiagnostici.sameDBWebUI=false) permette di impostare il tipodi database utilizzato: postgresql/mysql/oracle

La voce msgDiagnostici.configurazioneCustomAppender abilita la gestione degli OpenSPCoopAppender (Sezione 3.3.2.1) al-l’interno della sezione di configurazione dei messaggi diagnostici (Default: false)

5.2.3.4 Accesso al database dei messaggi in transito sulla Porta di Dominio

L’interfaccia PddConsole deve essere configurata, tramite il file di configurazione infoGeneral.cfg, per accedere al databaseutilizzato dalla porta di dominio per gestire i messaggi in transito (Sezione 3.2.3)

L’accesso al database viene indicato, tramite la voce monitor.dataSource, in modo da fornire il nome jndi di un dataSourceregistrato nell’albero JNDI dell’A.S. È possibile fornire informazioni di contesto per la ricerca del dataSource, attraverso unao più voci monitor.dataSource.property.*, tramite la definizione di coppie nome/valore dove il nome viene preso al posto delcarattere speciale *. (Default: org.openspcoop.dataSource e proprietà di contesto non definite)

La voce monitor.tipoDatabase permette di impostare il tipo di database utilizzato: postgresql/mysql/oracle (Default: postgresql)


60 / 84

5.2.3.5 Logging





• Informazioni di debug sull’interfaccia, l’interfaccia emette informazioni di debug tramite la category log4j.category.tracerpdd.Per default tale category emette log sul file /var/openspcoop/log/InterfacciaPdD.log con verbosità DEBUG.

• Informazioni di debug sull’accesso al database dei messaggi, l’interfaccia emette informazioni di debug, riguardanti l’accessoal database dei messaggi in transito sulla porta di domino, tramite la category log4j.category.DRIVER_DB_MONITORAGGIO.Per default tale category emette log sul file /var/openspcoop/log/DriverMonitoraggio.log con verbosità DEBUG.

• Informazioni di auditing (per ulteriori dettagli vedi Release Notes: Versione 1.3, funzionalità di auditing sulle console grafiche), l’interfaccia emette informazioni di auditing tramite la category log4j.category.audit. Per default tale category emette log sulfile /var/openspcoop/log/AuditingPdd.log con verbosità DEBUG.

NotaLe altre categories presenti nel file tracer.log4j.properties non vengono interpretate dalla versione della PddConsole descritta inquesta sezione; verrano utilizzate per la gestione remota delle Pdd e del Registro dei Servizi descritto nella sezione Sezione 6
















61 / 84








– locale, visione dei soli oggetti da lui creati– globale, visione complessiva di tutti gli oggetti esistenti


6 Pdd Console per la gestione centralizzata

La PddConsole può essere utilizzata come strumento di gestione centralizzata di vari componenti software OpenSPCoop, chea vario titolo saranno parte di un’unica infrastruttura SPCoop gestita. In particolare, tramite la PddConsole OpenSPCoop èpossibile gestire un numero arbitrario di Porte di Dominio OpenSPCoop, anche distribuite su Enti diversi, un Registro dei ServiziOpenSPCoop, un Gestore Eventi OpenSPCoop ed eventualmente anche componenti custom, facilmente implementabili comeplugin applicativi. La PddConsole permette inoltre di monitorare centralmente lo stato delle varie porte di dominio gestite.

Una tipica installazione della PddConsole OpenSPCoop, prevede quindi i seguenti componenti software:

• Interfaccia Web della PddConsole. Utilizzata dagli amministratori dell’architettura, permette la gestione attraverso un’inter-faccia web intuitiva delle configurazioni delle Porte di Dominio, del Registro dei Servizi, e del Gestore Eventi.

• WebService di gestione del Registro dei Servizi. Implementa una interfaccia SOAP per la gestione di un Registro dei Servizi.Tipicamente installato nell’ApplicationServer dove risiede il registro dei servizi.

• WebService di gestione della Configurazione di una Porta di Dominio. Implementa una interfaccia SOAP per la gestione dellaconfigurazione di una Porta di Dominio OpenSPCoop. Tipicamente installato in tutti gli ApplicationServer dove risiedono leporte di dominio gestite.

• WebService di gestione del Monitoraggio di una Porta di Dominio. Implementa una interfaccia SOAP per il monitoraggiodello stato di una Porta di Dominio OpenSPCoop. Tipicamente installato in tutti gli ApplicationServer dove risiedono le portedi dominio gestite.

NotaL’uso della PddConsole richiede che le porte di dominio gestite siano configurate per leggere la propria configurazione da DBrelazionale (vedi Sezione 3.2.5).L’uso della PddConsole richiede che le porte di dominio gestite siano configurate per l’utilizzo di un registro dei servizi ditipologia DB o WEB (vedi Sezione 3.2.6).






62 / 84

La figura seguente mostra l’architettura della PddConsole e l’interazione che essa ha con i componenti di back-end da configurare

Figura 3: Architettura della PddConsole

NotaNon esiste attualmente una versione della PddConsole, per la gestione centralizzata, installabile in un Servlet Container.

6.1 Interfaccia Web di gestione centralizzata


I sorgenti dell’applicazione sono disponibili all’interno della distribuzione nella directory tools/web_interfaces/control_station/src.Per procedere con la compilazione è necessario utilizzare l’utility Ant sul path tools/web_interfaces/control_station, eseguendoil seguente comando:

ant clean build

La compilazione produce come risultato un archivio pddConsole.war all’interno della directory dist installabile in un applicationserver J2EE.

6.1.2 Installazione

I paragrafi di questa sezione descrivono come procedere con l’installazione dell’interfaccia web nell’application server JBoss4.2.X / 5.x


63 / 84

L’applicazione viene fornita sotto forma di archivio pddConsole.war come risultato della compilazione dei sorgenti descritta inSezione 6.1.1 .


L’interfaccia web richiede l’installazione di un database relazionale. Attualmente lo sviluppo di OpenSPCoop viene effettuatosu tre tipi di database: Postgres v8, MySQL v5 e Oracle10gExpress.

Le tabelle SQL richieste dall’interfaccia web sono descritte all’interno del file tools/web_interfaces/control_station/deploy/sql/TIPO_DATABASE/PddConsole.sql.



1. Creazione Utente

[user@localhost]$ suParola d’ordine: XXX[root@localhost]# su - postgres-bash-3.1$ createuser -PEnter name of role to add: pddConsoleEnter password for new role: pddConsoleConferma password: pddConsoleShall the new role be a superuser? (y/n) nShall the new role be allowed to create databases? (y/n) nCREATE ROLE


[user@localhost]$ suParola d’ordine: XXX[root@localhost]# su - pddConsole-bash-3.1$createdb -O pddConsole pddConsoleCREATE DATABASE

3. Abilitazione accesso dell’utente al Database, è possibile abilitare l’accesso editando il file /var/lib/pgsql/data/pg_hba.conf(come super utente). Abilitiamo quindi l’utente pddConsole ad accedere al db pddConsole, aggiungendo le seguenti righeal file:

local pddConsole pddConsole md5host pddConsole pddConsole 127.0.0.1 255.255.255.255 md5


[user@localhost]$ psql pddConsole pddConsole < tools/web_interfaces/control_station/ ←↩deploy/sql/TIPO_DATABASE/PddConsole.sql

Password for user pddConsole: pddConsole



64 / 84


L’interfaccia web richiede l’installazione di un pool di connessioni verso il DBMS che possieda come nome JNDI: org.openspcoop.dataSource.pddConsole.

Un datasource di esempio per l’application server JBoss viene fornito in tools/web_interfaces/control_station/deploy/datasource/jboss/pddConsole-ds.xml. Il file permette di creare la risorsa nella propria installazione dell’A.S., attraverso la configurazione e la successiva copiadel file in JBOSS_DIR/server/default/deploy.




6.1.2.3 Configurazione delle code JMS

L’interfaccia web necessita di alcune code JMS.

All’interno della distribuzione nella in tools/web_interfaces/control_station/deploy/code_jms/BROKER/control_station-destinations-service.xml vengono fornite le configurazioni delle code JMS per la loro creazione in JBoss 4.x e in JBoss 5.x:

• tools/web_interfaces/control_station/deploy/code_jms/jbossMQ/control_station-destinations-service.xml, le code sono istan-ziabili in JBoss 4.x attraverso la copia del file in JBOSSDIR/server/default/deploy/jms

• tools/web_interfaces/control_station/deploy/code_jms/jbossMessaging/control_station-destinations-service.xml, le code sonoistanziabili in JBoss 5.x attraverso la copia del file in JBOSSDIR/server/default/deploy/messaging

Devono, inoltre, essere aggiunte una coda jms per ogni Porta di Dominio che si intende gestire e monitorare. Per questo motivo ilfile control_station-destinations-service.xml contiene a titolo di esempio alcune definizioni per queste code (pdd1,pdd2...pddN).I nomi di queste porte di dominio esemplificative vanno sostituite con i nomi delle porte di dominio realmente configuratenell’applicazione.


L’interfaccia web è preconfigurata per gestire un database interno di tipo postgresql. Se si desidera cambiare il tipo di database sideve agire sui file di proprietà presenti all’interno dell’archivio pddConsole.war/WEB-INF/classes. Per ulteriori dettagli su comemodificare il tipo di database è possibile vedere Sezione 6.1.3.5.

La gestione centralizzata, è preconfigurata per gestire da remoto le porte di dominio, un registro dei servizi e un gestore even-ti. Verranno utilizzati i webservices di gestione/monitoraggio installati sulle singole Porte di dominio (vedi Sezione 6.3 e Se-zione 6.4) , sul registro servizi (vedi Sezione 6.2) e l’interfaccia webservice CRUD del Gestore Eventi (vedi Sezione 7). Leindicazioni su come accedere ai web services di gestione vengono definite nei seguenti paragrafi:

• accesso ai ws di gestione/monitoraggio delle PdD, descritto in Sezione 6.1.3.1

• accesso al ws di gestione del Registro dei Servizi, descritto in Sezione 6.1.3.2

• accesso al ws di gestione del Gestore Eventi, descritto in Sezione 6.1.3.3


65 / 84


È sufficiente copiare il file dist/pddConsole.war nella directory di deploy dell’application server: JBOSS_DIR/server/ISTANZA/deploy(es. /var/lib/jbossas/server/default/deploy).


• http://localhost:8080/pddConsole/login.do


L’applicazione produce dei log che registrano le operazioni smistate in remoto nei file /var/openspcoop/log/GestorePdD.log,/var/openspcoop/log/GestoreRegistroServizi.log e /var/openspcoop/log/GestoreGE.log. Per ulteriori informazioni su come per-sonalizzare i log vedi Sezione 6.1.3.7.



L’interfaccia web è preconfigurata per gestire un database interno di tipo postgresql e propaga configurazioni remote verso leporte di dominio gestite, verso un registro dei servizi e un Gestore Eventi. Il prodotto è tuttavia altamente configurabile agendosui file di proprietà presenti all’interno dell’archivio in pddConsole.war/WEB-INF/classes.


• Gestione/Monitoraggio delle Porte di Dominio

• Gestione del Registro dei Servizi

• Gestione del Gestore Eventi

• Gestione del sistema di autorizzazione

• Accesso al DBMS


• Logging


6.1.3.1 Gestione/Monitoraggio delle Porte di Dominio

Le porte di dominio gestite vengono registrate tramite l’interfaccia web. Al momento della registrazione, deve essere fornito l’in-dirizzo IP e la porta dove risiede il webservice di gestione e monitoraggio della porta di dominio (vedi Sezione 6.3 e Sezione 6.4),e l’indirizzo IP e la porta dove risiedono i servizi esposti dalla porta di dominio (openspcoop/PD,openspcoop/PA e openspcoo-p/IntegrationManager descritti in Sezione 3.2.7). I valori di default degli indirizzi ip e delle porte, proposti dall’interfaccia web,vengono definite dalle seguenti proprietà:

• pdd.indirizzoIP.pubblico e pdd.porta.pubblica, indirizzo IP e porta dove risiedono i servizi della porta di dominio. (Defaultip=127.0.0.1 e porta=80)





66 / 84

• pdd.indirizzoIP.gestione e pdd.porta.gestione, indirizzo IP e porta dove risiede il web service di gestione della porta di dominio.(Default ip=127.0.0.1 e porta=80)

L’interfaccia invocherà il web service di gestione della porta di dominio tramite una url costruita utilizzando come prefissohttp://ipgestione:portagestione/ e come suffisso quanto definito nella proprietà UrlWebServiceConfigurazione. Per default la urlutilizzata sarà http://ipgestione:portagestione/openspcoopConfigurazionePdD/Management

L’interfaccia, per i soggetti spcoop creati e associati ad una porta di dominio, crea un connettore http con url costruita utilizzan-do come prefisso http://ippubblico:portapubblica/ e come suffisso quanto definito nella proprietà UrlConnettoreSoggetto. Perdefault la url utilizzata sarà http://ippubblico:portapubblica/openspcoop/PA

La propagazione delle configurazione verso le porte di dominio viene abilitata attraverso la proprietà sincronizzazionePdd(Default: true).

Infine l’interfaccia, se viene utilizzata per monitorare lo stato di una porta di dominio, invocherà il web service di monitoraggiotramite una url costruita utilizzando come prefisso http://ipgestione:portagestione/ e come suffisso quanto definito nella proprietàUrlWebServiceMonitor. Per default la url utilizzata sarà http://ipgestione:portagestione/openspcoopMonitor/Monitor

NotaPer ogni porta di dominio gestita, deve essere aggiunta una coda JMS come descritto in Sezione 6.1.3.6.

6.1.3.2 Gestione del Registro dei Servizi

La propagazione delle configurazioni verso il registro dei servizi viene abilitata attraverso la proprietà sincronizzazioneRegistro(Default: true).

Tramite la proprietà UrlWebServiceRegistro viene indicato il WebService di gestione del Registro dei Servizi. (vedi Sezione 6.2)(Default: http://localhost:8080/openspcoopRegistroServizi/Management).

NotaPer la gestione remota del registro dei servizi deve essere aggiunta una coda JMS come descritto in Sezione 6.1.3.6.

6.1.3.3 Gestione del Gestore Eventi

La propagazione delle configurazioni verso il gestore eventi viene abilitata attraverso la proprietà sincronizzazioneGE (Default:true).

Tramite la proprietà UrlWebServiceGestoreEventi viene indicato il WebService di gestione del GestoreEventi. (vedi Sezione 7)(Default: http://localhost:8080/openspcoopGE/CRUD).

Deve essere indicato anche il Soggetto SPCoop che opera da Gestore Eventi, attraverso le proprietà tipo_soggetto e nome_soggetto(default, tipo=SPC e nome=GestoreEventi) e il nome del servizio applicativo che identifica il Gestore Eventi, attraverso leproprietà ServizioApplicativoGestoreEventi (default, nome_servizio_applicativo=ServizioApplicativoGestoreEventi).

NotaPer la gestione remota del gestore eventi deve essere aggiunta una coda JMS come descritto in Sezione 6.1.3.6.

6.1.3.4 Gestione del sistema di autorizzazione

La propagazione delle configurazioni, verso un sistema di autorizzazione agganciato alle Porta di Dominio (vedi Sezione 3.3.1.10),viene abilitata attraverso la proprietà sincronizzazioneLdap (Default: false).

Tramite la proprietà LDAPClassName deve essere indicata una classe java, contenente la logica di configurazione del sistema diautorizzazione. Tale classe deve implementare l’interfaccia presente in tools/web_interfaces/control_station/src/org/openspcoop/web/ctrlstat/driver/ILdapDriverCRUD.java.


67 / 84

NotaPer la gestione del sistema di autorizzazione deve essere aggiunta una coda JMS come descritto in Sezione 6.1.3.6.

NotaNon vengono fornite built-in in OpenSPCoop classi che implementano la configurazione del sistema di autorizzazione.


L’accesso al database dell’interfaccia web (vedi Sezione 6.1.2.1), viene definito tramite il file di configurazione datasour-ce.properties dove viene indicato, tramite la voce dataSource, il nome jndi di un dataSource registrato nell’albero JNDI del-l’A.S. È possibile fornire informazioni di contesto per la ricerca del dataSource, attraverso una o più voci dataSource.property.*,tramite la definizione di coppie nome/valore dove il nome viene preso al posto del carattere speciale *. (Default: dataSour-ce=org.openspcoop.dataSource.pddConsole e dataSource.property non definite).



L’accesso al broker JMS viene indicato, all’interno del file queue.properties, tramite la proprietà ConnectionFactory. Tale pro-prietà indica il nome jndi utilizzato dall’interfaccia web per accedere ad una connection factory registrata nell’albero JNDIdell’A.S. Il pool permetterà di creare connessioni e effettuare lookup verso il broker JMS sul quale è presente la coda descrittain Sezione 6.1.2.3. È possibile fornire informazioni di contesto per la ricerca delle risorse, attraverso una o più voci Connec-tionFactory.property.*, tramite la definizione di coppie nome/valore dove il nome viene preso al posto del carattere speciale *.(Default: ConnectionFactory e ConnectionFactory.property non definite).

I nomi JNDI delle code JMS sono definite all’interno del file infoGeneral.cfg:

• queue/OperazioniGestoreRegistro, coda per la propagazione verso il Registro dei Servizi; il nome JNDI viene indicato attra-verso la proprietà RegistroServiziQueue

• queue/NOMEPdD, code per la propagazione verso le porte di dominio OpenSPCoop; i nomi JNDI sono composti da unprefisso comune definito tramite la proprietà PdDQueuePrefix e dal nome delle porte di dominio realmente configurate tramitel’applicazione

• queue/GestoreEventi, coda per la propagazione verso il Gestore Eventi; il nome JNDI viene indicato attraverso la proprietàGestoreEventiQueue

• queue/SmistatoreOp, coda per lo smistamento delle operazioni, verso le altre code; il nome JNDI viene indicato attraverso laproprietà SmistatoreQueue

6.1.3.7 Logging





• Informazioni di debug sull’interfaccia, l’interfaccia emette informazioni di debug tramite la category log4j.category.ctrlcore.Per default tale category emette log sul file /var/openspcoop/log/ControlStationCore.log con verbosità DEBUG.



68 / 84

• Informazioni di debug sull’accesso al database, l’interfaccia emette informazioni di debug, riguardanti l’accesso al database,tramite le categories log4j.category.DRIVER_DB_CONFIGURAZIONE, log4j.category.DRIVER_DB_REGISTRO e log4j.category.DRIVER_DB_PDD_CONSOLE.Per default tali categories emettono log, con verbosità DEBUG, rispettivamente sui file /var/openspcoop/log/DriverConfigura-zioneDB.log, /var/openspcoop/log/DriverRegistroServiziDB.log e /var/openspcoop/log/DriverControlStationDB.log.

• Informazioni di auditing (per ulteriori dettagli vedi Release Notes: Versione 1.3, funzionalità di auditing sulle console grafiche), l’interfaccia emette informazioni di auditing tramite la category log4j.category.audit. Per default tale category emette log sulfile /var/openspcoop/log/AuditingControlStation.log con verbosità DEBUG.

• Informazioni sulla configurazione remota delle porte di dominio, l’interfaccia emette informazioni di debug, riguardanti losmistamento delle configurazioni verso le porte di dominio remote, tramite la category log4j.category.tracergestorepdd. Perdefault tale category emette log sul file /var/openspcoop/log/GestorePdd.log con verbosità DEBUG.

• Informazioni sulla configurazione remota del registro dei servizi, l’interfaccia emette informazioni di debug, riguardanti losmistamento delle configurazioni verso il registro dei servizi, tramite la category log4j.category.traceruddi. Per default talecategory emette log sul file /var/openspcoop/log/GestoreRegistroServizi.log con verbosità DEBUG.

• Informazioni sulla configurazione remota del gestore eventi, l’interfaccia emette informazioni di debug, riguardanti lo smista-mento delle configurazioni verso il gestore eventi, tramite la category log4j.category.gestore_eventi. Per default tale categoryemette log sul file /var/openspcoop/log/GestoreGE.log con verbosità DEBUG.

• Informazioni sulla configurazione del sistema di autorizzazione, l’interfaccia emette informazioni di debug, riguardanti losmistamento delle configurazioni verso il sistema di autorizzazione, tramite la category log4j.category.tracerldap. Per defaulttale category emette log sul file /var/openspcoop/log/GestoreLDAP.log con verbosità DEBUG.

• Informazioni sullo smistamento delle operazioni, l’interfaccia emette informazioni di debug, riguardanti lo smistamento del-le operazioni verso i gestori, tramite la category log4j.category.tracersmista. Per default tale category emette log sul file/var/openspcoop/log/Smistatore.log con verbosità DEBUG.




















69 / 84
















• generazioneAutomaticaPorteDelegate, all’aggiunta di una adesione in un accordo di servizio parte specifica, viene creataautomaticamente il componente di integrazione (PortaDelegata) necessario ad un servizio applicativo per poter effettivamentefruire del servizio SPCoop.

Tale funzionalità è attiva nell’interfaccia se l’opzione generazioneAutomaticaPorteDelegate assume il valore true (Default:true, valori possibili: true/false).









70 / 84





• Visualizzazione del numero di elementi di una lista, l’interfaccia è modificabile per poter far comparire o meno il totale deglielementi presenti in un elenco, nei link di accesso all’elenco stesso. Il numero di elementi viene visualizzato se la proprietàcontaListe assume il valore true (Default: true, valori possibili: true/false).







NotaLa proprietà singlePdD presente nel file infoGeneral.cfg non deve essere modificata. Tale proprietà indica all’interfaccia dilavorare in una modalità di gestione centralizzata; se modificata l’interfaccia funzionerà in modalità di gestione locale delle Pdde del Registro dei Servizi descritto nella sezione Sezione 5.1

NotaLe altre proprietà presenti nel file infoGeneral.cfg non vengono interpretate dalla versione della PddConsole descritta in questasezione; verrano utilizzate per la gestione locale delle Pdd e del Registro dei Servizi descritto nella sezione Sezione 5.1

6.2 Interfaccia WebService per la gestione CRUD del Registro dei Servizi


I sorgenti dell’applicazione sono disponibili all’interno della distribuzione nella directory tools/ws/management/src. Per proce-dere con la compilazione è necessario utilizzare l’utility Ant sul path tools/ws/management, eseguendo il seguente comando:

ant clean build_registro

La compilazione produce come risultato un archivio openspcoopRegistroServizi.war all’interno della directory dist installabilein un application server J2EE. L’archivio deve essere installato sulla macchina dove risiede il registro dei servizi da gestire.






71 / 84

6.2.2 Installazione

I paragrafi di questa sezione descrivono come procedere con l’installazione dell’interfaccia web service utilizzabile per la confi-gurazione di un registro dei servizi. Il web servizi può essere utilizzato per la configurazione di una qualsiasi tipologia di registrodei servizi, ad esclusione della versione XML. Come prerequisito è quindi richiesta una installazione di una tipologia di registrodei servizi descritta in Sezione 4

L’applicazione viene fornita sotto forma di archivio openspcoopRegistroServizi.war come risultato della compilazione dei sor-genti descritta in Sezione 6.2.1.


L’interfaccia web service per la configurazione del Registro dei Servizi di OpenSPCoop è preconfigurata per gestire un registrobasato su database di tipo postgresql.

Se si desidera cambiare il tipo di database o la tipologia del registro dei servizi si deve agire sui file di proprietà presenti all’internodell’archivio: openspcoopRegistroServizi.war/WEB-INF/classes.

Per ulteriori dettagli su come modificare la tipologia di registro dei servizi o il tipo di database gestito dall’interfaccia ws èpossibile vedere Sezione 6.2.3.1.


È sufficiente copiare il file dist/openspcoopRegistroServizi.war nella directory di deploy dell’application server: JBOSS_DIR/server/ISTANZA/deploy(es. /var/lib/jbossas/server/default/deploy).


• http://localhost:8080/openspcoopRegistroServizi/Management


• http://localhost:8080/openspcoopRegistroServizi/Management?wsdl

L’applicazione produce dei log che registrano le operazioni effettuate nel file /var/openspcoop/log/WebServiceRegistroServizi.log.Per ulteriori informazioni su come personalizzare i log vedi Sezione 6.2.3.2.


L’interfaccia web service per la configurazione del Registro dei Servizi di OpenSPCoop è preconfigurato per gestire un registrosu database di tipo postgresql. Il prodotto è tuttavia configurabile agendo sui file di proprietà presenti all’interno dell’archivio inopenspcoopRegistroServizi.war/WEB-INF/classes.



• Logging


L’applicazione web service si interfaccia per default ad un Registro dei Servizi DB di tipo postgresql. Se si vuole modificarela tipologia del registro dei servizi si deve agire sul file di configurazione infoGeneralManagement.properties impostando leproprietà factory e fileProperties relative alla tipologia desiderata. Il file di proprietà varia a seconda della tipologia di registrodei servizi scelto:


72 / 84

• DB (registro basato su db, factory=org.openspcoop.dao.registry.driver.FactoryDriverRegistroServiziDBCreator e fileProper-ties=registroDB.properties), gli accordi di servizio sono mantenuti su un database relazionale; devono essere indicati il tipo didatabase e le informazioni per accedervi tramite le seguenti proprietà

– tipoDatabase, indica il tipo di database scelto tra postgresql, mysql e oracle.– dataSource, nome jndi di un dataSource registrato nell’albero JNDI dell’A.S. è possibile fornire informazioni di contesto

per la ricerca del dataSource, attraverso una o più voci dataSource.property.*, tramite la definizione di coppie nome/valoredove il nome viene preso al posto del carattere speciale *. (Default: dataSource=org.openspcoop.dataSource.regserv edataSource.property non definite).

• WEB (registro basato su Web, factory=org.openspcoop.dao.registry.driver.FactoryDriverRegistroServiziWEBCreator e filePro-perties=registroWEB.properties), gli accordi di servizio sono mantenuti su un repository web accessibile tramite http; deveessere indicato come accedere all’area dati del repository web tramite le seguenti proprietà

– WebPathPrefix, corrispondente al path della directory contenente l’area dati in cui mantenere i contenuti del registro– WebUrlPrefix, corrispondente alla URL con cui l’area dati è raggiungibile via http

• UDDI (registro basato su UDDI, factory=org.openspcoop.dao.registry.driver.FactoryDriverRegistroServiziUDDICreator e fi-leProperties=registroUDDI.properties), gli accordi di servizio sono mantenuti su un repository web accessibile tramite http eindicizzati tramite un Registro UDDI; deve essere indicato come accedere all’area dati del repository web e come accedere alregistro UDDI tramite le seguenti proprietà

– WebPathPrefix, corrispondente al path della directory contenente l’area dati in cui mantenere i contenuti del registro– WebUrlPrefix, corrispondente alla URL con cui l’area dati è raggiungibile via http– UddiInquiryURL, corrispondente alla URL con cui è possibile interrogare il registro UDDI– UddiPublishURL, corrispondente alla URL con cui è possibile pubblicare oggetti sul registro UDDI– UddiUser, username necessaria all’autenticazione sul registro UDDI– UddiPassword, password necessaria all’autenticazione sul registro UDDI

Per un registro dei servizi con tipologia DB, deve essere definito un utente, per conto del quale l’interfaccia web service si occupadi creare gli oggetti sul registro. Tale utente viene definito dalla proprietà superUser all’interno del file iinfoGeneralManage-ment.properties (Default: amministratore).

6.2.3.2 Logging

L’interfaccia web è configurabile, per quanto riguarda le funzionalità di logging, tramite il file tracerManagement.log4j.properties.




• Informazioni di debug sull’interfaccia ws, l’interfaccia emette informazioni di debug tramite la category log4j.category.ws_registry.Per default tale category emette log sul file /var/openspcoop/log/WebServiceRegistroServizi.log con verbosità DEBUG.

6.3 Interfaccia WebService per la gestione CRUD della configurazione di una PdD


I sorgenti dell’applicazione sono disponibili all’interno della distribuzione nella directory tools/ws/management/src. Per proce-dere con la compilazione è necessario utilizzare l’utility Ant sul path tools/ws/management, eseguendo il seguente comando:

ant clean build_config

La compilazione produce come risultato un archivio openspcoopConfigurazionePdD.war all’interno della directory dist installa-bile in un application server J2EE. L’archivio deve essere installato sulla macchina dove risiede la configurazione della porta didominio da gestire.



73 / 84

6.3.2 Installazione

I paragrafi di questa sezione descrivono come procedere con l’installazione dell’interfaccia web service utilizzabile per la confi-gurazione di una porta di dominio. Il web servizi può essere utilizzato per una configurazione di tipologia DB. Come prerequisitoè quindi richiesta una installazione di una tipologia di configurazione DB descritta in Sezione 3.2.5

L’applicazione viene fornita sotto forma di archivio openspcoopConfigurazionePdD.war come risultato della compilazione deisorgenti descritta in Sezione 6.3.1.


L’interfaccia web service per la configurazione di una porta di dominio OpenSPCoop è preconfigurata per gestire una configura-zione basata su database di tipo postgresql.

Se si desidera cambiare il tipo di database o la tipologia della configurazione si deve agire sui file di proprietà presenti all’internodell’archivio: openspcoopConfigurazionePdD.war/WEB-INF/classes.

Per ulteriori dettagli su come modificare la tipologia o il tipo di database gestito dall’interfaccia ws è possibile vedere Sezio-ne 6.3.3.1.


È sufficiente copiare il file dist/openspcoopConfigurazionePdD.war nella directory di deploy dell’application server: JBOSS_DIR/server/ISTANZA/deploy(es. /var/lib/jbossas/server/default/deploy).


• http://localhost:8080/openspcoopConfigurazionePdD/Management


• http://localhost:8080/openspcoopConfigurazionePdD/Management?wsdl

L’applicazione produce dei log che registrano le operazioni effettuate nel file /var/openspcoop/log/WebServiceConfigPdD.log.Per ulteriori informazioni su come personalizzare i log vedi Sezione 6.3.3.2.


L’interfaccia web service per la configurazione di una porta di dominio OpenSPCoop è preconfigurata per gestire una confi-gurazione su database di tipo postgresql. Il prodotto è tuttavia configurabile agendo sui file di proprietà presenti all’internodell’archivio in openspcoopConfigurazionePdD.war/WEB-INF/classes.


• Tipologia della configurazione

• Logging

6.3.3.1 Tipologia della configurazione

L’applicazione web service si interfaccia per default ad una configurazione DB di tipo postgresql. Se si vuole modificare la tipo-logia si deve agire sul file di configurazione infoGeneralManagement.properties impostando le proprietà factory e filePropertiesrelative alla tipologia desiderata. Il file di proprietà varia a seconda della tipologia scelta:

• DB (configurazione basata su db, factory=org.openspcoop.dao.config.driver.FactoryDriverConfigurazioneDBCreator e filePro-perties=configDB.properties), i componenti di integrazione sono mantenuti su un database relazionale; devono essere indicatiil tipo di database e le informazioni per accedervi tramite le seguenti proprietà


74 / 84

– tipoDatabase, indica il tipo di database scelto tra postgresql, mysql e oracle.

– dataSource, nome jndi di un dataSource registrato nell’albero JNDI dell’A.S. è possibile fornire informazioni di contestoper la ricerca del dataSource, attraverso una o più voci dataSource.property.*, tramite la definizione di coppie nome/va-lore dove il nome viene preso al posto del carattere speciale *. (Default: dataSource=org.openspcoop.dataSource.pdd edataSource.property non definite).

6.3.3.2 Logging

L’interfaccia web è configurabile, per quanto riguarda le funzionalità di logging, tramite il file tracerManagement.log4j.properties.




• Informazioni di debug sull’interfaccia ws, l’interfaccia emette informazioni di debug tramite la category log4j.category.ws_config.Per default tale category emette log sul file /var/openspcoop/log/WebServiceConfigPdD.log con verbosità DEBUG.

6.4 Interfaccia WebService per il monitoraggio di una PdD

Il WebService per il monitoraggio di una porta di dominio permette sia di monitorare i messaggi in transito sulla porta didominio (consulta il database descritto in Sezione 3.2.3), sia di visualizzare i messaggi diagnostici emessi dalla porta (vediSezione 3.3.2.1).


I sorgenti dell’applicazione sono disponibili all’interno della distribuzione nella directory tools/ws/monitor/src. Per procederecon la compilazione è necessario utilizzare l’utility Ant sul path tools/ws/monitor, eseguendo il seguente comando:

ant clean build

La compilazione produce come risultato un archivio openspcoopMonitor.war all’interno della directory dist installabile in unapplication server J2EE. L’archivio deve essere installato sulla macchina dove risiede la porta di dominio da tenere sottomonitoraggio.

6.4.2 Installazione

I paragrafi di questa sezione descrivono come procedere con l’installazione dell’interfaccia web service utilizzabile per il moni-toraggio di una porta di dominio. Come prerequisito è quindi richiesta una installazione di una porta di dominio; il web servicesi interfaccia verso il database dei messaggi Sezione 3.2.3 e verso il database utilizzato per la raccolta dei messaggi diagnosticiSezione 3.3.2.1.

L’applicazione viene fornita sotto forma di archivio openspcoopMonitor.war come risultato della compilazione dei sorgentidescritta in Sezione 6.4.1.


L’interfaccia web service per il monitoraggio di una porta di dominio OpenSPCoop è preconfigurata per monitorare un databasedi tipo postgresql instanziato come descritto in Sezione 3.2.3.

Se si desidera cambiare il tipo di database si deve agire sui file di proprietà presenti all’interno dell’archivio: openspcoopMonitor.war/WEB-INF/classes (vedi Sezione 6.4.3.1 e Sezione 6.4.3.2.



75 / 84


È sufficiente copiare il file dist/openspcoopMonitor.war nella directory di deploy dell’application server: JBOSS_DIR/server/ISTANZA/deploy(es. /var/lib/jbossas/server/default/deploy).


• http://localhost:8080/openspcoopMonitor/Monitor


• http://localhost:8080/openspcoopMonitor/Monitor?wsdl

L’applicazione produce dei log che registrano le operazioni effettuate nel file /var/openspcoop/log/WSMonitorCore.log. Perulteriori informazioni su come personalizzare i log vedi Sezione 6.4.3.3.


L’interfaccia web service per il monitoraggio di una porta di dominio OpenSPCoop è preconfigurata per gestire un repository deimessaggi di tipo postgresql. Il prodotto è tuttavia configurabile agendo sui file di proprietà presenti all’interno dell’archivio inopenspcoopMonitor.war/WEB-INF/classes.


• Accesso al Repository dei Messaggi della PdD

• Accesso ai diagnostici emessi dalla PdD

• Logging

6.4.3.1 Accesso al Repository dei Messaggi della PdD

L’accesso al database contenente il repository dei messaggi della porta di dominio (vedi Sezione 3.2.3), viene definito tramite il fi-le di configurazione dataSourceMonitor.properties dove viene indicato, tramite la voce org.openspcoop.monitor.dataSource.openspcoop,il nome jndi di un dataSource registrato nell’albero JNDI dell’A.S. È possibile fornire informazioni di contesto per la ricerca deldataSource, attraverso una o più voci org.openspcoop.monitor.dataSource.openspcoop.property.*, tramite la definizione di cop-pie nome/valore dove il nome viene preso al posto del carattere speciale *. (Default: dataSource=org.openspcoop.dataSource edataSource.property non definite).

Il tipo di database viene indicato tramite la voce org.openspcoop.monitor.dataSource.openspcoop.tipoDatabase. I tipi di databasegestiti sono: postgresql/mysql/oracle (default: postgresql).

6.4.3.2 Accesso ai diagnostici emessi dalla PdD

L’accesso al database contenente i diagnostici emessi dalla porta di dominio (vedi Sezione 3.3.2.1), viene definito tramite il file diconfigurazione dataSourceMonitor.properties dove viene indicato, tramite la voce org.openspcoop.monitor.dataSource.msgdiagnostici,il nome jndi di un dataSource registrato nell’albero JNDI dell’A.S. È possibile fornire informazioni di contesto per la ricerca deldataSource, attraverso una o più voci org.openspcoop.monitor.dataSource.msgdiagnostici.property.*, tramite la definizione dicoppie nome/valore dove il nome viene preso al posto del carattere speciale *. (Default: dataSource=org.openspcoop.dataSource.msgDiagnosticie dataSource.property non definite).

Il tipo di database viene indicato tramite la voce org.openspcoop.monitor.dataSource.msgdiagnostici.tipoDatabase. I tipi didatabase gestiti sono: postgresql/mysql/oracle (default: postgresql).


76 / 84

6.4.3.3 Logging

L’interfaccia web è configurabile, per quanto riguarda le funzionalità di logging, tramite il file tracerMonitor.log4j.properties.




• Informazioni di debug sull’interfaccia ws, l’interfaccia emette informazioni di debug tramite la category log4j.category.ws_logger.Per default tale category emette log sul file /var/openspcoop/log/WSMonitorCore.log con verbosità DEBUG.

• Informazioni di debug sull’accesso al repositori dei messaggi, l’interfaccia emette informazioni di debug, riguardanti l’acces-so al database dei messaggi della porta di dominio, tramite la category log4j.category.DRIVER_DB_MONITORAGGIO. Perdefault tale category emette log, con verbosità DEBUG, sul file /var/openspcoop/log/DriverMonitoraggio.log.

• Informazioni di debug sull’accesso ai diagnostici, l’interfaccia emette informazioni di debug, riguardanti l’accesso al databasecontenente i diagnostici emessi dalla porta di dominio, tramite la category log4j.category.DRIVER_DB_LOGANALIZER. Perdefault tale category emette log, con verbosità DEBUG, sul file /var/openspcoop/log/DriverMSGDiagnostici.log.

7 Gestore Eventi

Il Gestore Eventi di OpenSPCoop (GE) è un servizio di coordinamento previsto dalla specifica SPCoop per permettere lo scambiodi buste eGov secondo l’architettura EDA. L’uso del GE permette ai Sistemi Applicativi interessati ad un certo servizio di ricevere,previa iscrizione a quel servizio presso il GE, le comunicazioni inviate dai Sistemi Applicativi pubblicatori. Da questo punto divista, il Gestore Eventi può essere considerato un normale servizio SPCoop, con una sua logica applicativa che consiste appuntonel coordinare, secondo una logica EDA, richiedenti e fruitori dei servizi SPCoop. Per ulteriori dettagli è possibile consultare ildocumento Il Gestore Eventi di OpenSPCoop

Situato nella distribuzione di OpenSPCoop in services/gestore_eventi, è organizzato tramite la seguente struttura:

• deploy, include i files che permettono la configurazione dell’ambiente necessario al corretto funzionamento del Gestore Eventi;

• example, include i Client utilizzati negli scenari esemplificativi della guida utente del GestoreEventi;

• src, include i sorgenti del progetto;

7.1 Compilazione dei sorgenti

NotaNon è possibile produrre attualmente una versione del Gestore Eventi installabile in un Servlet Container.

7.1.1 Gestore Eventi

I sorgenti dell’applicazione sono disponibili all’interno della distribuzione nella directory services/gestore_eventi/src. Per proce-dere con la compilazione è necessario utilizzare l’utility Ant sul path services/gestore_eventi, eseguendo il seguente comando:

ant clean build

La compilazione produce come risultato un archivio GestoreEventi.ear all’interno della directory dist installabile in un applica-tion server J2EE.


http://www.openspcoop.org/openspcoop/jsp/?sel=doc-file&guida=ge&rel=1.4&id=index.html


77 / 84

7.1.2 Interfaccia Web di gestione

I sorgenti dell’interfaccia web del gestore eventi sono disponibili all’interno della distribuzione nella directory tools/web_interfaces/ge/src.Per procedere con la compilazione è necessario utilizzare l’utility Ant sul path tools/web_interfaces/ge, eseguendo il seguentecomando:

ant clean build

La compilazione produce come risultato un archivio ge.war all’interno della directory dist installabile in un application serverJ2EE.

7.2 Installazione

I paragrafi di questa sezione descrivono come procedere con l’installazione dell’applicazione GestoreEventi e dell’interfacciaweb di gestione nell’application server JBoss 4.2.X / 5.x

Le applicazioni vengono fornite sotto forma, rispettivamente, di archivio GestoreEventi.ear e ge.war. Le applicazioni sono ilrisultato della compilazione dei sorgenti descritta in Sezione 7.1.1 e Sezione 7.1.2.

7.2.1 Configurazione del Database

Il GestoreEventi richiede l’installazione di un database relazionale nel quale devono essere registrate le tabelle utilizzate perla gestione delle comunicazioni ad evento . Attualmente lo sviluppo del GestoreEventi viene effettuato su tre tipi di database:Postgres v8, MySQL v5 e Oracle10gExpress.

Le tabelle SQL richieste sono descritte all’interno del file tools/web_interfaces/ge/deploy/sql/TIPO_DATABASE/GestoreEventi.sql.



1. Creazione Utente

[user@localhost]$ suParola d’ordine: XXX[root@localhost]# su - postgres-bash-3.1$ createuser -PEnter name of role to add: geEnter password for new role: geConferma password: geShall the new role be a superuser? (y/n) nShall the new role be allowed to create databases? (y/n) nShall the new role be allowed to create more new roles? (y/n) nCREATE ROLE


[user@localhost]$ suParola d’ordine: XXX[root@localhost]# su - postgres-bash-3.1$createdb -O ge geCREATE DATABASE

3. Abilitazione accesso dell’utente al Database, è possibile abilitare l’accesso editando il file /var/lib/pgsql/data/pg_hba.conf(come super utente). Abilitiamo quindi l’utente ge ad accedere al db ge, aggiungendo le seguenti righe al file:


78 / 84

local ge ge md5host ge ge 127.0.0.1 255.255.255.255 md5


[user@localhost]$ psql ge ge < tools/web_interfaces/ge/deploy/sql/TIPO_DATABASE/ ←↩GestoreEventi.sql

Password for user ge: ge


7.2.2 Pool di Connessioni

Il GestoreEventi richiede l’installazione di un pool di connessioni verso il DBMS che possieda come nome JNDI: org.openspcoop.dataSource.ge.

Un datasource di esempio per l’application server JBoss viene fornito in tools/web_interfaces/ge/deploy/datasource/jboss/gestoreeventi-ds.xml. Il file permette di creare la risorsa nella propria installazione dell’A.S., attraverso la configurazione e la successiva copiadel file in JBOSS_DIR/server/default/deploy.


NotaPer ulteriori informazioni su come utilizzare un datasource registrato con nome JNDI diverso dal default è possibile consultarei paragrafi Sezione 7.3.1.1 e Sezione 7.3.2.1.


7.2.3 Configurazione delle code JMS

Il GestoreEventi necessita di alcune code JMS.

All’interno della distribuzione nella in services/gestore_eventi/deploy/code_jms/BROKER/ge-destinations-service.xml vengonofornite le configurazioni delle code JMS per la loro creazione in JBoss 4.x e in JBoss 5.x:

• services/gestore_eventi/deploy/code_jms/jbossMQ/ge-destinations-service.xml, le code sono istanziabili in JBoss 4.x attraversola copia del file in JBOSSDIR/server/default/deploy/jms

• services/gestore_eventi/deploy/code_jms/jbossMessaging/ge-destinations-service.xml, le code sono istanziabili in JBoss 5.xattraverso la copia del file in JBOSSDIR/server/default/deploy/messaging

7.2.4 Configurazione Iniziale

Sia il GestoreEventi che l’interfaccia web di gestione sono preconfigurati per gestire un database di tipo postgresql.

Se si desidera cambiare il tipo di database si deve agire sui file di proprietà presenti all’interno degli archivi, in GestoreEven-ti.ear/properties e ge.war/WEB-INF/classes.

Per ulteriori dettagli su come modificare il tipo di database è possibile consultare i paragrafi Sezione 7.3.1.1 e Sezione 7.3.2.1.


79 / 84

7.2.5 Deploy del Software GestoreEventi

L’applicazione GestoreEventi GestoreEventi.ear deve essere copiata nella directory di deploy dell’application server: JBOSS_DIR/server/ISTANZA/deploy(es. /var/lib/jbossas/server/default/deploy).

Una volta effettuato il deploy, l’applicazione GestoreEventi fornisce tre servizi, rispettivamente per la pubblicazione/prelevamen-to di messaggi, per la gestione della configurazione, ed un esempio di webService utilizzato per la ricezione delle notifiche daparte del gestore. Questi 3 servizi saranno rispettivamente accessibili agli indirizzi:

• http://localhost:8080/openspcoopGE/GE

• http://localhost:8080/openspcoopGE/CRUD

• http://localhost:8080/openspcoopGE/Notifica

L’applicazione produce dei log che registrano le operazioni effettuate nel file /var/openspcoop/log/gestoreEventi.log. Per ulterioriinformazioni su come personalizzare i log vedi Sezione 7.3.1.3.

7.2.6 Deploy dell’Interfaccia di Gestione del GestoreEventi

L’interfaccia di gestione ge.war deve essere copiata nella directory di deploy dell’application server: JBOSS_DIR/server/ISTANZA/deploy(es. /var/lib/jbossas/server/default/deploy).

Una volta effettuato il deploy dovrebbe essere possibile accedervi all’indirizzo:

• http://localhost:8080/ge/login.do


L’applicazione produce dei log che registrano le operazioni effettuate nel file /var/openspcoop/log/InterfacciaGE.log. Perulteriori informazioni su come personalizzare i log vedi Sezione 7.3.2.2.

7.2.7 Configurazione dell’ambiente SPCoop

Il Gestore Eventi non deve essere accessibile direttamente, ma soltanto tramite di una Porta di Dominio, come descritto neldocumento Il Gestore Eventi di OpenSPCoop . Sulla porta di Dominio è quindi necessario configurare:

• il soggetto che eroga il servizio di Gestore Eventi;

• i Servizi Applicativi che mappano le varie modalità di interazione dell’Applicazione Gestore Eventi con la Porta di Dominio;

• le porte applicative necessarie per consegnare all’applicazione Gestore Eventi i contenuti delle buste SPCoop ricevute dallaPdD;

• le porte delegate usate dall’applicazione di Gestore Eventi per consegnare i messaggi e/o le notifiche agli iscritti.

Mostriamo di seguito, a titolo esemplificazione, le configurazione necessarie per la Porta di Dominio e per il Registro dei servizi.Le configurazioni vengono fornite tramite formalismo xml descritto in Guida Utente XML ). Le stesse configurazioni possonoessere create anche tramite le altre tipologie della configurazione della PdD e del registro dei servizi descritte in Sezione 3.2.5 eSezione 3.2.6.

Le configurazione di esempio, nel formalismo xml, sono fornite anche all’interno della distribuzione nella directory services/-gestore_eventi/deploy/config_file. Tali file contengono anche le configurazioni utilizzate dagli esempi descritti nel documento IlGestore Eventi di OpenSPCoop






80 / 84

7.2.7.1 Configurazione del Registro dei Servizi

Di seguito viene mostrato un frammento di registro dei servizi, di tipologia xml, necessario per il corretto funzionamento delGestore Eventi.

<accordo-servizio nome="ASGetMessaggioNotificato" profilo-collaborazione="sincrono" ←↩

utilizzo-senza-azione="true" />



...



<soggetto-spcoop tipo="SPC" nome="GestoreEventi">

<connettore tipo="http" nome="PdDGestoreEventi"><property nome="location" valore="http://localhost:8080/openspcoop/PA" />

</connettore>

<servizio tipo="SPC" nome="GetMessaggioNotificato" accordo-servizio=" ←↩

ASGetMessaggioNotificato"/>



...

</soggetto-spcoop>

7.2.7.2 Configurazione della Porta di Dominio

Di seguito viene mostrato un frammento di configurazione della porta di dominio, di tipologia xml, necessaria per il correttofunzionamento del Gestore Eventi.

<soggetto-spcoop tipo="SPC" nome="GestoreEventi" >

<servizio-applicativo nome="GestoreEventiWS" ><invocazione-porta>

<credenziali tipo="basic" user="gestoreEventi" password="123456" /></invocazione-porta><invocazione-servizio get-message="abilitato" invio-per-riferimento="abilitato">

<connettore tipo="http" nome="gestoreEventi_pubblicazioneMessaggio"><property nome="location" valore="http://localhost:8080/openspcoopGE/GE" />

</connettore><gestione-errore comportamento="rispedisci" cadenza-rispedizione="5">

<codice-trasporto valore-minimo="200" valore-massimo="200" comportamento="accetta" ←↩/>

<soap-fault comportamento="rispedisci" /></gestione-errore>

</invocazione-servizio></servizio-applicativo>

<servizio-applicativo nome="GestoreMessaggiNotificati" ><invocazione-servizio risposta-per-riferimento="abilitato">

<connettore tipo="http" nome="gestoreEventi_prelevaMessaggio"><property nome="location" valore="http://localhost:8080/openspcoopGE/GE" />

</connettore>


81 / 84

<gestione-errore comportamento="rispedisci" cadenza-rispedizione="5"><codice-trasporto valore-minimo="200" valore-massimo="200" comportamento="accetta" ←↩

/><soap-fault comportamento="rispedisci" />

</gestione-errore></invocazione-servizio>

</servizio-applicativo>

<servizio-applicativo nome="ConsegnaEventi" ><invocazione-porta invio-per-riferimento="abilitato">

<credenziali tipo="basic" user="consegnatoreEventi" password="123456" /></invocazione-porta>


<servizio-applicativo nome="NotificatoreEventi" ><invocazione-porta>

<credenziali tipo="basic" user="notificatoreEventi" password="123456" /></invocazione-porta>


<porta-delegata nome="consegnaEvento" autenticazione="basic" autorizzazione="openspcoop"><soggetto-spcoop-erogatore tipo="SPC" identificazione="inputBased" /><servizio tipo="SPC" identificazione="inputBased" /><azione identificazione="inputBased" /><servizio-applicativo nome="ConsegnaEventi" />

</porta-delegata>

<porta-delegata nome="notificaEvento" autenticazione="basic" autorizzazione="openspcoop"><soggetto-spcoop-erogatore tipo="SPC" identificazione="inputBased" /><servizio tipo="SPC" identificazione="inputBased" /><azione identificazione="inputBased" /><servizio-applicativo nome="NotificatoreEventi" />

</porta-delegata>

<porta-applicativa nome="PubblicaEvento"><servizio tipo="SPC" nome="PubblicazioneEvento" /><servizio-applicativo nome="GestoreEventiWS" />

</porta-applicativa>

<porta-applicativa nome="GetMsgNotificato"><servizio tipo="SPC" nome="GetMessaggioNotificato" /><servizio-applicativo nome="GestoreMessaggiNotificati" />

</porta-applicativa>

</soggetto-spcoop>

7.3 Configurazione

7.3.1 Configurazione del Gestore Eventi

Il GestoreEventi è preconfigurata per gestire un database di tipo postgresql. Il prodotto è tuttavia altamente configurabile agendosui file di proprietà presenti all’interno dell’archivio in GestoreEventi.ear/properties.



82 / 84

• Accesso al DBMS


• Logging

• Personalizzazione dell’applicazione


L’accesso al database (vedi Sezione 7.2.1), viene definito tramite il file di configurazione GestoreEventi.properties dove vieneindicato, tramite la voce org.openspcoop.gestoreeventi.datasource, il nome jndi di un dataSource registrato nell’albero JNDI del-l’A.S. È possibile fornire informazioni di contesto per la ricerca del dataSource, attraverso una o più voci org.openspcoop.gestoreeventi.datasource.property.*,tramite la definizione di coppie nome/valore dove il nome viene preso al posto del carattere speciale *. (Default: dataSour-ce=org.openspcoop.dataSource.ge e dataSource.property non definite).

Il tipo di database viene indicato tramite la voce org.openspcoop.gestoreeventi.tipoDatabase. I tipi di database gestiti sono:postgresql/mysql/oracle (default: postgresql).


La configurazione riguardante l’accesso al broker JMS viene indicata all’interno del file GestoreEventi.properties.

Tramite la proprietà org.openspcoop.gestoreeventi.connectionFactory viene indicato il nome jndi utilizzato dall’interfaccia webper accedere ad una connection factory registrata nell’albero JNDI dell’A.S. Il pool permetterà di creare connessioni e effettuarelookup verso il broker JMS sul quale sono presenti la coda descritte in Sezione 7.2.3. È possibile fornire informazioni dicontesto per la ricerca delle risorse, attraverso una o più voci org.openspcoop.gestoreeventi.connectionFactory.property.*, tramitela definizione di coppie nome/valore dove il nome viene preso al posto del carattere speciale *. (Default: ConnectionFactory eConnectionFactory.property non definite).

I nomi JNDI delle code JMS vengono indicate tramite le proprietà org.openspcoop.gestoreeventi.consegnaEventiQueue e org.openspcoop.gestoreeventi.notificaEventiQueue.È possibile fornire informazioni di contesto per la ricerca delle code attraverso una o più voci org.openspcoop.gestoreeventi.queue.property.*,tramite la definizione di coppie nome/valore come viene fatto per la ConnectionFactory. (Default: consegnaEventiQueue=queue/ConsegnaEventi,notificaEventiQueue=queue/NotificaEventi e queue.property non definite).

7.3.1.3 Logging

Il GestoreEventi è configurabile, per quanto riguarda le funzionalità di logging, tramite il file logger.log4j.properties.


Il file contiene delle Category (log4j.category.*) che rappresentano un Logger utilizzato dal GestoreEventi per emettere log di uncerto tipo. Ad ogni Category sono associabili uno o più Appender (log4j.appender.*, ad esempio log4j.appender.tracer.file) cherappresentano una risorse su cui memorizzare i log. Le risorse utilizzabili tramite il framework sono svariate, da filesystem, adatabase, ad e-mail etc...


• Informazioni di debug sull’interfaccia, l’interfaccia emette informazioni di debug tramite la category log4j.category.openspcoop.gestoreeventi.core.Per default tale category emette log sul file /var/openspcoop/log/gestoreEventi.log con verbosità DEBUG.

• Informazioni di consegna di un evento, l’interfaccia emette informazioni riguardanti la consegna di un evento tramite la cate-gory log4j.category.openspcoop.gestoreeventi.consegna. Per default tale category emette log sul file /var/openspcoop/log/ge-storeEventiMDBConsegna.log con verbosità DEBUG.

• Informazioni di notifica di un evento, l’interfaccia emette informazioni riguardanti la notifica di un evento tramite la categorylog4j.category.openspcoop.gestoreeventi.notifica. Per default tale category emette log sul file /var/openspcoop/log/gestoreE-ventiMDBNotifica.log con verbosità DEBUG.



83 / 84

• Informazioni di verifica della consistenza del repository degli eventi, l’interfaccia emette informazioni riguardanti la verificadella consistenza del repository degli eventi, effettuata da un componente schedulato ad intervalli regolari, tramite la categorylog4j.category.openspcoop.gestoreeventi.timerMsgEvasi. Per default tale category emette log sul file /var/openspcoop/log/ge-storeEventiWSNotifica.log con verbosità DEBUG.

• Informazioni emesse dall’esempio di webService utilizzato per la ricezione delle notifiche, l’interfaccia emette tali informa-zioni tramite la category log4j.category.openspcoop.gestoreeventi.wsnotifica. Per default tale category emette log sul file/var/openspcoop/log/gestoreEventiWSNotifica.log con verbosità DEBUG.

7.3.1.4 Personalizzazione dell’applicazione

Le proprietà presenti nel file GestoreEventi.properties permettono di personalizzare il comportamento del GestoreEventi. Diseguito vengono riportate tali proprietà, catalogate funzionalmente:

• Accesso alla Porta di Dominio

La proprietà org.openspcoop.gestoreeventi.portaDiDominio.url, indica la url della Porta di Dominio che gestisce il GestoreEventi. (Default: url=http://localhost:8080/openspcoop)

Tramite le proprietà org.openspcoop.gestoreeventi.consegna.* vengono indicati i parametri di consegna di un evento quali laporta delegata da utilizzare sulla porta di dominio, e l’identità del servizio applicativo che si occupa della consegna (Default:portaDelegata=consegnaEvento, user=consegnatoreEventi e password=123456). Vedi Sezione 7.2.7.

Tramite le proprietà org.openspcoop.gestoreeventi.notifica.*, vengono indicati i parametri di notifica di un evento quali laporta delegata da utilizzare sulla porta di dominio, e l’identità del servizio applicativo che si occupa della notifica (Default:portaDelegata=notificaEvento, user=notificatoreEventi e password=123456). Vedi Sezione 7.2.7.

Tramite le proprietà org.openspcoop.gestoreeventi.user e org.openspcoop.gestoreeventi.password viene definita l’identita delservizio applicativo che impersonifica l’applicazione Gestore Eventi nella porta di dominio. (Default: user=gestoreEventi epassword=123456). Vedi Sezione 7.2.7.

• Scadenza Eventi

La proprietà org.openspcoop.gestoreeventi.scadenzaMessaggiDefault, indica l’intervallo di validità di un evento in minuti.

NotaL’intervallo di scadenza di un messaggio pubblicato deve essere minore dell’intervallo di scadenza dei mes-saggi gestiti dalla Porta di Dominio OpenSPCoop posta davanti all’applicazione GestoreEventi (vedi proprie-tà org.openspcoop.pdd.repository.scadenzaMessaggi del file openspcoop.properties, descritta in Sezione 3.3.1.3).(Default:scadenzaMessaggiDefault=7200 )

• Timer per il controllo dei eventi scaduti

La proprietà org.openspcoop.gestoreeventi.timerMsgEvasiScaduti, indica il nome jndi di un EJB Timer utilizzato nell’archi-tettura dell’applicazione per gestire gli eventi scaduti. È possibile fornire informazioni di contesto per la ricerca nell’alberoJNDI, attraverso una o più voci org.openspcoop.gestoreeventi.ejb.property.*, tramite la definizione di coppie nome/valore doveil nome viene preso al posto del carattere speciale *. (Default: timerMsgEvasiScaduti=ejb/MessaggiEvasiEJB e ejb.propertynon definite);

L’intervallo di tempo, in minuti, con cui viene eseguito il timer è definito dalla proprietà org.openspcoop.gestoreeventi.timeoutMsgEvasiScaduti(Default timeoutMsgEvasiScaduti=1).

• BeanCore del GestoreEventi

Le funzionalità implementate dal GestoreEventi sono tutte disponibili tramite un EJB Bean. La proprietà org.openspcoop.gestoreeventi.beanCoreindica il nome jndi di EJB di tale bean. È possibile fornire informazioni di contesto per la ricerca nell’albero JNDI, attraversouna o più voci org.openspcoop.gestoreeventi.ejb.property.*, tramite la definizione di coppie nome/valore dove il nome vienepreso al posto del carattere speciale *. (Default: beanCore=ejb/GestoreEventiEJB e ejb.property non definite);

NotaIl file di proprietà CodiciErrore.properties contiene i codici di errore generati dal Gestore Eventi.


84 / 84

7.3.2 Configurazione dell’interfaccia web di gestione

L’interfaccia di gestione del GestoreEventi è preconfigurata per gestire un database di tipo postgresql. Il prodotto è tuttaviaaltamente configurabile agendo sui file di proprietà presenti all’interno dell’archivio in ge.war/WEB-INF/classes.


• Accesso al DBMS

• Logging



L’accesso al database (vedi Sezione 7.2.1), viene definito tramite il file di configurazione datasource.properties dove vieneindicato, tramite la voce dataSource, il nome jndi di un dataSource registrato nell’albero JNDI dell’A.S. È possibile fornire infor-mazioni di contesto per la ricerca del dataSource, attraverso una o più voci dataSource.property.*, tramite la definizione di coppienome/valore dove il nome viene preso al posto del carattere speciale *. (Default: dataSource=org.openspcoop.dataSource.ge edataSource.property non definite).


7.3.2.2 Logging

L’interfaccia web del GestoreEventi è configurabile, per quanto riguarda le funzionalità di logging, tramite il file tracer.log4j.properties.




• Informazioni di debug sull’interfaccia, l’interfaccia emette informazioni di debug tramite la category log4j.category.tracerge.Per default tale category emette log sul file /var/openspcoop/log/InterfacciaGE.log con verbosità DEBUG.

• Informazioni di auditing (per ulteriori dettagli vedi Release Notes: Versione 1.3, funzionalità di auditing sulle console grafiche), l’interfaccia emette informazioni di auditing tramite la category log4j.category.audit. Per default tale category emette log sulfile /var/openspcoop/log/AuditingGE.log con verbosità DEBUG.

Documents

Guida Installazione della distribuzione sorgente di ... · 3.3.1.8 Validazione Semantica della Conﬁgurazione e del Registro dei Servizi . . . . . . . . . . . . .17