Guida Installazione della distribuzione sorgente di OpenSPCoop 1.4

Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
Guida Installazione della distribuzione sorgente di
OpenSPCoop 1.4
i
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
Copyright © 2005-2011 Link.it s.r.l.
ii
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
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
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
Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.3.1
9
3.2
3.3
Aspetti di Configurazione Generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
3.3.2
3.3.3
iv
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
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
4
Interoperabilità rispetto ad altre implementazioni di Porta di Dominio . . . . . . . . . . . . . . . . . . . 38
Registro dei Servizi
4.1
Interfaccia Web del Registro dei Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1.1
4.1.2
4.1.3
4.2
39
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
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
Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.3.1
Tipologia del Registro dei Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.3.2
Accesso al DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.3.3
Accesso al broker JMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.3.4
Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1.3.5
Personalizzazione dell’interfaccia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Interfaccia WebService del Registro dei Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
4.2.1
Compilazione dei sorgenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.1.1
4.2.2
4.2.3
5
4.2.2.1
Configurazione Iniziale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.2.2
Deploy del Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.3.1
Tipologia del Registro dei Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.3.2
Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
48
PddConsole con Registro dei Servizi locale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1.1
5.1.2
5.1.3
5.2
Interfaccia WebService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Pdd Console
5.1
v
Compilazione dei sorgenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1.1.1
Interfaccia Web per Application Server J2EE . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1.1.2
Interfaccia Web per Servlet Container . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.2.1
Configurazione del Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.2.2
Pool di Connessioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.1.2.3
Configurazione Iniziale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.1.2.4
Deploy del Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
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.1.3.6
Personalizzazione dell’interfaccia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
PddConsole con Registro dei Servizi centralizzato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.1
5.2.2
5.2.3
Compilazione dei sorgenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.1.1
Interfaccia Web per Application Server J2EE . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.1.2
Interfaccia Web per Servlet Container . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2.2.1
Configurazione del Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2.2.2
Pool di Connessioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2.2.3
Configurazione Iniziale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2.2.4
Deploy del Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
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
5.2.3.6
Personalizzazione dell’interfaccia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
6
Pdd Console per la gestione centralizzata
6.1
6.1.1
Compilazione dei sorgenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.1.2
Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.2.2
6.2.3
Configurazione del Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.1.2.2
Pool di Connessioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.1.2.3
Configurazione delle code JMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.1.2.4
Configurazione Iniziale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.1.2.5
Deploy del Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
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.6
Accesso al broker JMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.1.3.7
Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.1.3.8
Personalizzazione dell’interfaccia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Compilazione dei sorgenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.2.2.1
Configurazione Iniziale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.2.2.2
Deploy del Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.2.3.1
Tipologia del Registro dei Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.2.3.2
Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Interfaccia WebService per la gestione CRUD della configurazione di una PdD . . . . . . . . . . . . . . . . . . 72
6.3.1
Compilazione dei sorgenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.3.2
Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.3.3
6.4
6.1.2.1
Interfaccia WebService per la gestione CRUD del Registro dei Servizi . . . . . . . . . . . . . . . . . . . . . . . 70
6.2.1
6.3
61
Interfaccia Web di gestione centralizzata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.1.3
6.2
vi
6.3.2.1
Configurazione Iniziale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.3.2.2
Deploy del Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.3.3.1
Tipologia della configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.3.3.2
Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Interfaccia WebService per il monitoraggio di una PdD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.4.1
Compilazione dei sorgenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.4.2
Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.4.3
6.4.2.1
Configurazione Iniziale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.4.2.2
Deploy del Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
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
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
7
Gestore Eventi
7.1
7.2
7.3
vii
76
Compilazione dei sorgenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.1.1
Gestore Eventi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.1.2
Interfaccia Web di gestione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
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
Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.3.1
7.3.2
Configurazione del Gestore Eventi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.3.1.1
Accesso al DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.3.1.2
Accesso al broker JMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.3.1.3
Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.3.1.4
Personalizzazione dell’applicazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Configurazione dell’interfaccia web di gestione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.3.2.1
Accesso al DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.3.2.2
Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.3.2.3
Personalizzazione dell’interfaccia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
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
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
1
1 / 84
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; su
questi 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 sistema
centralizzato di gestione dell’intero ambiente SPCoop. Inoltre sono presenti vari tool web services e ’command-line’ per la
gestione 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 che
permette 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
3.1
3.1.1
Porta di Dominio OpenSPCoop
Compilazione dei sorgenti
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 la
compilazione è 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
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
3.1.2
2 / 84
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 sia
installabile in un servlet container (es. Tomcat). Per procedere con questo tipo di compilazione, sulla radice della distribuzione
eseguire 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 OpenSPCoop installabile in un servlet container. Con questa versione della porta di dominio non è possibile usufruire di tutte le
funzionalità 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 JBoss
4.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 server
JBoss) 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 porta
di dominio
3. /etc/openspcoop, necessaria solo in caso di configurazione della PdD (vedi Sezione 3.2.5) o del registro dei servizi (vedi
Sezione 4) in formato xml, contiene i relativi file xml.
Nota
La porta di dominio deve possedere i diritti di lettura sulla directory di configurazione (/etc/openspcoop) e di scrittura su quelle
di lavoro (/var/openspcoop); se il server dove è in esecuzione gira come utente jboss/tomcat, sarà necessario dare i diritti in
scrittura 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
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
3.2.2
3 / 84
Configurazione delle code JMS
La PdD OpenSPCoop distributa sotto forma di archivio J2EE OpenSPCoop.ear necessita di alcune code JMS. Se si sta installando
la 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 configurazioni 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 copia
del 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 la
copia 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 la
gestione dei messaggi. Attualmente lo sviluppo di OpenSPCoop viene effettuato su tre tipi di database: Postgres v8, MySQL v5
e Oracle10gExpress.
Le tabelle SQL richieste da OpenSPCoop sono descritte all’interno del file deploy/pdd/SQL_Table/TIPO_DATABASE/OpenSPCoop.sql.
Nota
La porta di dominio deve possedere i diritti di lettura/scrittura sulle suddette tabelle.
Nota
A seconda del tipo di repository dei messaggi impostato per la porta di dominio (file system o db; per ulteriori dettagli vedi
Sezione 3.3.1.3), la tabella DEFINIZIONE_MESSAGGI definita nel file OpenSPCoop.sql deve possedere o meno la colonna
MSG_BYTES. Di default OpenSPCoop utilizza il fileSystem per implementare il msgRepository, e quindi la definizione fornita
nel 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 PostgreSQL
su sistema operativo Linux.
1. Creazione Utente
[user@localhost]$ su
Parola d’ordine: XXX
[root@localhost]# su - postgres
-bash-3.1$ createuser -P
Enter name of role to add: openspcoop
Enter password for new role: openspcoop
Conferma password: openspcoop
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n
CREATE ROLE
2. Crezione Database
[user@localhost]$ su
Parola d’ordine: XXX
[root@localhost]# su - postgres
-bash-3.1$createdb -O openspcoop openspcoop
CREATE DATABASE
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
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 righe
al file:
local openspcoop openspcoop md5
host 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 nella
cartella JBOSS/server/default/lib.
Nota
Ulteriori tabelle SQL possono essere necessarie in caso si voglia registrare i messaggi diagnostici e/o tracciare le buste eGov
su database utilizzando gli appender forniti nella distribuzione (Vedi Sezione 3.3.2 per ulteriori dettagli ). In tal caso le tabelle
richieste sono descritte nel file fornito con la distribuzione in deploy/pdd/SQL_Table/TIPO_DATABASE/Tracciamento.sql. Il file
definisce 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 di
connessioni anche verso il broker JMS.
• Database, la configurazione di default della porta di dominio richiede un datasource con nome org.openspcoop.dataSource per
creare 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. Il
file permette di creare la risorsa nella propria installazione dell’A.S., attraverso la configurazione e la successiva copia del file
in JBOSS_DIR/server/default/deploy.
In alternativa, per l’application server JBoss, è possibile utilizzare un datasource realizzato tramite l’applicazione openspcoopSysconfig; 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. Il
file permette di creare la risorsa nella propria installazione di Tomcat, attraverso la configurazione e la successiva copia del file
in 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 con
nome org.openspcoop.jmsPool per creare connessioni (e sessioni che permettano la gestione applicativa della transazione) verso
il Broker JMS. Una connection factory di esempio viene fornita in deploy/pdd/code_jms/BROKER/openspcoop-jms-ds.xml per
la 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 copia
del 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 la
copia del file in JBOSSDIR/server/default/deploy/messaging
In alternativa è possibile utilizzare una connection factory realizzata tramite l’applicazione openspcoopSysconfig, per ulteriori
dettagli è possibile leggere la documentazione dell’applicazione in doc/sysconfig.readme.
Nota
Per ulteriori informazioni su come utilizzare connection factory o datasource registrati con nomi JNDI diversi dai default di
OpenSPCoop vedi Sezione 3.3.1.4.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
5 / 84
Nota
L’applicazione openspcoopSysconfig, disponibile nella distribuzione in tools/sysconfig, permette di creare pool di risorse e registrarli nell’albero JNDI del proprio Application Server. La definizione dei pool deve essere fornita tramite un file xml che rispetti
lo schema in tools/sysconfig/src/schemi/sysconfig.xsd . Tutti i pool indicati nella guida utente/installazione e richiesti dai vari
prodotti rilasciati con la distribuzione di OpenSPCoop sono descritti in una configurazione di esempio dell’applicazione openspcoopSysconfig 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 da
gestire, in scenari non molto dinamici e con un basso numero di soggetti e servizi. È il modo migliore di usare OpenSPCoop
in ambiente di testing e di sviluppo, mentre non si addice in ambiente di produzione o in generale in casi complessi. La
configurazione 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 molto
dinamici e il numero di soggetti e servizi da gestire risulta elevato. Infatti la configurazione su Database consente la gestione
tramite una web application che è descritta in Sezione 5. La configurazione DB della Porta di Dominio è documentata nella
Guida Utente della Porta di Dominio OpenSPCoop .
Quick Start
Supponendo che si desideri utilizzare una configurazione della Porta di Dominio in modalità XML è necessario installare nella
directory di configurazione (per default /etc/openspcoop) il file config.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 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 iniziale. 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 essere
modificato il file xml se si desidera impostare un registro dei servizi di diverso tipo (vedi Sezione 4) o disponibile in un path del
file 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 essere
indicato 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 nella
distribuzione 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 essere
registrate le tabelle che conterranno gli elementi di configurazione. Tale database differisce a seconda del tipo di interfaccia di
gestione che gli si vuole associare:
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
6 / 84
• Interfaccia PDDConsole con Registro dei Servizi locale, permette di gestire sia gli elementi di integrazione della Porta di
Dominio che un registro dei servizi integrato. Le tabelle SQL richieste da questo tipo di interfaccia si trovano nella distribuzione all’interno del file tools/web_interfaces/control_station/deploy/sql/TIPO_DATABASE/single_pdd/PddConsole.sql. Per
ulteriori dettagli sulla creazione del database vedi Sezione 5.1.
• Interfaccia PDDConsole con Registro dei Servizi centralizzato, permette di gestire solo elementi di integrazione della Porta
di 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 database
vedi Sezione 5.2.
Una volta creato il database per l’interfaccia desiderata, deve essere indicato di utilizzare la tipologia di configurazione basata su
DBMS 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 . Esempi
di 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 Dominio
OpenSPCoop:
• 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 usare
OpenSPCoop in ambiente di testing e di sviluppo, mentre non si addice in ambienti reali. La configurazione XML del Registro
dei Servizi è documentata nella Guida Utente XML .
• Registro dei Servizi DB, il registro è realizzato come un database relazionale. Si addice per ambienti reali dove gli scenari
possono essere dinamici e il numero di soggetti e servizi da gestire risulta elevato. Infatti in questo caso il registro può essere
gestito tramite un’interfaccia web in maniera integrata alla configurazione della PdD (Sezione 5) oppure con un’interfaccia
web di gestione dedicata (Sezione 4.1). La configurazione DB del registro dei servizi è documentata nella Guida Utente della
Porta di Dominio OpenSPCoop .
• Registro dei Servizi WEB, il registro è realizzato come un sito web che mantiene un insieme di oggetti descritti in xml e
accessibili via http (Registro dei Servizi HTTP ); questo registro può essere gestito tramite l’interfaccia web di gestione del
Registro (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 (Interfaccia
WS per il Registro dei Servizi ). L’interfaccia espone tramite WebServices uno qualsiasi dei tipi di registri descritti in questo
elenco.
Quick Start
Supponendo che si desideri utilizzare un registro dei servizi in modalità XML è necessario installare nella directory di configurazione (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 Utente
XML
Di seguito vengono riportate le indicazioni su come indicare le informazioni di accesso ad un registro dei servizi di OpenSPCoop
all’interno delle due tipologie di configurazione disponibili per la Porta di Dominio OpenSPCoop. Per l’installazioni di una
tipologia 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 presente all’interno del root element configurazione. Di seguito si riporta un esempio di configurazione xml che indica alla Porta
di Dominio di accedere ad un registro dei servizi di tipo XML disponibile al path /etc/openspcoop/registroServizi.xml:
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
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 registro dei servizi di tipo DB accessibile tramite un datasource (registrato nell’albero JNDI), con nome org.openspcoop.dataSource.regis
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
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
8 / 84
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
3.2.7
9 / 84
Deploy del Software
Per il deploy della versione J2EE è sufficiente copiare il file dist/OpenSPCoop.ear nella directory di deploy dell’application
server: 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 servlet
container: 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 messaggio
simile 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 OpenSPCoop, 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 della
Guida 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à che
interessano i più svariati aspetti di funzionamento della Porta di Dominio. Di seguito vengono riportato solo alcune proprietà di
carattere 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: /etc/openspcoop). Nella directory indicata nella proprietà dovranno essere inserite la configurazione della PdD e/o il registro
dei servizi, entrambi in formato xml. Per ulteriori dettagli sulle configurazioni xml si rimanda alle sezioni Sezione 3.2.5 e
Sezione 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 server
JMX)
– web, il server è un WebContainer (es. Tomcat). Con questo tipo di server, i profili di collaborazione saranno gestiti solo in
modalità 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:
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
10 / 84
– org.openspcoop.pdd.identificativoPorta.dominio, identificativo di dominio del soggetto di default (default: OpenSPCoopSPCoopIT).
– 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 OpenSPCoop
Sezione 3.2.5.
Il tipo di configurazione della porta di dominio viene indicato dalla voce org.openspcoop.pdd.config.tipo; attualmente OpenSPCoop dispone di due tipi di configurazioni:
1. xml: viene fornita attraverso un file XML (vedi Guida Utente XML: Configurazione PdD ). L’informazione su come
reperire la configurazione deve essere definita attraverso la voce org.openspcoop.pdd.config.location, specificando il path
nel fileSystem, in caso di un file XML locale (es. /etc/openspcoop/config.xml), o una url, nel caso di file XML remoto (es
http://repository/config.xml).
2. db: viene fornita attraverso un database SQL. L’informazione su come reperire il database deve essere definita attraverso
la voce org.openspcoop.pdd.config.location, specificando il nome di un dataSource registrato nell’albero JNDI dell’application server. Il dataSource viene utilizzato da OpenSPCoop per accedere alle tabelle descritte in Sezione 5.1.2.1 o
Sezione 5.2.2.1 (a seconda della PddConsole scelta). È possibile fornire informazioni di contesto per la ricerca del dataSource, attraverso una o più voci org.openspcoop.pdd.config.property.*, tramite la definizione di coppie nome/valore dove
il 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 riesieda
nel path /etc/openspcoop/config.xml
L’accesso alla configurazione, soprattutto in caso di configurazione su database, può risultare oneroso. Per limitare gli accessi alla
configurazione da parte della Porta di Dominio è possibile anteporre alla configurazione un meccanismo di cache configurabile
tramite 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 (porte
delegate, porte applicative, servizi applicativi), ed una riguardante aspetti puri di configurazione della porta di dominio (per
ulteriori dettagli vedi Guida Utente della Porta di Dominio OpenSPCoop o Guida Utente XML: Configurazione PdD ). Mentre
nella prima macro-area, è necessario avere un meccanismo di refresh delle informazioni mantenute in cache (in seguito alla
creazione/cancellazione frequente di elementi di integrazione), nella seconda area è accettabile anche associare alla porta di
dominio un comportamento per il quale legge le informazioni di configurazioni solo una volta all’avvio, e le mantiene fino
al 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 (valore
true). 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 di
OpenSPCoop, per default, abilita il refresh.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
3.3.1.2
11 / 84
Accesso al Registro dei Servizi
Tramite la proprietà org.openspcoop.registroServizi.readObjectStatoBozza (Default: false) è possibile configurare la porta di
dominio in modo da utilizzare o ignorare accordi di servizio, accordi di cooperazione, servizi spcoop e fruzioni in uno stato di
bozza.
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.dat
il 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 org.openspcoop.pdd.dataSource.property.*, tramite la definizione di coppie
nome/valore dove il nome viene preso al posto del carattere speciale *. (Default: dataSource=org.openspcoop.dataSource e
dataSource.property non definite).
La voce org.openspcoop.pdd.repository.tipoDatabase (Opzionale) permette di impostare il tipo di database utilizzato. Questa
voce 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 dei
messaggi 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 differenti di repository, impostabili tramite la proprietà org.openspcoop.pdd.repository (Default: tipo=fs, directory=/var/openspcoop/msgReposit
1. fs: il repository viene mantenuto su fileSystem all’interno di una directory indicata attraverso la proprietà org.openspcoop.pdd.repos
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().
Nota
le keyword utilizzate per la definizione di un JDBC adapter sono definite all’interno del file className.properties descritto nel seguito di questo paragrafo, e precisano la classe che implementa l’interfaccia
org.openspcoop.core.jdbc.IJDBCAdapter. È possibile fornire adapter personalizzati, semplicemente definendo una opportuna classe che implementa l’interfaccia JDBCAdapter e registrandola all’interno del file className.properties (vedi
Sezione 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 seguente 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 descritta in precedenza in questo paragrafo. Questo tipo di controllo è attivabile tramite la proprietà org.openspcoop.pdd.repository.scadenza
(true/false, default: true). Se il controllo è attivato anche le buste che possiedono un’elemento ’ora-registrazione’ scaduto, vengono scartate tramite un messaggio SPCoop Errore, con eccezione che segnala la busta scaduta, così come viene effettivamente
fatto se la busta porta nell’header la data di scadenza (elemento ’scadenza’) scaduta.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
12 / 84
Nota
L’abilitazione o meno di questo controllo influenza il meccanismo di pulizia del repository delle buste e-Gov. Se il controllo viene
disabilitato, le informazioni per effettuare il filtro duplicati vengono mantenute all’infinito, poichè una stessa busta (stesso id eGov) può essere gestita dalla Porta di Dominio in un qualsiasi momento, anche anni dopo! Come conseguenza sarà necessaria
una 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.messaggioInProcessam
permettono rispettivamente di configurare l’attesa attiva, in secondi, effettuata per il completamento dei messaggi precedentemente già ricevuti (es. buste con stesso id egov) e l’intervallo in millisecondi tra un check e l’altro durante l’attesa attiva. Questi
parametri 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 asincrona asimmetrica deve essere gestita dal servizio di RicezioneBusteEGov, solo se la precedente richiesta o ricevuta alla richiesta non risulti ancora in processamento nella porta di dominio. Se arriva una risposta/richiestaStato mentre la precedente richiesta/ricevutaRichiesta è ancora in gestione, il servizio effettua una attesa attiva configurabile attraverso i parametri
org.openspcoop.pdd.repository.messaggioAsincronoInProcessamento.attesaAttiva e org.openspcoop.pdd.repository.messaggioAsincrono
org.openspcoop.pdd.repository.gestoreMessaggi.cache.* permette di anteporre una cache per ottimizzare le performance della
porta di dominio per quanto riguarda la gestione dei messaggi, effettuata dai moduli dell’infrastruttura di OpenSPCoop, basata
su 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 che
riferiscono altre buste attraverso un riferimento messaggio.
• Algoritmo di Transaction Manager che permette il corretto passaggio della gestione dei messaggi tra i moduli funzionali
dell’architettura di OpenSPCoop.
Nota
Una cache per la gestione dei messaggi è utile solo se la PdD OpenSPCoop viene distribuita sotto forma di archivio J2EE
OpenSPCoop.ear e quindi utilizza le code fornite da un broker JMS. Se si è installato la versione per Servlet Container (Tomcat) 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 un
elemento può esistere senza essere acceduto.
• org.openspcoop.pdd.repository.gestoreMessaggi.cache.itemLifeSecond, permette di impostare la vita, in secondi, di un elemento inserito in cache.
(Default: config.cache.enable=false)
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
3.3.1.4
13 / 84
Accesso al broker JMS
Nota
Solo 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 jndi
utilizzato da OpenSPCoop per accedere ad un pool di connessioni jms registrato nell’albero JNDI dell’A.S. Il pool permetterà di
creare connessioni verso il broker JMS sul quale sono presenti le code descritte in Sezione 3.2.2. È possibile fornire informazioni
di 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.jmsPool
e queueConnectionFactory.property non definite). È possibile anche indicare il tipo di Acknowledge utilizzato con la sessione
JMS attraverso la proprietà org.openspcoop.pdd.queueConnectionFactory.session.AcknowledgeMode (Default: AUTO_ACKNOWLEDG
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 di
gestire le richieste di servizio effettuate dai servizi applicativi.
• org.openspcoop.pdd.queue.ricezioneBusteEGov, coda del modulo RicezioneBusteEGov che si occupa di gestire le buste eGov
inviate da altre Porte di Dominio.
• org.openspcoop.pdd.queue.inoltroBusteEGov, coda del modulo InoltroBuste eGov che si occupa di inoltrare buste eGov prodotte dalla PdD verso altre Porte di Dominio.
• org.openspcoop.pdd.queue.inoltroRisposteEGov, coda del modulo InoltroRisposte eGov che si occupa di gestire eventuali
buste eGov di risposta da inoltrare su nuove connessioni http.
• org.openspcoop.pdd.queue.consegnaContenutiApplicativi, coda del modulo ConsegnaContenutiApplicativi che si occupa di
invocare 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 per
buste in uscita.
• org.openspcoop.pdd.queue.imbustamentoRisposte, coda del modulo ImbustamentoRisposte che si occupa della creazione di un
header eGov per buste contenenti risposte applicative.
• org.openspcoop.pdd.queue.sbustamento, coda del modulo Sbustamento che si occupa dello sbustamento/gestione dell’header
eGov presente nelle buste ricevute.
• org.openspcoop.pdd.queue.sbustamentoRisposte, coda del modulo SbustamentoRisposte che si occupa dello sbustamento/gestione 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ù voci
org.openspcoop.pdd.queue.property.*, tramite la definizione di coppie nome/valore dove il nome viene preso al posto del carattere
speciale *. (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 in
ingresso.
• Connessioni in uscita
Le seguenti proprietà influenzano le connessioni istanziate in fase di consegna ai servizi applicativi e in fase di inoltro delle
buste e-Gov:
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
14 / 84
– org.openspcoop.pdd.connettori.TIPO_MODULO_FUNZIONALE.connection.timeout, timeout in millisecondi per la creazione della connessione.
– org.openspcoop.pdd.connettori.TIPO_MODULO_FUNZIONALE.readConnection.timeout, timeout in millisecondi per la
lettura della risposta dalla connessione.
– org.openspcoop.pdd.connettori.TIPO_MODULO_FUNZIONALE.httpTransferLength, tipo di transfer-length http utilizzato
per 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 sia
la entity-length sia il transfer-length
* transfer-encoding-chunked, viene impostato un header http Transfer-Encoding con il valore chunked. Con questo tipo di
transfer-length è possibile indicare la dimensione in bytes di ogni singolo chunk tramite la proprietà org.openspcoop.pdd.connettor
(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 al
servizio applicativo
• Connessioni in entrata
La seguente proprietà influenza le connessioni istanziate in fase di invocazione delle porte delegate da parte dei servizi applicativi 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 che
agiscono in modalità stateless (vedi Sezione 3.3.1.12). Se si abilita il rinegoziamento della connessione, non vi è un vincolo
tra connessioni HTTP e connessioni sul DB e il numero di connessioni HTTP può essere tranquillamente maggiore. Se invece
il thread che gestisce una richiesta non rinegozia la connessione, vi è un vincolo 1-1 tra connessioni HTTP e connessioni sul
DB 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 tipo di transfer-length http utilizzato per la spedizione dei messaggi soap di risposta sulla connessione http (vedi Hypertext
Transfer Protocol -- HTTP/1.1: Message Length ):
– content-length (default), viene impostato un header http Content-Length contenente un valore decimale rappresentante sia la
entity-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 viene
lasciata 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 utilizzare soap action quotate. Anche se il protocollo HTTP permette header con valori non quotati, alcune implementazioni SOAP
richiedono 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 SOAPAction con valore quotato.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
3.3.1.6
15 / 84
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 forma
di archivio J2EE OpenSPCoop.ear o tramite semplici thread se la PdD viene distribuita come archivio per ServletContainer
openspcoop.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/false, 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à interpretata 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 dalla
PdD 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 occupa
di gestire la pulizia del repository delle buste e-Gov.
Attraverso la voce org.openspcoop.pdd.timer.gestoreRepositoryEGov.enable è possibile attivare/disattivare (true/false, default: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à interpretata
dalla 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 del
carattere 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 dalla
porta di dominio. I controlli sulle risorse di sistema sono attivabili tramite le voci org.openspcoop.pdd.risorse.check.*. Le
risorse 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
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
16 / 84
– broker JMS, controllo attivabile tramite l’opzione org.openspcoop.pdd.risorse.check.jms, verifica che sia possibile istanziare
ed 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 configurazione
istanziata); inoltre tramite la proprietà org.openspcoop.pdd.risorse.check.configurazione.validazioneSemantica è possibile
associare 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 che
sia accessibile il registro dei servizi (controlli differenti a secondo del tipo di configurazione istanziata); esistono due
tipologie 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 controllo
anche 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, verifica
che 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.che
• Controlli personalizzati delle risorse utilizzate dalla Porta di Dominio
Infine è possibile fornire controlli personalizzabili sulla disponibilità di risorse per la gestione di ulteriori richieste applicative
e/o buste eGov, tramite le voci org.openspcoop.pdd.repository.threshold.*. Tramite la voce org.openspcoop.pdd.repository.threshold.tip
(Opzionale) è possibile elencare diversi tipi di controlli da effettuare. Ogni tipo indica il nome di una classe, registrata in className.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_THRESHOL
L’intervallo di tempo (in secondi) con cui i controlli vengono schedulati è impostabile tramite l’opzione org.openspcoop.pdd.repository.
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 superato
il valore di soglia indicato. Il valore che viene passato al controllo puo essere del tipo valore_soglia[;nome_datasource]. Se
nome datasource non è indicato verrà utilizzata la connessione verso il database openspcoop. Il valore di soglia è interpretato
in 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 attraverso
l’opzione org.openspcoop.pdd.core.jmx.enable (default: true). Gli MBean JMX utilizzabili permetteranno di gestire le seguenti
funzionalità:
• 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 RicezioneBusteEGov
• type=ConfigurazionePdD, gestione della configurazione della Porta di Dominio (livello di log, tracciamento, dump) e gestione
della 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 (database,jms) impegnate dalla porta
• type=RepositoryMessaggi, gestione della cache utilizzata per i dati dei messaggi in transito sulla Porta di Dominio
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
17 / 84
è possibile indicare Il nome JNDI del MBean Server da utilizzare per la registrazione dei MBean JMX attraverso l’opzione
org.openspcoop.pdd.core.jmx.jndi.mbeanServer. È possibile fornire informazioni di contesto per la ricerca JNDI, attraverso una
o più voci org.openspcoop.pdd.core.jmx.jndi.property.*, tramite la definizione di coppie nome/valore dove il nome viene preso
al 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 seguenti
opzioni:
• org.openspcoop.pdd.startup.config.xml.validazioneSemantica (default: abilitato), opzione utilizzata in caso di configurazione
basata su XML (vedi Sezione 3.2.5.1); se abilitata la validazione viene effettuata allo startup della PdD, e ogni qualvolta viene
modificato il file XML
• org.openspcoop.pdd.startup.config.validazioneSemantica (default: disabilitato), opzione utilizzata in caso di tipi di configurazione non basati su XML (vedi Sezione 3.2.5.2); indica se abilitare o meno la validazione semantica; se abilitata, la validazione 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 dei
servizi basato su XML Sezione 3.2.6; se abilitata, la validazione viene effettuata allo startup della PdD, e ogni qualvolta viene
modificato il file XML
• org.openspcoop.pdd.startup.registri.validazioneSemantica (default: disabilitato), opzione utilizzata nel caso di registri dei servizi non basati su XML Sezione 3.2.6; indica se abilitare o meno la validazione semantica; se abilitata, la validazione viene effettuata allo startup della PdD e ad intervalli regolari se è stato attivato il timer apposito (vedi proprietà org.openspcoop.pdd.risorse.chec
in Sezione 3.3.1.6)
• org.openspcoop.pdd.startup.registri.validazioneSemantica.checkURI (default: disabilitato), se abilitata viene effettuata la validazione delle URI presenti nelle risorse definite nel registro dei servizi
Nota
All’interno della distribuzione, in tools/validator, viene fornito un validatore semantico della configurazione e del registro dei
servizi utilizzabile tramite command line. Istruzioni su come utilizzare questo tool vengono fornite nella distribuzione in
doc/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 descritti
tutti gli aspetti personalizzabili per l’integrazione, dal protocollo SOAP (SOAPFault, Attachments) all’header di integrazione per
lo 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 dalla
porta 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 di
specifica 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 (Sistema
Pubblico di cooperazione: Porta di Dominio v1.0 a pg 41) se l’opzione org.openspcoop.pdd.erroreApplicativo.fault.details
non è abilitata, altrimenti contiene una descrizione dell’errore.
* FaultCode, contiene il codice dell’errore.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
18 / 84
* Details, contiene l’xml che forma il messaggio di errore applicativo come definito nella specifica CNIPA (Sistema Pubblico 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 porta
di 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. I
codici 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 processamento
interni. 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’Interazione con la Porta di Dominio ). Il prefisso dei codici di errore (es. OPENSPCOOP_ORG_500) è definito nella voce
org.openspcoop.pdd.erroreApplicativo.prefixFaultCode (default OPENSPCOOP_ORG_ ). OpenSPCoop produce per default codici di errore specifici a seconda del tipo di errore, all’interno della classe 4XX o 5XX (es. 502, 403 ... ). Questa opzione può essere disattivata (producendo errori generici 400 e 500) attraverso la voce org.openspcoop.pdd.erroreApplicativo.genericF
(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 gestione
dei profili asincroni. L’interscambio di informazioni viene attuato tramite header di integrazione di diverse tipologie con lo
scopo 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.pd
e org.openspcoop.pdd.integrazione.tipo.pa, rispettivamento lato porta delegata (il servizio applicativo fornisce informazioni alla 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 servizio
applicativo. Esistono anche altri tipi built-in come ’soap’ e ’wsa’ per informazioni inserite in un header SOAP proprietario di
OpenSPCoop o tramite lo standard WS-Addressing. Per ulteriori dettagli sugli header di integrazione è possibile consultare il
documento Manuale di Sviluppo: Interscambio di informazioni tra Servizi Applicativi e Porte di Dominio . L’ordine degli header ne definisce il livello di importanza in ordine crescente per l’integrazione tra servizio applicativo e pdd. Per l’integrazione
tra 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 seguenti
voci:
– 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:
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
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 anche
come namespace
La porta di dominio, lato porta delegata, una volta interpretato un header di integrazione, può essere configurata per eliminare
tale 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 i
valori 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 applicativa
o 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
(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 eliminato
poichè 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 di
IntegrationManager , è personalizzabile in alcuni aspetti di configurazione avanzata, tramite le seguenti proprietà:
– org.openspcoop.pdd.service.IntegrationManager.nomePortaDelegataUrlBased, modalità di definizione della porta delegata
indicata nel metodo ’invocaPortaDelegata’. Di default (value=false) il nome fornito viene utilizzato interamente per individuare la porta delegata da utilizzare. È possibile modificare il comportamento in modo che il nome fornito viene utilizzato
in 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’invocazione 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 applicativi 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 influenzano
tale 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’eliminazione
di tale istruzione di codifica, se presente. Se deleteInstructionTargetMachineXml=false e l’istruzione <?xml è presente
l’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 essere
impostato 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 attivato
anche per una risposta presente nell’http-reply (in profili sincroni) sempre tramite l’header http della risposta, impostando la
keyword indicata dalla proprietà. (Default: OpenSPCoopTunnelSOAP)
– org.openspcoop.pdd.core.soap.tunnelSOAP.mimeType, Se viene richiesto il servizio di imbustamento, il contenuto inviato
viene codificato in Base64 con mime-type application/openspcoop se non viene fornito un mime-type attraverso questa proprietà. Se invece viene fornito un mime-type verrà utilizzato il DataContentHandler associato al mime type, che deve essere
stato registrato in META-INF/mailcap all’interno dell’archivio OpenSPCoop (Default: OpenSPCoopTunnelSOAPMimeType)
• 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 aggiungere un actor di default nel caso in cui la configurazione WSS lo comprenda. L’impostazione di un actor di default per l’header
WSS introdotto dalla PdD è fondamentale per non avere conflitti durante la gestione, se anche i servizi applicativi fruitori ed
erogatori gestiscono a loro volta un header wssecurity a livello applicativo (e non utilizzano un actor). Attraverso l’opzione
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
20 / 84
org.openspcoop.pdd.wssecurity.actorDefault.valore è possibile definire l’eventuale actor di default introdotto dalla porta di
dominio (Default: enable=true e valore=openspcoop).
• HandlerBypassHeaderElement
Nota
Le proprietà descritte di seguito non sono più utilizzate a meno di usufruire dei servizi deprecati openspcoop/services/PD e
openspcoop/services/PA.
È possibile configurare alcuni aspetti di gestione degli header presenti nei messaggi SOAP ricevuti dalla porta di dominio. Nel
caso in cui un msg SOAP, ricevuto da un servizio di OpenSPCoop, possieda un header con l’attributo mustUnderstand=1 e non
sia presente l’actor, il servizio Axis provoca erroneamente un SoapFault, perché pensa che debba gestire l’header, e non possiede informazioni per farlo. Il filtro, inserito in testa ai servizi axis di OpenSPCoop (con un handler) permette di bypassare il problema 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 non
possiede un actor. Se si desidera invece abilitare un filtro più selettivo verso gli header da gestire, che possiedono mustUnderstand=1 e non possiedono un actor, è possibile operare con la proprietà org.openspcoop.pdd.services.BypassMustUnderstandHandler.h
fornendo 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 (namespace
uri: 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 (namespace 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. È possibile 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 alla
fruizione di un servizio. Se il soggetto mittente della busta e-Gov risulta registrato come fruitore del servizio nel registro dei
servizi, allora tale soggetto è autorizzato.
• pddConsole, vengono utilizzate le informazioni presenti nel database dell’applicazione pddConsole che possiede un registro
dei 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 eGov
in ingresso
Nota
Il tipo di autorizzazione effettuata dal servizio di ricezione buste eGov indica il nome di una classe, registrata in className.properties, che implementa l’interfaccia org.openspcoop.pdd.core.autorizzazione.IAutorizzazioneOpenSPCoop.java. Per
ulteriori 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 attraverso
le 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.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
21 / 84
• org.openspcoop.pdd.autorizzazioneSPCoop.cache.algoritmo, permette di impostare l’algoritmo utilizzato con la cache (LRU/MRU).
• org.openspcoop.pdd.autorizzazioneSPCoop.cache.itemIdleTime, indica il massimo intervallo di tempo, in secondi, che un
elemento può esistere senza essere acceduto.
• org.openspcoop.pdd.cautorizzazioneSPCoop.cache.itemLifeSecond, permette di impostare la vita, in secondi, di un elemento
inserito 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 negli
Identificativi EGov. Esistono le seguenti modalita: (default: static)
– db, viene utilizzato il contatore presente nella tabella ID_EGOV del database di OpenSPCoop. La colonna viene acceduta
con 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 di
installazione in cluster della porta di dominio. In tale contesto, poichè l’informazione è memorizzata staticamente due porte
di dominio installate su due application server distinti, possono produrre gli stessi contatori seriali e quindi potenzialmente gli
stessi 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 ciascuna
istanza 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 normalmente
da 7 cifre generate tutte in maniera sequenziale e univoca, verrà composto invece dal numero progressivo impostato nella
proprietà 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 il
sistema di marcatura delle buste e-Gov rispetto all’attuale utilizzo della porta di dominio. La tabella RepositoryEGov del
database 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 presenza
di 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 di
database)
– bytewise: gestione dei tre booleani compattati in un unico campo INTEGER e trattati con una maschera di bit attraverso
operatori 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 con
una maschera di bit attraverso operatori ’BIT_OR’ e ’BIT_AND’ della libreria ’utl_raw’
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
22 / 84
Ottimizzazione di operazioni su bit
Un tipo di gestione diversa da quella di default richiede una creazione della tabella con opportuni campi di gestione per i
booleani. (Esempio di inizializzazione, diversa da quella di default, per i tipi di gestione esistenti sono forniti, commentati, nel
file 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 Dominio
rispetto 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) o
un 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 porta delegata, con org.openspcoop.egov.oneway.http202=true e header di integrazione impostato a ’soap’ (o con un’altra integrazione 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. Questa
opzione indica se ritornare al servizio applicativo tali messaggi, o se in caso in cui il soap body è vuoto, il messaggio non
deve 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 associabili ad un servizio SPCoop
– org.openspcoop.egov.filtroDuplicati.letturaRegistro (Default: true), se abilitata, la porta di dominio non si fida della busta
eGov 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 della
busta eGov ricevuta, ma controlla il registro dei servizi per verificare se deve generare un riscontro. Se la gestione dei
riscontri 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 della
busta eGov ricevuta, ma controlla il registro dei servizi per verificare se deve gestire la consegna in ordine. Se la consegna
in 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 con
struttura non corretta è possibile indicare se interpretare comunque l’header e generare una possibile risposta o ritornare solo
un 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’attributo
role 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 di
dominio 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
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
–
–
–
–
–
–
–
–
23 / 84
* ora, ora in cui viene emessa la busta eGov
La PdD OpenSPCoop valida per default ogni singola parte di un identificativo eGov. È possibile istruire la PdD in modo che
non validi le prime due parti (nome e identificativo porta del mittente) tramite l’opzione org.openspcoop.egov.validazione.idegov.vali
(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 richiesta
asincrona asimmetrica
org.openspcoop.egov.collaborazione.enable (Default: true), indica se la porta deve generare/gestire l’elemento Collaborazione della busta
org.openspcoop.egov.consegnaInOrdine.enable (Default: true), indica se la porta deve gestire la consegna in ordine (ConsegnaAffidabile+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 messaggio SPCoopErrore se viene ricevuto un messaggio duplicato in presenza di un profilo di collaborazione OneWay o profili
Asincroni (in modalità asincrona)
org.openspcoop.egov.spcoopErrore.ignoraNonGravi.enable (Default: false), la Porta di Dominio considera le busta che contengono una lista eccezioni con eccezioni di qualsiasi tipo, un errore SPCoop (con associato SOAPFault). Attraverso l’opzione è possibile indicare alla porta che liste eccezioni, con eccezioni non gravi, possono essere processate come un messaggio
SPCoop 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 livello
infoSpcoop.
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 SPCoop
malformata solo se la validazione rileva eccezioni di livello GRAVE, deve essere abilitata la seguente opzione
Certificazione CNIPA e linee guida 1.1
Le opzioni indicate permettono la gestione di tutte le funzionalità e-Gov descritte nel documento Sistema Pubblico di Cooperazione: Busta EGov 1.1 . Tali opzioni vengono interpretate dalla Porta di Dominio solo se il servizio fruito/erogato viene
gestito tramite profilo eGov1.1; se invece è stato scelto il profilo eGov1.1-lineeGuida1.1 (per ulteriori dettagli vedi Guida
Utente della Porta di Dominio OpenSPCoop: Profili e Compatibilità ) viene automaticamente impostato una gestione della
busta come descritto nel documento Sistema Pubblico di Cooperazione: Linee Guida all’uso della Busta EGov 1.1 . In questo
contesto 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 collaborazione
asincroni, 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
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
3.3.1.12
24 / 84
Gestione stateless/stateful dei messaggi
Dalla versione 1.2 sono state realizzate numerose ottimizzazioni nella gestione dei profili di collaborazione, finalizzate principalmente a limitare l’eccessivo uso del database operato dalla versione 1.0. La principale ottimizzazione è stata introdotta
tramite l’uso del parametro stateless sulle porte delegate e applicative, o agendo sulla configurazione globale della PdD tramite
le proprietà descritte in questo paragrafo.
• org.openspcoop.pdd.stateless.default.*, le porta di dominio può gestire i profili di collaborazione Oneway, Sincrono e Asincrono in modalita stateless. In questa modalità la gestione avviene senza il salvataggio delle informazioni sul database e
l’attivazione di diversi MDB funzionali, ma tramite un unico thread. È possibile impostare il comportamento stateless nel
contesto 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à di
integrazione, Modalità di gestione Stateless/Stateful );
Le opzioni org.openspcoop.pdd.stateless.default.oneway, org.openspcoop.pdd.stateless.default.sincrono e org.openspcoop.pdd.statele
permettono 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 transito
in modalità stateless. In questa modalità la gestione avviene senza il salvataggio delle informazioni sul database e l’attivazione
di 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 trasmissione
sincrona, 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 sblocca
subito il client. La modalità di trasmissione sincrona viene utilizzata se la porta delegata/applicativa viene configurata come
stateless, altrimenti viene utilizzata la modalità asincrona. È possibile avere anche un approccio ibrido dove la gestione avviene
in modalità stateless ma la modalità di trasmissione è asincrona. Questo comportamento viene configurato dalla seguente
proprietà:
– org.openspcoop.pdd.stateful.oneway=1.0, gestione asincrona effettuata come nella versione 1.0 di OpenSPCoop attraverso
l’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 regolari
fino 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 imposta
un ritardo crescente sulla base del numero di riconsegne. La proprietà org.openspcoop.pdd.connettore.ritardo.stato, permette di
abilitare 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.* permette
di 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 ritardo
incrementato esponenzialmente o linearmente del numero di tentativi già effettuati. Descriviamo adesso i parametri per impostare
i valori della formula:
• CadenzaRispedizione, la cadenza di rispedizione viene impostata nella porta di dominio (vedi voce ’gestione-errore’ del documento 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 )
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
25 / 84
• FattoreRitardo, impostabile tramite la proprietà org.openspcoop.pdd.connettore.ritardo.fattore, indica l’intervallo di ritardo
per le ri-consegne di messaggi in secondi (default: 2).
• FattoreCrescita, impostabile tramite la proprietà org.openspcoop.pdd.connettore.ritardo.operazione, indica l’algoritmo di crescita, esponenziale(*) o lineare(+) (default: *)
• Limite di Crescita, impostabile tramite la proprietà org.openspcoop.pdd.connettore.ritardo.limite, indica il limite del numero
di 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 proprietà org.openspcoop.pdd.connettore.ritardo=2 e org.openspcoop.pdd.connettore.operazione=* la data del prossimo tentativo di
spedizione 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.te
default: spc)
• spc, indica che la porta di dominio possiede una sorgente temporale sincronizzata attraverso un server centrale certificato
dall’infrastruttura SPC
• locale, indica che la porta di dominio utilizza una sorgente temporale (locale o anche remota) non sincronizzata attraverso un
server 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 attraverso la voce org.openspcoop.pdd.date.property.ntp.server. Inoltre è possibile configurare un timeout (org.openspcoop.pdd.date.property.n
e abilitare una cache che limita il numero di letture al secondo verso il server (voci org.openspcoop.pdd.date.property.ntp.cache.enable
e 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 attraverso la voce org.openspcoop.pdd.date.property.time.server (per il server TCP è possibile indicare anche la porta attraverso la voce
org.openspcoop.pdd.date.property.time.porta). Inoltre è possibile configurare un timeout (org.openspcoop.pdd.date.property.time.time
e abilitare una cache che limita il numero di letture al secondo verso il server (voci org.openspcoop.pdd.date.property.time.cache.enable
e 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 per
svariati motivi. Nell’arco di tempo in cui non vi è la sincronizzazione temporale, la data del sistema potrebbe disallinearsi e
quindi la Porta di Dominio potrebbe produrre o ricevere buste e-Gov che portino una data disallineata rispetto alle altre Porte di
Dominio. In questo contesto è utile avere un intervallo temporale di tolleranza per accettare buste che portano date future rispetto
alla data del sistema dove è installata la Porta di Dominio. Per abilitare l’intervallo temporale di tolleranza, si può impostare
un valore maggiore di 0 nella proprietà org.openspcoop.pdd.date.intervalloTolleranza, in modo da far accettare alla Porta di
Dominio 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.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
3.3.1.15
26 / 84
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 la
modalità di dump. Se tale proprietà viene attivata vengono registrati tutti gli attachments (in caso di dump attivo), altrimenti solo
gli 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 messaggi
tramite code JMS. In questa architettura, era possibile effettuare il tuning di diversi aspetti, in modo da adattare la configurazione
al sistema su cui veniva installata la Porta di Dominio. Questi parametri di configurazione, nell’attuale versione, sono ancora utili
solo in presenza di un utilizzo della Porta di Dominio in un ambiente J2EE (OpenSPCoop.ear) con gestione stateful dei profili di
collaborazione.
• org.openspcoop.pdd.nodeReceiver.*, contiene una configurazione avanzata dei moduli ’RicezioneContenutiApplicativì e ’RicezioneBusteEGov’ 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 in
className.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.reposit
vedi Sezione 3.3.1.3), per migliorare le performance, se le informazioni su di un messaggio non sono presenti nella cache
si assumono anche non presenti nel database. La cache può comunque svuotarsi velocemente se la dimensione è troppo
piccola 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 ricezione 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 RicezioneContenutiApplicativi.
– 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 in
className.properties, che implementano l’interfaccia org.openspcoop.pdd.core.node.INodeSender. Il tipo jms (Default) attiva
i moduli attraverso spedizione di messaggi in code JMS; i moduli sono implementati tramite MDB in ascolto sulle code. Il tipo
db registra i messaggi su database; ogni modulo ha un thread che si occupa di fare ricerca attiva sul database per localizzare
eventuali messaggi da gestire. Verrà modificata automaticamente dal task ant build o build_threads a seconda del tipo di
OpenSPCoop costruito.
• org.openspcoop.pdd.core.TransactionManager, contiene una configurazione avanzata del Transaction Manager di OpenSPCoop. Possono essere personalizzati gli aspetti quali:
– org.openspcoop.pdd.core.TransactionManager.timeout, timeout di attesa attiva, per la validazione di un messaggio ricevuto
da 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
per migliorare le performance, se le informazioni su di un messaggio non sono presenti nella cache si assumono anche non
presenti nel database. La cache può cmq svuotarsi velocemente se la dimensione è troppo piccola rispetto al numero di msg
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.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
27 / 84
– org.openspcoop.pdd.core.TransactionManager.singleConnection, indicazione sul rilascio delle connessioni (true/false) durante la validazione della transazione del messaggio.
• org.openspcoop.pdd.jdbc.serializable, contiene una configurazione avanzata della gestione del livello serializable per le connessioni 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 operazione
sul 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’intervallo 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 dispone
di appender proprietari per quanto riguarda la memorizzazione di tracce e messaggi diagnostici. Nelle sotto-sezioni di questo
paragrafo 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 diverse
Category (log4j.category.*, ad esempio log4j.category.openspcoop.tracciamento per le tracce) che rappresentano un Logger utilizzato dalla Porta di Dominio per emettere log di un certo tipo (es. per emettere tracce). Ad ogni Category sono associabili uno
o più Appender (log4j.appender.*, ad esempio log4j.appender.openspcoop.tracciamento.rollingFile per le tracce) che rappresentano 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 utilizzate
dalla Porta di Dominio OpenSPCoop. I Log4J Appender non sono però associati per default alle rispettive Category a meno del
tipo RollingFileAppender, il quale si occupa di emettere i log associati alla category su filesystem, ruotando i log ogni volta che
il singolo file di log supera la dimensione stabilita. Ad esempio per la category sul tracciamento si ha l’associazione tramite la
seguente 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 filesystem 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 category su filesystem nel file indicato tramite la voce log4j.appender.openspcoop.<CategoryName>.rollingFile.File. Quando la
dimensione del file di log raggiunge la dimensione indicata dalla proprietà log4j.appender.openspcoop.<CategoryName>.rollingFile.M
il file di log viene ruotato.
• DailyRollingFileAppender, (log4j.appender.openspcoop.tracciamento.dateRollingFile), si occupa di emettere i log associati alla 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 meccanismo 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 su
un 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.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
28 / 84
• SysLogAppender (log4j.appender.openspcoop.<CategoryName>.syslog), si occupa di emettere i log associati alla category su
un syslog server. I dati di accesso al syslog server, come la url di connessione e la facility da utilizzare, devono essere fornite
nella 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 pubblico
di 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 openspcoop.msgDiagnostico, la quale, nella configurazione di default, si occupa di registrare il log all’interno del file /var/openspcoop/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 singole
informazioni di un messaggio diagnostico su un DBMS. Il database utilizzato include tutte le tabelle necessarie alla raccolta 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 estrarre
dall’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 parametri
di connessione (rispettivamente connection-url, driver jdbc, username e password) per accedere al database contenente la
tabella msgdiagnostici.
– FileRejected, indica un path sul filesystem dove verranno salvati i messaggi diagnostici, in caso di fallimento del salvataggio
su database (Default: /var/openspcoop/log/msgDiagnosticoRejected.log).
Il livello di filtraggio dei log, non deve essere impostato nella Category Log4J openspcoop.msgDiagnostico (nella quale deve
essere permesso qualsiasi tipo di log: ALL), ma nella configurazione di OpenSPCoop tramite la voce Livello SPCoop della
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.
• OpenSPCoop Appender.
La porta di dominio consegna i singoli xml, formanti un messaggio diagnostico, agli OpenSPCoopAppender attivati nella
sezione 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 delle
informazioni. Come creare un appender personalizzabile è illustrato nella Sezione 3.3.3.8. OpenSPCoop possiede un OpenSPCoopAppender 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 Log4J
Appender 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 diagnostico definito dal CNIPA, e quindi le uniche informazioni presenti possono essere solo quelle definite dal documento di
specifica. Mentre l’OpenSPCoopAppender è una implementazione di un’interfaccia java dove sono stati definiti i parametri passati, che sono quelli presenti nel messaggio diagnostico CNIPA, con l’aggiunta di informazioni extra riguardanti la
cooperazione applicativa per cui vengono emessi i diagnostici. Le informazioni aggiuntive sono contenute in parte nella
stessa tabella msgdiagnostici dove sono memorizzate anche le informazioni obbligatorie di un messaggio diagnostico. Tali
informazioni aggiuntive riguardano:
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
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’identificativo 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 la
cooperazione
* 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) fruitore o erogatore (a seconda del valore della colonna delegata)
L’OpenSPCoopAppender built-in di OpenSPCoop è definito dalla classe org.openspcoop.pdd.logger.MsgDiagnosticoOpenSPCoopApp
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 della
proprietà 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 SPCoop
della 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 cooperazione: 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, la
quale, 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) con
l’estensione di un Appender built-in di OpenSPCoop. Questo appender personalizzato si occupa di salvare le singole informazioni di una traccia su un DBMS. Il database utilizzato include tutte le tabelle necessarie alla raccolta dei messaggi diagnostici e
delle tracce. Tale database viene definito dal file presente nella distribuzione in deploy/pdd/SQL_table/TIPO_DATABASE/Tracciamento
In particolare il Log4J Appender built-in di OpenSPCoop si occupa di estrarre dall’xml di una traccia le informazioni presenti
e 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 parametri
di connessioni (rispettivamente connection-url, driver jdbc, username e password) per accedere al database contenente la
tabella 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).
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
30 / 84
L’abilitazione a registrare o meno le tracce non riguarda il livello di filtraggio dei log. Tale abilitazione non deve quindi essere
impostato nella Category Log4J openspcoop.tracciamento (nella quale deve essere permesso qualsiasi tipo di log: ALL), ma
nella configurazione di OpenSPCoop tramite la voce Tracciamento Buste e-Gov della sezione di configurazione del tracciamento. Si rimanda alla Guida Utente XML: Configurazione Porta di Dominio, Tracciamento delle Buste e-Gov 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 una traccia, agli OpenSPCoopAppender attivati nella sezione Tracciamento Buste e-Gov della configurazione della Porta di Dominio, per ulteriori dettagli vedi Guida Utente XML: Configurazione
Porta di Dominio, Tracciamento delle Buste e-Gov .
Gli OpenSPCoop Appender sono personalizzabili a seconda dello storage che si desidera utilizzare per il salvataggio delle informazioni. Come creare un appender personalizzabile è illustrato nella Sezione 3.3.3.9. OpenSPCoop possiede un OpenSPCoopAppender built-in per il salvataggio delle tracce su database (registrato con tipo dbTracciamentoAppender); lo stesso database
utilizzato dal Log4J Appender org.openspcoop.pdd.logger.TracciamentoLog4JAppender (deploy/pdd/SQL_table/TIPO_DATABASE/Tr
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 Log4J
Appender 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 definita
dal CNIPA, e quindi le uniche informazioni presenti possono essere solo quelle definite dal documento di specifica. Mentre
l’OpenSPCoopAppender è una implementazione di un’interfaccia java dove sono stati definiti i parametri passati, che sono
quelli presenti nella traccia CNIPA, con l’aggiunta di informazioni extra riguardanti la cooperazione applicativa per cui
vengono emesse le tracce. Le informazioni aggiuntive sono contenute nella stessa tabella tracce dove sono memorizzate
anche 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 caso
di cooperazione applicativa tramite porta delegata
L’OpenSPCoopAppender built-in di OpenSPCoop è definito dalla classe org.openspcoop.pdd.logger.TracciamentoOpenSPCoopAppen
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 della
proprietà 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 Tracciamento
Buste e-Gov della sezione di configurazione del tracciamento. Si rimanda alla Guida Utente XML: Configurazione Porta di
Dominio, Tracciamento delle Buste e-Gov e Guida Utente della Porta di Dominio: Configurazione dei parametri SPCoop per
ulteriori 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 documenti
di specifica del CNIPA. Tali tipologie di log vengono descritte di seguito e si riferiscono una ad una a Category Log4J impostate
nel 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 in
un formato human readable. Ogni messaggio diagnostico viene tradotto dalla struttura XML definita in Sistema pubblico
di cooperazione: Porta di Dominio, versione 1.0 , in un formato contenente una prima riga formata da una intestazione
che permette di identificare la cooperazione applicativa in corso (id e-Gov, mittente, destinatario, servizio, azione ...) e una
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
31 / 84
seconda riga contenente il testo del messaggio diagnostico. La traduzione viene consegnata alla Category Log4J con nome 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 deve
essere permesso qualsiasi tipo di log: ALL), ma nella configurazione di OpenSPCoop tramite la voce Livello OpenSPCoop
della 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 differenza
dei messaggi emessi da tutti gli altri moduli/servizi di OpenSPCoop, non vengono consegnati alla Category Log4J descritta
in precedenza, ma vengono consegnati alla Category Log4J con nome openspcoop.integrationManager, la quale si occupa di
registrare 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 quale
deve essere permesso qualsiasi tipo di log: ALL), ma nella configurazione di OpenSPCoop tramite la voce Livello OpenSPCoop
della 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 aggiuntive che non rientrano nello scopo dei messaggi diagnostici. Tali informazioni vengono consegnate alla Category Log4J con
nome 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 livello
desiderato.
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 header
della protocollo e-Gov. Una volta aggiunto o eliminato l’header e-Gov, il messaggio viene inoltrato al servizio applicativo interno
o 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 il
salvataggio del contenuto applicativo. In questi contesti è utilizzabile la funzionalità di dump dei contenuti applicativi attivabile
tramite 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 SPCoop
per ulteriori dettagli.
I contenuti dei messaggi in transito sulla Porta di Dominio, se è attiva la funzionalità di dump, vengono consegnati alla Category
Log4J 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 permesso qualsiasi tipo di log: ALL), ma nella configurazione di OpenSPCoop tramite la voce Dump della sezione di configurazione
delle 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. I
vari componenti sono definiti da interfacce java e vengono forniti, con la Porta di Dominio OpenSPCoop, tramite implementazioni built-in disponibili registrate nel file className.properties. La registrazione permette di associare ad ogni componente
un tipo utilizzabile all’interno della configurazione della Porta di Dominio. I seguenti paragrafi descriveranno come realizzare
componenti personalizzati.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
3.3.3.1
32 / 84
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 di
dominio. Per ulteriori dettagli vedi Guida Utente XML: Connettore
Un connettore può essere definito semplicemente implementando l’interfaccia definita nella distribuzione in /src/org/openspcoop/pdd/core/connettori/IConnettore.java. La classe personalizzata, una volta creata, deve essere registrata nel file deploy/pdd/properties/className.properties inserendo una proprietà, dopo la lista dei connettori built-in forniti con la Porta di Dominio
OpenSPCoop:
# ------------- Connettori ---------# connettore http
org.openspcoop.connettore.http=org.openspcoop.pdd.core.connettori.ConnettoreHTTP
# connettore https
org.openspcoop.connettore.https=org.openspcoop.pdd.core.connettori.ConnettoreHTTPS
# connettore jms
org.openspcoop.connettore.jms=org.openspcoop.pdd.core.connettori.ConnettoreJMS
# connettore saaj
org.openspcoop.connettore.saaj=org.openspcoop.pdd.core.connettori.ConnettoreSAAJ
# connettore null
org.openspcoop.connettore.null=org.openspcoop.pdd.core.connettori.ConnettoreNULL
# connettore nullEcho
org.openspcoop.connettore.nullEcho=org.openspcoop.pdd.core.connettori.ConnettoreNULLEcho
# connettore personalizzato
org.openspcoop.connettore.tipo_connettore_personalizzato=package.personalizzato. ←ImplementazioneConnettorePersonalizzato
La classe package.personalizzato.ImplementazioneConnettorePersonalizzato può quindi essere referenziata come tipo di connettore, 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à del
servizio applicativo fruitore che sta invocando la porta delegata. Per ulteriori dettagli vedi Guida Utente XML: Funzionalità di
Integrazione, autenticazione dei servizi applicativi
Un meccanismo di autenticazione dei servizi applicativi può essere definito semplicemente implementando l’interfaccia definita nella distribuzione in /src/org/openspcoop/pdd/core/autenticazione/IAutenticazione.java. La classe personalizzata, una volta creata, deve essere registrata nel file deploy/pdd/properties/className.properties inserendo una proprietà, dopo la lista dei
meccanismi di autenticazione built-in forniti con la Porta di Dominio OpenSPCoop:
# ------------- Autenticazione ---------# autenticazione basic
org.openspcoop.autenticazione.basic=org.openspcoop.pdd.core.autenticazione. ←AutenticazioneBASIC
# autenticazione ssl
org.openspcoop.autenticazione.ssl=org.openspcoop.pdd.core.autenticazione.AutenticazioneSSL
# autenticazione personalizzata
org.openspcoop.autenticazione.tipo_autenticazione_sa_personalizzata=package.personalizzato. ←ImplementazioneAutenticazioneSAPersonalizzata
La classe package.personalizzato.ImplementazioneAutenticazioneSAPersonalizzata può quindi essere referenziata come tipo di
autenticazione dei servizi applicativi, all’interno della configurazione della porta di dominio, semplicemente usando la keyword
tipo_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 autorizzati
di invocare una porta delegata. Per ulteriori dettagli vedi Guida Utente XML: Funzionalità di Integrazione, autorizzazione dei
servizi applicativi
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
33 / 84
Un meccanismo di autorizzazione dei servizi applicativi può essere definito semplicemente implementando l’interfaccia definita nella distribuzione in /src/org/openspcoop/pdd/core/autorizzazione/IAutorizzazione.java. La classe personalizzata, una volta creata, deve essere registrata nel file deploy/pdd/properties/className.properties inserendo una proprietà, dopo la lista dei
meccanismi di autorizzazione built-in forniti con la Porta di Dominio OpenSPCoop:
# ------------- Autorizzazione ---------# autorizzazione OpenSPCoop
org.openspcoop.autorizzazione.openspcoop=org.openspcoop.pdd.core.autorizzazione. ←AutorizzazioneOpenSPCoop
# autorizzazione personalizzata
org.openspcoop.autorizzazione.tipo_autorizzazione_sa_personalizzata=package.personalizzato. ←ImplementazioneAutorizzazioneSAPersonalizzata
La classe package.personalizzato.ImplementazioneAutorizzazioneSAPersonalizzata può quindi essere referenziata come tipo di
autorizzazione dei servizi applicativi, all’interno della configurazione della porta di dominio (Porta Delegata), semplicemente
usando 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 applicativo
utilizzato dai servizi applicativi al momento dell’invocazione di una porta delegata. Per ulteriori dettagli su come associare
il tipo di autorizzazione-contenuti alla Porta Delegata vedi Guida Utente XML: Configurazione XML della Porta di Dominio
OpenSPCoop, Porta Delegata
Un meccanismo di autorizzazione dei contenuti inviato dai servizi applicativi può essere definito semplicemente implementando l’interfaccia definita nella distribuzione in /src/org/openspcoop/pdd/core/autorizzazione/IAutorizzazioneContenuto.java. La
classe personalizzata, una volta creata, deve essere registrata nel file deploy/pdd/properties/className.properties inserendo una
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 per contenuto dei Servizi Applicativi ----------# autorizzazione esempio OK
org.openspcoop.autorizzazioneContenuto.esempioOK=org.openspcoop.pdd.core.autorizzazione. ←AutorizzazioneContenutoOK
# autorizzazione esempio KO
org.openspcoop.autorizzazioneContenuto.esempioKO=org.openspcoop.pdd.core.autorizzazione. ←AutorizzazioneContenutoKO
# autorizzazione personalizzata
org.openspcoop.autorizzazioneContenuto.tipo_autorizzazione_contenuto_personalizzata=package ←.personalizzato.ImplementazioneAutorizzazioneContenutoPersonalizzata
La classe package.personalizzato.ImplementazioneAutorizzazioneContenutoPersonalizzata può quindi essere referenziata come
tipo 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 invocare un servizio spcoop erogato sulla porta. Per ulteriori dettagli vedi Guida Utente XML: Funzionalità Avanzate, Autorizzazione
delle buste eGov in ingresso
Un meccanismo di autorizzazione delle buste e-Gov può essere definito semplicemente implementando l’interfaccia definita
nella distribuzione in /src/org/openspcoop/pdd/core/autorizzazione/IAutorizzazioneSPCoop.java. La classe personalizzata, una
volta creata deve essere registrata nel file deploy/pdd/properties/className.properties inserendo una proprietà, dopo la lista dei
meccanismi di autorizzazione built-in forniti con la Porta di Dominio OpenSPCoop:
# ------------ Autorizzazione SPCoop ----------# autorizzazione spcoop
org.openspcoop.autorizzazioneSPCoop.spcoop=org.openspcoop.pdd.core.autorizzazione. ←AutorizzazioneSPCoopRegistro
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
34 / 84
# autorizzazione pddConsole
org.openspcoop.autorizzazioneSPCoop.pddConsole=org.openspcoop.pdd.core.autorizzazione. ←AutorizzazionePdDConsole
# autorizzazione personalizzata
org.openspcoop.autorizzazioneSPCoop.tipo_autorizzazione_personalizzata=package. ←personalizzato.ImplementazioneAutorizzazionePersonalizzata
La classe package.personalizzato.ImplementazioneAutorizzazionePersonalizzata può quindi essere referenziata come tipo di autorizzazione delle buste e-Gov, all’interno della configurazione della porta di dominio (vedi Sezione 3.3.1.10), semplicemente
usando 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 applicativo
presente nelle buste e-Gov in ingresso sulla porta applicativa. Per ulteriori dettagli su come associare il tipo di autorizzazionecontenuti alla Porta Applicativa vedi Guida Utente XML: Configurazione XML della Porta di Dominio OpenSPCoop, Porta
Applicativa
Un meccanismo di autorizzazione del contenuto presente nelle buste eGov può essere definito semplicemente implementando
l’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 inserendo
una 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 OK
org.openspcoop.autorizzazioneContenutoSPCoop.esempioOK=org.openspcoop.pdd.core. ←autorizzazione.AutorizzazioneContenutoSPCoopOK
# autorizzazione esempio KO
org.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 referenziata
come tipo di autorizzazione-contenuto portato nelle buste e-Gov, all’interno della configurazione della porta di dominio (Porta
Applicativa), 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 dei
profili asincroni. L’interscambio di informazioni viene attuato tramite header di integrazione di diverse tipologie con lo scopo di
permettere lo scambio nella maniera più consona all’implementazione del servizio applicativo. Per ulteriori dettagli vedi Guida
Utente 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 porta
delegata, per fornire informazioni di integrazioni alla porta di dominio. Tali header possono essere definiti implementando
l’interfaccia in /src/org/openspcoop/pdd/integrazione/IGestoreIntegrazionePDSoap.java.
• PdD -> ServiziApplicativi (PortaApplicativa), header utilizzati dalla porta di dominio, al momento dell’invocazione del servizio 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 inserendo
una proprietà, dopo la lista degli header di integrazione built-in forniti con la Porta di Dominio OpenSPCoop:
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
35 / 84
# ------------- Integrazione tra Servizi Applicativi e PdD ---------org.openspcoop.integrazione.pd.trasporto=org.openspcoop.pdd.core.integrazione. ←GestoreIntegrazionePDTrasporto
org.openspcoop.integrazione.pd.urlBased=org.openspcoop.pdd.core.integrazione. ←GestoreIntegrazionePDUrlBased
org.openspcoop.integrazione.pd.soap=org.openspcoop.pdd.core.integrazione. ←GestoreIntegrazionePDSoap
org.openspcoop.integrazione.pd.wsa=org.openspcoop.pdd.core.integrazione. ←GestoreIntegrazionePDWSAddressing
# integrazione personalizzata
org.openspcoop.integrazione.pd.tipo_integrazione_pd_personalizzata=package.personalizzato. ←ImplementazioneIntegrazionePersonalizzataPD
# ------------ Integrazione tra PdD e Servizi Applicativi
org.openspcoop.integrazione.pa.trasporto=org.openspcoop.pdd.core.integrazione. ←GestoreIntegrazionePATrasporto
org.openspcoop.integrazione.pa.urlBased=org.openspcoop.pdd.core.integrazione. ←GestoreIntegrazionePAUrlBased
org.openspcoop.integrazione.pa.soap=org.openspcoop.pdd.core.integrazione. ←GestoreIntegrazionePASoap
org.openspcoop.integrazione.pa.wsa=org.openspcoop.pdd.core.integrazione. ←GestoreIntegrazionePAWSAddressing
# integrazione personalizzata
org.openspcoop.integrazione.pa.tipo_integrazione_pa_personalizzata=package.personalizzato. ←ImplementazioneIntegrazionePersonalizzataPA
Le classi package.personalizzato.ImplementazioneIntegrazionePersonalizzataPD e ImplementazioneIntegrazionePersonalizzataPA possono quindi essere referenziatate come tipo di header di integrazione all’interno della configurazione della porta di dominio, 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 di
dominio, 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 implementando 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 inserendo
una 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 personalizzato
org.openspcoop.msgdiagnosticoAppender.tipo_appender_personalizzato_msg_diagnostici=package. ←personalizzato.ImplementazioneMsgDiagnosticoAppenderPersonalizzato
La classe package.personalizzato.ImplementazioneMsgDiagnosticoAppenderPersonalizzato può quindi essere referenziata come
tipo di openspcoop appender per i messaggi diagnostici all’interno della configurazione della porta di dominio (vedi Sezione 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, con
l’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’interfaccia definita nella distribuzione in /src/org/openspcoop/pdd/logger/ITracciamentoOpenSPCoopAppender.java. La classe personalizzata, 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:
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
36 / 84
# ----------- Tracciamento Appender Personalizzati ---------org.openspcoop.tracciamentoAppender.dbTracciamentoAppender=org.openspcoop.pdd.logger. ←TracciamentoOpenSPCoopAppenderDB
# openspcoop appender personalizzato
org.openspcoop.tracciamentoAppender.tipo_appender_personalizzato_tracce=package. ←personalizzato.ImplementazioneTracciamentoAppenderPersonalizzato
La classe package.personalizzato.ImplementazioneTracciamentoAppenderPersonalizzato può quindi essere referenziata come
tipo di openspcoop appender per le tracce all’interno della configurazione della porta di dominio (vedi Sezione 3.3.2.2), semplicemente 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 invocata
ParametriPortaDelegata parPD = new ParametriPortaDelegata();
parPD.setLocation(nomePortaDelegata);
parPD.setUrlInvocazionePD(urlDiInvocazione); // utile per identificazioni url-Based
parPD.setParameters(parametriNomeValore); // utile per identificazioni url-Based stile form
parPD.setParametersTrasporto(parametriNomeValoreTrasporto); // utile per profili asincroni
// Credenziali utilizzate nella richiesta
Credenziali credenziali = new Credenziali();
// es. Basic
credenziali.setUsername(username);
credenziali.setPassword(password);
// Contesto di Richiesta
RicezioneContenutiApplicativiContext context = new RicezioneContenutiApplicativiContext();
context.setCredenziali(credenziali);
context.setIdModulo(ID_MODULO); // ID_MODULO, deve iniziare col prefisso ←RicezioneContenutiApplicativi
context.setGestioneRisposta(true); // true se deve essere ritornato un SoapMessage di ←risposta, false altrimenti
context.setInvocazionePDPerRiferimento(false); // true se deve essere effettuata una ←invocazione per riferimento, false altrimenti
context.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
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
3.3.3.11
37 / 84
Threshold personalizzati per il controllo delle risorse
È possibile fornire controlli personalizzati sulla disponibilità di risorse per la gestione di ulteriori richieste applicative e/o buste
eGov. Per ulteriori dettagli vedi Sezione 3.3.1.6.
Un Threshold personalizzato può essere definito semplicemente implementando l’interfaccia definita nella distribuzione in /src/org/openspcoop/pdd/threshold/IThreshold.java. La classe personalizzata, una volta creata, deve essere registrata nel file deploy/pdd/properties/className.properties inserendo una proprietà, dopo la lista dei threshold built-in forniti con la Porta di
Dominio OpenSPCoop:
# ------------ Threshold ------------org.openspcoop.threshold.mysqlFreeSpace=org.openspcoop.pdd.core.threshold.MySQLThreshold
org.openspcoop.threshold.postgresUsedSpace=org.openspcoop.pdd.core.threshold. ←PostgreSQLThreshold
# threshold personalizzato
org.openspcoop.threshold.tipo_threshold_personalizzato=package.personalizzato. ←ImplementazioneThresholdPersonalizzato
La classe package.personalizzato.ImplementazioneThresholdPersonalizzato può quindi essere referenziata come tipo di threshold all’interno della configurazione della porta di dominio (vedi Sezione 3.3.1.6), semplicemente usando la keyword tipo_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 vedi
Sezione 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 nel
file deploy/pdd/properties/className.properties inserendo una proprietà, dopo la lista dei marcatori built-in forniti con la Porta
di Dominio OpenSPCoop:
# ----------- Gestore Repository EGov ---------------------org.openspcoop.repositoryEGov.default=org.openspcoop.egov.GestoreRepositoryEGovDefault
org.openspcoop.repositoryEGov.bytewise=org.openspcoop.egov.GestoreRepositoryEGovBytewise
org.openspcoop.repositoryEGov.oracle=org.openspcoop.egov.GestoreRepositoryEGovOracle
# marcatore personalizzato
org.openspcoop.repositoryEGov.tipo_marcatore_personalizzato=package.personalizzato. ←ImplementazioneMarcatoreRepositoryEGOVPersonalizzato
La classe package.personalizzato.ImplementazioneMarcatoreRepositoryEGOVPersonalizzato può quindi essere referenziata come tipo di marcatore all’interno della configurazione della porta di dominio (vedi Sezione 3.3.1.11), semplicemente usando la
keyword 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/pdd/properties/className.properties inserendo una proprietà, dopo la lista delle sorgenti temporali built-in forniti con la Porta di
Dominio OpenSPCoop:
# ----------- Date ------------------------------------org.openspcoop.date.system=org.openspcoop.utils.date.SystemDate
org.openspcoop.date.java=org.openspcoop.utils.date.JavaDate
org.openspcoop.date.ntp=org.openspcoop.utils.date.NTPDate
org.openspcoop.date.tcpTime=org.openspcoop.utils.date.TCPTimeDate
org.openspcoop.date.udpTime=org.openspcoop.utils.date.UDPTimeDate
# sorgente personalizzata
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
38 / 84
org.openspcoop.date.tipo_sorgente_personalizzata=package.personalizzato. ←ImplementazioneDatePersonalizzata
La classe package.personalizzato.ImplementazioneDatePersonalizzata può quindi essere referenziata come tipo di sorgente temporale all’interno della configurazione della porta di dominio (vedi Sezione 3.3.1.14), semplicemente usando la keyword tipo_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 dei
servizi per poter interoperare con Porte di Dominio che sono conforme alle nuove linee guida per la certificazione, ma anche con
porte 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 diverse
disambiguità presenti nelle precedenti versioni della specifica (Sistema Pubblico di Cooperazione: Busta EGov 1.1 ). Ciò nonostante, nei contesti in cui si deve cooperare con porte di dominio che non si sono ancora allineate alle linee guida, potrebbero
essere presenti tali disambiguità. La Porta di Dominio OpenSPCoop permette di affrontare tali disambiguità agendo sulle proprietà 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 la
configurazione riflette in tutte le cooperazioni che verranno intraprese dalla porta di dominio in modalità non linee guida. Quindi
se abbiamo due porte di dominio diverse con cui interoperare (non ancora allineate alle linee guida), che presentano lo stesso
problema di interoperabilità, ma soluzione diversa, come fare?
In questi contesti è possibile personalizzare il comportamento della nostra porta di dominio, in funzione della porta di dominio
con cui si deve interoperare. Per farlo è necessario configurare nel registro dei servizi la porta di domimio con cui si deve cooperare, e associarla al soggetto che gestisce. Nella configurazione della porta di dominio deve essere specificato nell’elemento
implementazione una keyword che la identifica (es. OraclePDD). Dopodichè è possibile indicare nel file presente in deploy/pdd/properties/pdd.properties le proprietà della configurazione che si vuole ridefinire quando si deve interoperare con la porta di
dominio indicata dalla keyword. Le proprietà ridefinibili riguardano:
• Validazione Buste e-Gov, è possibile ridefinire la validazione e-Gov della configurazione delle porta di dominio, descritta in
Guida 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/disa
– manifestAttachments, ridefinibile tramite la proprietà @[email protected]=abilitato/disabi
Inoltre è possibile anche ridefinire le seguenti proprietà descritte in Sezione 3.3.1.11 riguardanti la validazione della busta
e-Gov:
– org.openspcoop.egov.filtroDuplicati.letturaRegistro, ridefinibile tramite la proprietà @[email protected]
– org.openspcoop.egov.confermaRicezione.letturaRegistro, ridefinibile tramite la proprietà @[email protected]
– org.openspcoop.egov.consegnaInOrdine.letturaRegistro, ridefinibile tramite la proprietà @[email protected]
– org.openspcoop.egov.validazione.readQualifiedAttribute, ridefinibile tramite la proprietà @[email protected]
– org.openspcoop.egov.validazione.idegov.validazioneCompleta, ridefinibile tramite la proprietà @[email protected]
• 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]
– org.openspcoop.egov.collaborazione.enable, ridefinibile tramite la proprietà @[email protected]
– org.openspcoop.egov.consegnaInOrdine.enable, ridefinibile tramite la proprietà @[email protected]
– org.openspcoop.egov.trasmissione.enable, ridefinibile tramite la proprietà @[email protected]=tru
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
–
–
–
–
–
39 / 84
org.openspcoop.egov.riscontri.enable, ridefinibile tramite la proprietà @[email protected]=true/false
org.openspcoop.egov.filtroduplicati.generazioneSPCoopErrore, ridefinibile tramite la proprietà @[email protected]
org.openspcoop.egov.manifestAttachments.role.richiesta, ridefinibile tramite la proprietà @[email protected]
org.openspcoop.egov.manifestAttachments.role.risposta, ridefinibile tramite la proprietà @[email protected]
org.openspcoop.egov.manifestAttachments.role.allegato, ridefinibile tramite la proprietà @[email protected]
Inoltre, sempre riguardante la generazione della busta e-gov è ridefinibile la proprietà org.openspcoop.pdd.tempo.tipo, descritta
in 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 descritta in Guida Utente XML della Porta di Dominio: Configurazione, validazione contenuti applicativi e Guida Utente della
Porta di Dominio: Funzionalità avanzate, validazione XSD :
– stato, ridefinibile tramite la proprietà @[email protected]=abilitato/disabilitato/warningOn
– 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 in
Sezione 3.3.1.9:
– org.openspcoop.pdd.wssecurity.actorDefault.enable, ridefinibile tramite la proprietà @[email protected].
– org.openspcoop.pdd.wssecurity.actorDefault.valore, ridefinibile tramite la proprietà @[email protected]
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 e
accessibili via http.
• Registro dei Servizi UDDI, il registro è realizzato tramite un registro in tecnologia UDDI che indicizza un insieme di oggetti
descritti 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 di
configurazione 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 crea
gli oggetti sempre sul registro dei servizi basato su DBMS e inoltre, se configurata, i dati vengono inoltrati al registro dei servizi
WEB o UDDI.
Infine qualsiasi tipologia del registro dei servizi può essere estesa tramite una interfaccia WebService, descritta in (Interfaccia
WS per il Registro dei Servizi ).
4.1
Interfaccia Web del Registro dei Servizi
4.1.1
4.1.1.1
Compilazione dei sorgenti
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 application
server J2EE.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
4.1.1.2
40 / 84
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.
Nota
La 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 JBoss
4.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 in
Sezione 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 le
tabelle utilizzate per la raccolta degli accordi di servizio e soggetti. Attualmente lo sviluppo di OpenSPCoop viene effettuato su
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/regserv/deploy/sql/TIPO_DATABASE
Nota
L’interfaccia deve possedere i diritti per leggere ed inserire elementi nelle tabelle.
A titolo esemplificativo, vengono elencati i passi di configurazione da effettuare per la configurazione del Database PostgreSQL
su sistema operativo Linux.
1. Creazione Utente
[user@localhost]$ su
Parola d’ordine: XXX
[root@localhost]# su - postgres
-bash-3.1$ createuser -P
Enter name of role to add: regserv
Enter password for new role: regserv
Conferma password: regserv
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n
CREATE ROLE
2. Crezione Database
[user@localhost]$ su
Parola d’ordine: XXX
[root@localhost]# su - postgres
-bash-3.1$createdb -O regserv regserv
CREATE DATABASE
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
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 md5
host regserv regserv 127.0.0.1 255.255.255.255 md5
4. Creazione tabelle SQL
[user@localhost]$ psql regserv regserv < tools/web_interfaces/regserv/deploy/sql/ ←TIPO_DATABASE/RegistroServizi.sql
Password for user regserv: regserv
5. Fornire infine all’application server il driver JDBC del DB utilizzato. Ad es. per l’A.S. JBoss copiare l’apposito jar nella
cartella JBOSS/server/default/lib.
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.dataSo
Un datasource di esempio per l’application server JBoss viene fornito in tools/web_interfaces/regserv/deploy/datasource/jboss/regservds.xml. Il file permette di creare la risorsa nella propria installazione dell’A.S., attraverso la configurazione e la successiva copia
del file in JBOSS_DIR/server/default/deploy.
In alternativa, per l’application server JBoss, è possibile utilizzare un datasource realizzato tramite l’applicazione openspcoopSysconfig; 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 tools/web_interfaces/regserv/deploy/datasource/tomcat/regserv
Il file permette di creare la risorsa nella propria installazione di Tomcat, attraverso la configurazione e la successiva copia del file
in TOMCAT_DIR/Catalina/ (es. /etc/tomcat5/Catalina/localhost/).
Nota
Per ulteriori informazioni su come utilizzare un datasource registrato con nome JNDI diverso dal default vedi Sezione 4.1.3.2.
Nota
L’applicazione openspcoopSysconfig, disponibile nella distribuzione in tools/sysconfig, permette di creare pool di risorse e registrarli nell’albero JNDI del proprio Application Server. La definizione dei pool deve essere fornita tramite un file xml che rispetti
lo schema in tools/sysconfig/src/schemi/sysconfig.xsd . Tutti i pool indicati nella guida utente/installazione e richiesti dai vari
prodotti rilasciati con la distribuzione di OpenSPCoop sono descritti in una configurazione di esempio dell’applicazione openspcoopSysconfig 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.
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 registri
dei servizi di tipologia WEB e UDDI. Se si sta installando la versione per Servlet Container (Tomcat) non si deve seguire le
indicazioni descritte in questo paragrafo.
All’interno della distribuzione nella in tools/web_interfaces/regserv/deploy/code_jms/BROKER/regserv-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/regserv/deploy/code_jms/jbossMQ/regserv-destinations-service.xml, le code sono istanziabili in JBoss
4.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 in
JBoss 5.x attraverso la copia del file in JBOSSDIR/server/default/deploy/messaging
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
4.1.2.4
42 / 84
Configurazione Iniziale
L’interfaccia web del Registro dei Servizi di OpenSPCoop è preconfigurato per gestire un database di tipo postgresql e un Registro
dei 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’interno
dell’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 Sezione 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/ISTA
(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 acceduti
all’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. Per
ulteriori informazioni su come personalizzare i log vedi Sezione 4.1.3.4.
Nota
I SQL utilizzati per l’installazione dell’interfaccia grafica hanno creato un utente amministratore 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 ). Accedendo con tale utente verranno visualizzate solo le informazioni utili per la gestione di servizi SPCoop
conformi al documento Sistema Pubblico di Cooperazione: Linee Guida all’uso della Busta EGov 1.1 . Se si desidera avere
una visualizzazione completa è possibile agire sulla tipologia dell’utente nella sezione Configurazione -> Utente -> Tipologia
Interfaccia.
4.1.3
Configurazione
L’interfaccia web del Registro dei Servizi di OpenSPCoop è preconfigurato per gestire un database di tipo postgresql e un Registro
dei Servizi DB. Il prodotto è tuttavia altamente configurabile agendo sui file di proprietà presenti all’interno dell’archivio in
regserv.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
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
4.1.3.1
43 / 84
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 si
deve agire sul file di configurazione infoGeneral.cfg. Le proprietà da modificare, all’interno del file di configurazione, variano a
seconda 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 necessari
ulteriori 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, per
completare 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.3
indicare 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 il
contesto è 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 dati
esportata via http (tramite un server dedicato, quale ad es. apache, tomcat etc...), dove saranno mantenuti i contenuti del
registro. 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 indicizzati
tramite un Registro UDDI; in questo caso, per completare l’installazione, oltre ai passi indicati per la configurazione del
registro 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 installazione
di 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 pubblicazione al registro UDDI, tramite le proprietà UddiInquiryURL, UddiPublishURL, UddiUser e UddiPassword. Esempi di
valori 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 di
configurazione datasource.properties dove viene indicato, tramite la voce dataSource, il 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/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 gestiti
sono: postgresql/mysql/oracle (default: postgresql).
4.1.3.3
Accesso al broker JMS
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 proprietà indica il nome jndi utilizzato dall’interfaccia web per accedere ad una connection factory registrata nell’albero JNDI
dell’A.S. Il pool permetterà di creare connessioni e effettuare lookup verso il broker JMS sul quale è presente la coda descritta
in Sezione 4.1.2.3. È possibile fornire informazioni di contesto per la ricerca delle risorse, attraverso una o più voci ConnectionFactory.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).
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
4.1.3.4
44 / 84
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 un
certo tipo. Ad ogni Category sono associabili uno o più Appender (log4j.appender.*, ad esempio log4j.appender.tracer.file) che
rappresentano una risorse su cui memorizzare i log. Le risorse utilizzabili tramite il framework sono svariate, da filesystem, a
database, 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 sul
file /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 tali
proprietà, catalogate funzionalmente:
• Package CNIPA, gli accordi di servizio parte comune e specifica e gli accordi di cooperazione possono essere importati/esportati
in package CNIPA (vedi Release Notes: Versione 1.3, Import/Export degli accordi nel registro dei servizi compatibili con
ClientSICA ).
Tale funzionalità è attiva nell’interfaccia se l’opzione IMPORTA_ESPORTA assume il valore true (Default: true, valori
possibili: true/false).
• Ciclo di vita degli accordi, l’interfaccia grafica del registro dei servizi permette agli utenti di gestire il ciclo di vita degli accordi
di 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, valori
possibili: true/false).
• Gestione accordi di servizio, nella versione 1.0 di OpenSPCoop un Accordo di Servizio poteva corrispondere ad un unico
PortType del WSDL del Servizio. Questo limite è stato superato nella versione 1.1, introducendo la gestione esplicita dei
PortType 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 WSDL
che 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 parte
comune. 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 definire
un 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ò essere
specificata direttamente nell’accordo di servizio parte comune. L’accordo di servizio parte specifica viene automaticamente
gestito 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’opzione
accordi.showCorrelazioneAsincrona assume il valore true (Default: true, valori possibili: true/false).
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
45 / 84
• Gestione accordi di cooperazione, gli accordi di cooperazione e i servizi composti vengono gestiti dall’interfaccia web solo se
l’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 di
conversazione.
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 i
servizi. Tali endpoint possono essere semplici url http o connettori più complessi (es. JMS). L’interfaccia grafica è configurabile
per 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 deve
impostare 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 riguarda connettori e meccanismi di autenticazione/autorizzazione dei servizi applicativi. Questo poichè oltre alla possibilità di
selezionare un componente built-in, è permesso anche di indicarne uno creato e registrato dall’utente. Per ulteriori dettagli vedi
Sezione 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, valori
possibili: true/false).
• Terminologia degli Accordi di Servizio, la terminologia sugli accordi di servizio presente nelle interfacce grafiche è stata
adeguata ai documenti CNIPA, dalla versione 1.3. Per ulteriori dettagli vedi Release Notes: Versione 1.3, Miglioramenti
principali 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, AccordiServizioComposti e Adesioni
– openspcoop, i termini utilizzati saranno AccordiServizio, ServizioSPCoop, AccordiCooperazione, AccordiServizio + opzione composto e Fruitori
• Pulsante Aggiungi nel menù dell’interfaccia, l’interfaccia è modificabile per poter far comparire o meno il punsante Aggiungi
direttamente all’interno delle sezioni del menù. Il pulsante viene visualizzato se la proprietà menu.visualizzazioneLinkAggiungi
assume il valore true (Default: false).
• Pulsante Aggiungi nell’elenco degli oggetti, l’interfaccia è modificabile per poter far comparire o meno il punsante Aggiungi all’interno dell’elenco degli oggetti gestiti dall’interfaccia. Il pulsante viene visualizzato se la proprietà elenchi.visualizzaPulsanteAggiun
assume il valore true (Default: true).
• Visibilità utenti, un utente che ha i permessi di gestione dei servizi ’S’ (Release Notes: Versione 1.3, Introduzione dei
Permessi per l’accesso alle funzionalità delle console grafiche ) puo avere due tipologie di visibilità degli oggetti presenti
nell’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).
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
4.2
46 / 84
Interfaccia WebService del Registro dei Servizi
4.2.1
4.2.1.1
Compilazione dei sorgenti
Interfaccia WebService
I sorgenti dell’interfaccia web service del registro dei servizi sono disponibili all’interno della distribuzione nella directory tools/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 tipologia
di registro dei servizi descritta in Sezione 4
L’applicazione viene fornita sotto forma di archivio openspcoopRegistroServiziSearch.war come risultato della compilazione dei
sorgenti descritta in Sezione 4.2.1.1.
4.2.2.1
Configurazione Iniziale
L’interfaccia web service del Registro dei Servizi di OpenSPCoop è preconfigurata per gestire un registro basato 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’interno
dell’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.
4.2.2.2
Deploy del Software
Per la versione J2EE è sufficiente copiare il file dist/openspcoopRegistroServiziSearch.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/openspcoopRegistroServiziSearch.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/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. Per
ulteriori 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 archivio jar contenente degli stub utilizzabili per la creazione di un client Java basato sul framework soap Axis 1.4
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
4.2.3
47 / 84
Configurazione
L’interfaccia web service del Registro dei Servizi di OpenSPCoop è preconfigurata per gestire un registro su database di tipo postgresql. Il prodotto è tuttavia configurabile agendo sui file di proprietà presenti all’interno dell’archivio in openspcoopRegistroServiziSearc
INF/classes.
In questa sezione verrano descritti alcuni aspetti di configurazione avanzata riguardante:
• Tipologia del Registro dei Servizi
• Logging
4.2.3.1
Tipologia del Registro dei Servizi
L’applicazione web service si interfaccia per default ad un Registro dei Servizi DB di tipo postgresql. Se si vuole modificare la
tipologia del registro dei servizi si deve agire sul file di configurazione infoGeneral.cfg. Le proprietà da modificare, all’interno del
file 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 di
database 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/valore
dove il nome viene preso al posto del carattere speciale *. (Default: dataSource=org.openspcoop.dataSource.regserv e
dataSource.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 essere
indicato 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 indicizzati tramite un Registro UDDI; deve essere indicato come accedere all’area dati del repository web e come accedere al registro
UDDI 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.
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 un
certo tipo. Ad ogni Category sono associabili uno o più Appender (log4j.appender.*, ad esempio log4j.appender.tracer.file) che
rappresentano una risorse su cui memorizzare i log. Le risorse utilizzabili tramite il framework sono svariate, da filesystem, a
database, ad e-mail etc...
Le category presenti riguardano le seguenti tipologie di log:
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
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 database
relazionale, come descritto in Sezione 3.2.5. In questa sezione verrà descritto come installare e configurare il software necessario
alla configurazione basata su database relazionale, tralasciando completamente la configurazione basata su file xml che non
necessita 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 numero
di 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 la
dotazione di una Porta di Dominio per un singolo ente la cui gestione avviene localmente in completa autonomia. Per ulteriori
dettagli 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 dati
riguardanti 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 gestisce
autonomamente la configurazione della propria Porta di Dominio. Invece il Registro dei Servizi è unico, quindi condiviso da
tutte le porte di dominio, e gestito centralmente, ad esempio da un unico soggetto (es. un Centro Servizi Territoriale). Per
ulteriori 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 dati riguardanti gli accordi di servizio non vengono gestiti, ma dovranno essere conosciuti per essere inseriti dall’utente nei
componenti 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 di
monitoraggio:
• 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 essere
consegnati
L’interfaccia effettua le ricerche consultando il database dei messaggi descritto in Sezione 3.2.3.
5.1
PddConsole con Registro dei Servizi locale
5.1.1
5.1.1.1
Compilazione dei sorgenti
Interfaccia Web per Application Server J2EE
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, eseguendo
il seguente comando:
ant clean build_pddConsole
La compilazione produce come risultato un archivio pddConsole.war all’interno della directory dist installabile in un application
server J2EE.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
5.1.1.2
49 / 84
Interfaccia Web per Servlet Container
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, eseguendo
il seguente comando:
ant clean build_tomcat
La compilazione produce come risultato un archivio pddConsole.war all’interno della directory dist installabile in un servlet
container.
5.1.2
Installazione
I paragrafi di questa sezione descrivono come procedere con l’installazione dell’interfaccia web nell’application server JBoss
4.2.X / 5.x o nel servlet container Tomcat 5.x.
L’applicazione viene fornita sotto forma di archivio pddConsole.war come risultato della compilazione dei sorgenti descritta in
Sezione 5.1.1.1 e Sezione 5.1.1.2.
5.1.2.1
Configurazione del Database
L’interfaccia web richiede l’installazione di un database relazionale nel quale devono essere registrate le tabelle utilizzate per la
raccolta dei componenti di integrazione e degli accordi di servizio. Attualmente lo sviluppo di OpenSPCoop viene effettuato su
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_DAT
Nota
L’interfaccia deve possedere i diritti per leggere ed inserire elementi nelle tabelle.
A titolo esemplificativo, vengono elencati i passi di configurazione da effettuare per la configurazione del Database PostgreSQL
su sistema operativo Linux.
1. Creazione Utente
[user@localhost]$ su
Parola d’ordine: XXX
[root@localhost]# su - postgres
-bash-3.1$ createuser -P
Enter name of role to add: pddConsole
Enter password for new role: pddConsole
Conferma password: pddConsole
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n
CREATE ROLE
2. Crezione Database
[user@localhost]$ su
Parola d’ordine: XXX
[root@localhost]# su - postgres
-bash-3.1$createdb -O pddConsole pddConsole
CREATE 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 righe
al file:
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
50 / 84
local pddConsole pddConsole md5
host pddConsole pddConsole 127.0.0.1 255.255.255.255 md5
4. Creazione tabelle SQL
[user@localhost]$ psql pddConsole pddConsole < tools/web_interfaces/control_station/ ←deploy/sql/TIPO_DATABASE/single_pdd/PddConsole.sql
Password for user pddConsole: pddConsole
5. Fornire infine all’application server il driver JDBC del DB utilizzato. Ad es. per l’A.S. JBoss copiare l’apposito jar nella
cartella JBOSS/server/default/lib.
Nota
Il database include le tabelle per la memorizzazione delle tracce e dei messaggi diagnostici emessi dalla porta di dominio, le
quali 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 in
questa sezione, si deve configurare l’interfaccia a consultare tale database invece di quello creato in questo paragrafo; ulteriori
dettagli 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 cui
conservare le tracce e i messaggi diagnostici emessi è possibile consultare le sezioni Sezione 3.3.2.1 e Sezione 3.3.2.2.
5.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.dataSo
Un datasource di esempio per l’application server JBoss viene fornito in tools/web_interfaces/control_station/deploy/datasource/jboss/pd
ds.xml. Il file permette di creare la risorsa nella propria installazione dell’A.S., attraverso la configurazione e la successiva copia
del file in JBOSS_DIR/server/default/deploy.
In alternativa, per l’application server JBoss, è possibile utilizzare un datasource realizzato tramite l’applicazione openspcoopSysconfig; 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 tools/web_interfaces/control_station/deploy/datasource/tomca
Il file permette di creare la risorsa nella propria installazione di Tomcat, attraverso la configurazione e la successiva copia del file
in TOMCAT_DIR/Catalina/ (es. /etc/tomcat5/Catalina/localhost/).
Nota
Per ulteriori informazioni su come utilizzare un datasource registrato con nome JNDI diverso dal default vedi Sezione 5.1.3.1.
Nota
L’applicazione openspcoopSysconfig, disponibile nella distribuzione in tools/sysconfig, permette di creare pool di risorse e registrarli nell’albero JNDI del proprio Application Server. La definizione dei pool deve essere fornita tramite un file xml che rispetti
lo schema in tools/sysconfig/src/schemi/sysconfig.xsd . Tutti i pool indicati nella guida utente/installazione e richiesti dai vari
prodotti rilasciati con la distribuzione di OpenSPCoop sono descritti in una configurazione di esempio dell’applicazione openspcoopSysconfig 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.
5.1.2.3
Configurazione Iniziale
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/WEBINF/classes.
Per ulteriori dettagli su come modificare il tipo di database è possibile vedere Sezione 5.1.3.1.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
5.1.2.4
51 / 84
Deploy del Software
Per la versione J2EE è sufficiente copiare il file dist/pddConsole.war nella directory di deploy dell’application server: JBOSS_DIR/server
(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).
Una volta effettuato il deploy, l’applicazione dovrebbe essere disponibile all’indirizzo:
• http://localhost:8080/pddConsole/login.do
Per effettuare il login di accesso è possibile utilizzare come login amministratore e come password secret. Una volta acceduti
all’interfaccia sarà possibile cambiare la password dell’amministratore.
L’applicazione produce dei log che registrano le operazioni effettuate nel file /var/openspcoop/log/ControlStationCore.log. Per
ulteriori informazioni su come personalizzare i log vedi Sezione 5.1.3.5.
Nota
I SQL utilizzati per l’installazione dell’interfaccia grafica hanno creato un utente amministratore 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 ). Accedendo con tale utente verranno visualizzate solo le informazioni utili per la gestione di servizi SPCoop
conformi al documento Sistema Pubblico di Cooperazione: Linee Guida all’uso della Busta EGov 1.1 . Se si desidera avere
una visualizzazione completa è possibile agire sulla tipologia dell’utente nella sezione Configurazione -> Utente -> Tipologia
Interfaccia.
5.1.3
Configurazione
L’interfaccia web PddConsole con registro dei servizi locale è preconfigurata per gestire un database di tipo postgresql. Il
prodotto è tuttavia altamente configurabile agendo sui file di proprietà presenti all’interno dell’archivio in pddConsole.war/WEBINF/classes.
In questa sezione verrano descritti alcuni aspetti di configurazione avanzata riguardante:
• 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
• Personalizzazione dell’interfaccia
5.1.3.1
Accesso al DBMS
L’accesso al database dove vengono conservati i componenti di integrazione e gli accordi (vedi Sezione 5.1.2.1), viene definito
tramite il file di configurazione datasource.properties dove viene indicato, tramite la voce dataSource, il 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/valore dove il nome viene preso al posto del carattere
speciale *. (Default: dataSource=org.openspcoop.dataSource.pddConsole 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 gestiti
sono: postgresql/mysql/oracle (default: postgresql).
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
5.1.3.2
52 / 84
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 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 database
utilizzato 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à tracce.sameDBWebUI al valore false.
L’accesso al database viene indicato, tramite la voce tracce.dataSource, in modo da fornire il 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 tracce.dataSource.property.*, tramite la definizione di coppie nome/valore dove il nome viene preso al posto del
carattere speciale *.
La voce tracce.tipoDatabase (interpretata solo se tracce.sameDBWebUI=false) permette di impostare il tipo di database utilizzato: postgresql/mysql/oracle
La voce tracce.configurazioneCustomAppender abilita la gestione degli OpenSPCoopAppender (Sezione 3.3.2.2) all’interno
della 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 diagnostici
su 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 database
utilizzato 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 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à msgDiagnostici.sameDBWebUI al valore false.
L’accesso al database viene indicato, tramite la voce msgDiagnostici.dataSource, in modo da fornire il 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 msgDiagnostici.dataSource.property.*, tramite la definizione di coppie nome/valore dove il nome viene
preso al posto del carattere speciale *.
La voce msgDiagnostici.tipoDatabase (interpretata solo se msgDiagnostici.sameDBWebUI=false) permette di impostare il tipo
di database utilizzato: postgresql/mysql/oracle
La voce msgDiagnostici.configurazioneCustomAppender abilita la gestione degli OpenSPCoopAppender (Sezione 3.3.2.1) all’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 database
utilizzato 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 dataSource registrato nell’albero JNDI dell’A.S. È possibile fornire informazioni di contesto per la ricerca del dataSource, attraverso
una o più voci singlePdD.monitor.dataSource.property.*, tramite la definizione di coppie nome/valore dove il nome viene preso
al 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)
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
5.1.3.5
53 / 84
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 un
certo tipo. Ad ogni Category sono associabili uno o più Appender (log4j.appender.*, ad esempio log4j.appender.tracer.file) che
rappresentano una risorse su cui memorizzare i log. Le risorse utilizzabili tramite il framework sono svariate, da filesystem, a
database, 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.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.DR
Per default tali categories emettono log, con verbosità DEBUG, rispettivamente sui file /var/openspcoop/log/DriverConfigurazioneDB.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 sul
file /var/openspcoop/log/AuditingControlStation.log con verbosità DEBUG.
Nota
Le altre categories presenti nel file tracer.log4j.properties non vengono interpretate dalla versione della PddConsole descritta in
questa sezione; verrano utilizzate per la gestione remota delle Pdd e del Registro dei Servizi descritto nella sezione Sezione 6
5.1.3.6
Personalizzazione dell’interfaccia
Le proprietà presenti nel file infoGeneral.cfg permettono di personalizzare l’interfaccia web. Di seguito vengono riportate tali
proprietà, catalogate funzionalmente:
• Package CNIPA, gli accordi di servizio parte comune e specifica e gli accordi di cooperazione possono essere importati/esportati
in package CNIPA (vedi Release Notes: Versione 1.3, Import/Export degli accordi nel registro dei servizi compatibili con
ClientSICA ).
Tale funzionalità è attiva nell’interfaccia se l’opzione IMPORTA_ESPORTA assume il valore true (Default: true, valori
possibili: true/false).
• Ciclo di vita degli accordi, l’interfaccia grafica del registro dei servizi permette agli utenti di gestire il ciclo di vita degli accordi
di 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, valori
possibili: true/false).
• Gestione accordi di servizio, nella versione 1.0 di OpenSPCoop un Accordo di Servizio poteva corrispondere ad un unico
PortType del WSDL del Servizio. Questo limite è stato superato nella versione 1.1, introducendo la gestione esplicita dei
PortType 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 WSDL
che 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 parte
comune. 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).
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
54 / 84
• Soggetto referente e versione, dalla versione 1.1 di OpenSPCoop per un accordo di servizio parte comune è obbligatorio definire
un 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ò essere
specificata direttamente nell’accordo di servizio parte comune. L’accordo di servizio parte specifica viene automaticamente
gestito 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’opzione
accordi.showCorrelazioneAsincrona assume il valore true (Default: true, valori possibili: true/false).
• Gestione accordi di cooperazione, gli accordi di cooperazione e i servizi composti vengono gestiti dall’interfaccia web solo se
l’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 di
conversazione.
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 i
servizi. Tali endpoint possono essere semplici url http o connettori più complessi (es. JMS). L’interfaccia grafica è configurabile
per 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 deve
impostare 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 riguarda connettori e meccanismi di autenticazione/autorizzazione dei servizi applicativi. Questo poichè oltre alla possibilità di
selezionare un componente built-in, è permesso anche di indicarne uno creato e registrato dall’utente. Per ulteriori dettagli vedi
Sezione 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, valori
possibili: true/false).
• Terminologia degli Accordi di Servizio, la terminologia sugli accordi di servizio presente nelle interfacce grafiche è stata
adeguata ai documenti CNIPA, dalla versione 1.3. Per ulteriori dettagli vedi Release Notes: Versione 1.3, Miglioramenti
principali 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, AccordiServizioComposti e Adesioni
– openspcoop, i termini utilizzati saranno AccordiServizio, ServizioSPCoop, AccordiCooperazione, AccordiServizio + opzione composto e Fruitori
• generazioneAutomaticaPorteDelegate, all’aggiunta di una adesione in un accordo di servizio parte specifica, viene creata
automaticamente il componente di integrazione (PortaDelegata) necessario ad un servizio applicativo per poter effettivamente
fruire 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 non
devono essere configurabili tramite PddConsole. La proprietà org.openspcoop.pdd.server permette proprio di indicare quale
ambiente 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)
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
55 / 84
• pa.SPCoopProperties.valoriPredefiniti, la porta applicativa permette di configurare delle proprietà relative a informazioni SPCoop, che verranno utilizzate dalla Porta di Dominio per propagare le informazioni presenti nella busta eGov all’interno
dell’header di trasporto utilizzato per invocare un servizio applicativo (vedi Guida Utente XML: Configurazione PdD, SPCoop
Property ).
L’inserimento delle proprietà da parte dell’utente, può essere pilotato tramite un insieme di valori ammissibili o può essere
lasciato libero. Tale comportamento è configurato dalla proprietà pa.SPCoopProperties.valoriPredefiniti. (Default: true, valori
possibili: true/false).
• Pulsante Aggiungi nel menù dell’interfaccia, l’interfaccia è modificabile per poter far comparire o meno il punsante Aggiungi
direttamente all’interno delle sezioni del menù. Il pulsante viene visualizzato se la proprietà menu.visualizzazioneLinkAggiungi
assume il valore true (Default: false).
• Pulsante Aggiungi nell’elenco degli oggetti, l’interfaccia è modificabile per poter far comparire o meno il punsante Aggiungi all’interno dell’elenco degli oggetti gestiti dall’interfaccia. Il pulsante viene visualizzato se la proprietà elenchi.visualizzaPulsanteAggiun
assume il valore true (Default: true).
• Visualizzazione del numero di elementi di una lista, l’interfaccia è modificabile per poter far comparire o meno il totale degli
elementi 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 destinate
a 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).
• Visibilità utenti, un utente che ha i permessi di gestione dei servizi ’S’ (Release Notes: Versione 1.3, Introduzione dei
Permessi per l’accesso alle funzionalità delle console grafiche ) puo avere due tipologie di visibilità degli oggetti presenti
nell’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).
Nota
La proprietà singlePdD presente nel file infoGeneral.cfg non deve essere modificata. Tale proprietà indica all’interfaccia di
lavorare 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
Nota
Le altre proprietà presenti nel file infoGeneral.cfg non vengono interpretate dalla versione della PddConsole descritta in questa
sezione; 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
5.2.1
5.2.1.1
Compilazione dei sorgenti
Interfaccia Web per Application Server J2EE
I sorgenti dell’interfaccia web sono disponibili all’interno della distribuzione nella directory tools/web_interfaces/pdd/src. Per
procedere con la compilazione è necessario utilizzare l’utility Ant sul path tools/web_interfaces/pdd, eseguendo il seguente
comando:
ant clean build
La compilazione produce come risultato un archivio pdd.war all’interno della directory dist installabile in un application server
J2EE.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
5.2.1.2
56 / 84
Interfaccia Web per Servlet Container
I sorgenti dell’interfaccia web sono disponibili all’interno della distribuzione nella directory tools/web_interfaces/pdd/src. Per
procedere con la compilazione è necessario utilizzare l’utility Ant sul path tools/web_interfaces/pdd, eseguendo il seguente
comando:
ant clean build_tomcat
La compilazione produce come risultato un archivio pdd.war all’interno della directory dist installabile in un servlet container.
5.2.2
Installazione
I paragrafi di questa sezione descrivono come procedere con l’installazione dell’interfaccia web nell’application server JBoss
4.2.X / 5.x o nel servlet container Tomcat 5.x.
L’applicazione viene fornita sotto forma di archivio pdd.war come risultato della compilazione dei sorgenti descritta in Sezione 5.2.1.1 e Sezione 5.2.1.2.
5.2.2.1
Configurazione del Database
L’interfaccia web richiede l’installazione di un database relazionale nel quale devono essere registrate le tabelle utilizzate per la
raccolta dei componenti di integrazione e degli accordi di servizio. Attualmente lo sviluppo di OpenSPCoop viene effettuato su
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/pdd/deploy/sql/TIPO_DATABASE/Co
Nota
L’interfaccia deve possedere i diritti per leggere ed inserire elementi nelle tabelle.
A titolo esemplificativo, vengono elencati i passi di configurazione da effettuare per la configurazione del Database PostgreSQL
su sistema operativo Linux.
1. Creazione Utente
[user@localhost]$ su
Parola d’ordine: XXX
[root@localhost]# su - postgres
-bash-3.1$ createuser -P
Enter name of role to add: pdd
Enter password for new role: pdd
Conferma password: pdd
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n
CREATE ROLE
2. Crezione Database
[user@localhost]$ su
Parola d’ordine: XXX
[root@localhost]# su - postgres
-bash-3.1$createdb -O pdd pdd
CREATE 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:
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
57 / 84
local pdd pdd md5
host pdd pdd 127.0.0.1 255.255.255.255 md5
4. Creazione tabelle SQL
[user@localhost]$ psql pdd pdd < tools/web_interfaces/pdd/deploy/sql/TIPO_DATABASE/ ←ConfigurazionePdD.sql
Password for user pdd: pdd
5. Fornire infine all’application server il driver JDBC del DB utilizzato. Ad es. per l’A.S. JBoss copiare l’apposito jar nella
cartella JBOSS/server/default/lib.
Nota
Il database include le tabelle per la memorizzazione delle tracce e dei messaggi diagnostici emessi dalla porta di dominio, le
quali 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 in
questa sezione, si deve configurare l’interfaccia a consultare tale database invece di quello creato in questo paragrafo; ulteriori
dettagli 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 cui
conservare le tracce e i messaggi diagnostici emessi è possibile consultare le sezioni Sezione 3.3.2.1 e Sezione 3.3.2.2.
5.2.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.dataSo
Un datasource di esempio per l’application server JBoss viene fornito in tools/web_interfaces/pdd/deploy/datasource/jboss/configds.xml. Il file permette di creare la risorsa nella propria installazione dell’A.S., attraverso la configurazione e la successiva copia
del file in JBOSS_DIR/server/default/deploy.
In alternativa, per l’application server JBoss, è possibile utilizzare un datasource realizzato tramite l’applicazione openspcoopSysconfig; 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 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 file
in TOMCAT_DIR/Catalina/ (es. /etc/tomcat5/Catalina/localhost/).
Nota
Per ulteriori informazioni su come utilizzare un datasource registrato con nome JNDI diverso dal default vedi Sezione 5.2.3.1.
Nota
L’applicazione openspcoopSysconfig, disponibile nella distribuzione in tools/sysconfig, permette di creare pool di risorse e registrarli nell’albero JNDI del proprio Application Server. La definizione dei pool deve essere fornita tramite un file xml che rispetti
lo schema in tools/sysconfig/src/schemi/sysconfig.xsd . Tutti i pool indicati nella guida utente/installazione e richiesti dai vari
prodotti rilasciati con la distribuzione di OpenSPCoop sono descritti in una configurazione di esempio dell’applicazione openspcoopSysconfig 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.
5.2.2.3
Configurazione Iniziale
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/WEBINF/classes.
Per ulteriori dettagli su come modificare il tipo di database è possibile vedere Sezione 5.2.3.1.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
5.2.2.4
58 / 84
Deploy del Software
Per la versione J2EE è sufficiente copiare il file dist/pdd.war nella directory di deploy dell’application server: JBOSS_DIR/server/ISTANZ
(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: TOMCAT_DIR/webapps (es. /var/lib/tomcat5/webapps).
Una volta effettuato il deploy, l’applicazione dovrebbe essere disponibile all’indirizzo:
• http://localhost:8080/pdd/login.do
Per effettuare il login di accesso è possibile utilizzare come login amministratore e come password secret. Una volta acceduti
all’interfaccia sarà possibile cambiare la password dell’amministratore.
L’applicazione produce dei log che registrano le operazioni effettuate nel file /var/openspcoop/log/InterfacciaPdD.log. Per
ulteriori informazioni su come personalizzare i log vedi Sezione 5.2.3.5.
Nota
I SQL utilizzati per l’installazione dell’interfaccia grafica hanno creato un utente amministratore 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 ). Accedendo con tale utente verranno visualizzate solo le informazioni utili per la gestione di servizi SPCoop
conformi al documento Sistema Pubblico di Cooperazione: Linee Guida all’uso della Busta EGov 1.1 . Se si desidera avere
una visualizzazione completa è possibile agire sulla tipologia dell’utente nella sezione Configurazione -> Utente -> Tipologia
Interfaccia.
5.2.3
Configurazione
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/WEBINF/classes.
In questa sezione verrano descritti alcuni aspetti di configurazione avanzata riguardante:
• 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
• Personalizzazione dell’interfaccia
5.2.3.1
Accesso al DBMS
L’accesso al database dove vengono conservati i componenti di integrazione (vedi Sezione 5.2.2.1), viene definito tramite il file
di configurazione datasource.properties dove viene indicato, tramite la voce dataSource, il 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/valore dove il nome viene preso al posto del carattere speciale *.
(Default: dataSource=org.openspcoop.dataSource.pdd 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 gestiti
sono: postgresql/mysql/oracle (default: postgresql).
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
5.2.3.2
59 / 84
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 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 database
utilizzato 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à tracce.sameDBWebUI al valore false.
L’accesso al database viene indicato, tramite la voce tracce.dataSource, in modo da fornire il 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 tracce.dataSource.property.*, tramite la definizione di coppie nome/valore dove il nome viene preso al posto del
carattere speciale *.
La voce tracce.tipoDatabase (interpretata solo se tracce.sameDBWebUI=false) permette di impostare il tipo di database utilizzato: postgresql/mysql/oracle
La voce tracce.configurazioneCustomAppender abilita la gestione degli OpenSPCoopAppender (Sezione 3.3.2.2) all’interno
della 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 diagnostici
su 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 database
utilizzato 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 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à msgDiagnostici.sameDBWebUI al valore false.
L’accesso al database viene indicato, tramite la voce msgDiagnostici.dataSource, in modo da fornire il 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 msgDiagnostici.dataSource.property.*, tramite la definizione di coppie nome/valore dove il nome viene
preso al posto del carattere speciale *.
La voce msgDiagnostici.tipoDatabase (interpretata solo se msgDiagnostici.sameDBWebUI=false) permette di impostare il tipo
di database utilizzato: postgresql/mysql/oracle
La voce msgDiagnostici.configurazioneCustomAppender abilita la gestione degli OpenSPCoopAppender (Sezione 3.3.2.1) all’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 database
utilizzato 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 dataSource
registrato nell’albero JNDI dell’A.S. È possibile fornire informazioni di contesto per la ricerca del dataSource, attraverso una
o più voci monitor.dataSource.property.*, tramite la definizione di coppie nome/valore dove il nome viene preso al posto del
carattere 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)
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
5.2.3.5
60 / 84
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 un
certo tipo. Ad ogni Category sono associabili uno o più Appender (log4j.appender.*, ad esempio log4j.appender.tracer.file) che
rappresentano una risorse su cui memorizzare i log. Le risorse utilizzabili tramite il framework sono svariate, da filesystem, a
database, 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.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’accesso
al 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 sul
file /var/openspcoop/log/AuditingPdd.log con verbosità DEBUG.
Nota
Le altre categories presenti nel file tracer.log4j.properties non vengono interpretate dalla versione della PddConsole descritta in
questa sezione; verrano utilizzate per la gestione remota delle Pdd e del Registro dei Servizi descritto nella sezione Sezione 6
5.2.3.6
Personalizzazione dell’interfaccia
Le proprietà presenti nel file infoGeneral.cfg permettono di personalizzare l’interfaccia web. Di seguito vengono riportate tali
proprietà, catalogate funzionalmente:
• Gestione connettori, i soggetti SPCoop e i gli accordi di servizio parte specifica contengono gli endpoint dove sono erogati i
servizi. Tali endpoint possono essere semplici url http o connettori più complessi (es. JMS). L’interfaccia grafica è configurabile
per 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 deve
impostare 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 riguarda connettori e meccanismi di autenticazione/autorizzazione dei servizi applicativi. Questo poichè oltre alla possibilità di
selezionare un componente built-in, è permesso anche di indicarne uno creato e registrato dall’utente. Per ulteriori dettagli vedi
Sezione 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, 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 non
devono essere configurabili tramite PddConsole. La proprietà org.openspcoop.pdd.server permette proprio di indicare quale
ambiente 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)
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
61 / 84
• pa.SPCoopProperties.valoriPredefiniti, la porta applicativa permette di configurare delle proprietà relative a informazioni SPCoop, che verranno utilizzate dalla Porta di Dominio per propagare le informazioni presenti nella busta eGov all’interno
dell’header di trasporto utilizzato per invocare un servizio applicativo (vedi Guida Utente XML: Configurazione PdD, SPCoop
Property ).
L’inserimento delle proprietà da parte dell’utente, può essere pilotato tramite un insieme di valori ammissibili o può essere
lasciato libero. Tale comportamento è configurato dalla proprietà pa.SPCoopProperties.valoriPredefiniti. (Default: true, valori
possibili: true/false).
• Pulsante Aggiungi nel menù dell’interfaccia, l’interfaccia è modificabile per poter far comparire o meno il punsante Aggiungi
direttamente all’interno delle sezioni del menù. Il pulsante viene visualizzato se la proprietà menu.visualizzazioneLinkAggiungi
assume il valore true (Default: false).
• Pulsante Aggiungi nell’elenco degli oggetti, l’interfaccia è modificabile per poter far comparire o meno il punsante Aggiungi all’interno dell’elenco degli oggetti gestiti dall’interfaccia. Il pulsante viene visualizzato se la proprietà elenchi.visualizzaPulsanteAggiun
assume il valore true (Default: true).
• Soggetti Virtuali, la Porta di Dominio OpenSPCoop può essere configurata, per casi eccezionali, per processare buste destinate
a 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).
• Visibilità utenti, un utente che ha i permessi di gestione dei servizi ’S’ (Release Notes: Versione 1.3, Introduzione dei
Permessi per l’accesso alle funzionalità delle console grafiche ) puo avere due tipologie di visibilità degli oggetti presenti
nell’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).
6
Pdd Console per la gestione centralizzata
La PddConsole può essere utilizzata come strumento di gestione centralizzata di vari componenti software OpenSPCoop, che
a 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 Servizi
OpenSPCoop, un Gestore Eventi OpenSPCoop ed eventualmente anche componenti custom, facilmente implementabili come
plugin 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’interfaccia 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 della
configurazione di una Porta di Dominio OpenSPCoop. Tipicamente installato in tutti gli ApplicationServer dove risiedono le
porte di dominio gestite.
• WebService di gestione del Monitoraggio di una Porta di Dominio. Implementa una interfaccia SOAP per il monitoraggio
dello stato di una Porta di Dominio OpenSPCoop. Tipicamente installato in tutti gli ApplicationServer dove risiedono le porte
di dominio gestite.
Nota
L’uso della PddConsole richiede che le porte di dominio gestite siano configurate per leggere la propria configurazione da DB
relazionale (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 di
tipologia DB o WEB (vedi Sezione 3.2.6).
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
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
Nota
Non esiste attualmente una versione della PddConsole, per la gestione centralizzata, installabile in un Servlet Container.
6.1
6.1.1
Interfaccia Web di gestione centralizzata
Compilazione dei sorgenti
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, eseguendo
il seguente comando:
ant clean build
La compilazione produce come risultato un archivio pddConsole.war all’interno della directory dist installabile in un application
server J2EE.
6.1.2
Installazione
I paragrafi di questa sezione descrivono come procedere con l’installazione dell’interfaccia web nell’application server JBoss
4.2.X / 5.x
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
63 / 84
L’applicazione viene fornita sotto forma di archivio pddConsole.war come risultato della compilazione dei sorgenti descritta in
Sezione 6.1.1 .
6.1.2.1
Configurazione del Database
L’interfaccia web richiede l’installazione di un database relazionale. Attualmente lo sviluppo di OpenSPCoop viene effettuato
su 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_DAT
Nota
L’interfaccia deve possedere i diritti per leggere ed inserire elementi nelle tabelle.
A titolo esemplificativo, vengono elencati i passi di configurazione da effettuare per la configurazione del Database PostgreSQL
su sistema operativo Linux.
1. Creazione Utente
[user@localhost]$ su
Parola d’ordine: XXX
[root@localhost]# su - postgres
-bash-3.1$ createuser -P
Enter name of role to add: pddConsole
Enter password for new role: pddConsole
Conferma password: pddConsole
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) n
CREATE ROLE
2. Crezione Database
[user@localhost]$ su
Parola d’ordine: XXX
[root@localhost]# su - pddConsole
-bash-3.1$createdb -O pddConsole pddConsole
CREATE 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 righe
al file:
local pddConsole pddConsole md5
host pddConsole pddConsole 127.0.0.1 255.255.255.255 md5
4. Creazione tabelle SQL
[user@localhost]$ psql pddConsole pddConsole < tools/web_interfaces/control_station/ ←deploy/sql/TIPO_DATABASE/PddConsole.sql
Password for user pddConsole: pddConsole
5. Fornire infine all’application server il driver JDBC del DB utilizzato. Ad es. per l’A.S. JBoss copiare l’apposito jar nella
cartella JBOSS/server/default/lib.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
6.1.2.2
64 / 84
Pool di Connessioni
L’interfaccia web richiede l’installazione di un pool di connessioni verso il DBMS che possieda come nome JNDI: org.openspcoop.dataSo
Un datasource di esempio per l’application server JBoss viene fornito in tools/web_interfaces/control_station/deploy/datasource/jboss/pd
ds.xml. Il file permette di creare la risorsa nella propria installazione dell’A.S., attraverso la configurazione e la successiva copia
del file in JBOSS_DIR/server/default/deploy.
In alternativa, per l’application server JBoss, è possibile utilizzare un datasource realizzato tramite l’applicazione openspcoopSysconfig; per ulteriori dettagli è possibile leggere la documentazione dell’applicazione in doc/sysconfig.readme.
Nota
Per ulteriori informazioni su come utilizzare un datasource registrato con nome JNDI diverso dal default vedi Sezione 6.1.3.5.
Nota
L’applicazione openspcoopSysconfig, disponibile nella distribuzione in tools/sysconfig, permette di creare pool di risorse e registrarli nell’albero JNDI del proprio Application Server. La definizione dei pool deve essere fornita tramite un file xml che rispetti
lo schema in tools/sysconfig/src/schemi/sysconfig.xsd . Tutti i pool indicati nella guida utente/installazione e richiesti dai vari
prodotti rilasciati con la distribuzione di OpenSPCoop sono descritti in una configurazione di esempio dell’applicazione openspcoopSysconfig 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.
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-destinationsservice.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 istanziabili 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 sono
istanziabili 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 il
file 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 configurate
nell’applicazione.
6.1.2.4
Configurazione Iniziale
L’interfaccia web è preconfigurata per gestire un database interno 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. Per ulteriori dettagli su come
modificare 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 eventi. Verranno utilizzati i webservices di gestione/monitoraggio installati sulle singole Porte di dominio (vedi Sezione 6.3 e Sezione 6.4) , sul registro servizi (vedi Sezione 6.2) e l’interfaccia webservice CRUD del Gestore Eventi (vedi Sezione 7). Le
indicazioni 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
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
6.1.2.5
65 / 84
Deploy del Software
È 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).
Una volta effettuato il deploy, l’applicazione dovrebbe essere disponibile all’indirizzo:
• http://localhost:8080/pddConsole/login.do
Per effettuare il login di accesso è possibile utilizzare come login amministratore e come password secret. Una volta acceduti
all’interfaccia sarà possibile cambiare la password dell’amministratore.
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 personalizzare i log vedi Sezione 6.1.3.7.
Nota
I SQL utilizzati per l’installazione dell’interfaccia grafica hanno creato un utente amministratore 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 ). Accedendo con tale utente verranno visualizzate solo le informazioni utili per la gestione di servizi SPCoop
conformi al documento Sistema Pubblico di Cooperazione: Linee Guida all’uso della Busta EGov 1.1 . Se si desidera avere
una visualizzazione completa è possibile agire sulla tipologia dell’utente nella sezione Configurazione -> Utente -> Tipologia
Interfaccia.
6.1.3
Configurazione
L’interfaccia web è preconfigurata per gestire un database interno di tipo postgresql e propaga configurazioni remote verso le
porte di dominio gestite, verso un registro dei servizi e un Gestore Eventi. Il prodotto è tuttavia altamente configurabile agendo
sui file di proprietà presenti all’interno dell’archivio in pddConsole.war/WEB-INF/classes.
In questa sezione verrano descritti alcuni aspetti di configurazione avanzata riguardante:
• Gestione/Monitoraggio delle Porte di Dominio
• Gestione del Registro dei Servizi
• Gestione del Gestore Eventi
• Gestione del sistema di autorizzazione
• Accesso al DBMS
• Accesso al broker JMS
• Logging
• Personalizzazione dell’interfaccia
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’indirizzo 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 openspcoop/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. (Default
ip=127.0.0.1 e porta=80)
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
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 prefisso
http://ipgestione:portagestione/ e come suffisso quanto definito nella proprietà UrlWebServiceConfigurazione. Per default la url
utilizzata 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 utilizzando come prefisso http://ippubblico:portapubblica/ e come suffisso quanto definito nella proprietà UrlConnettoreSoggetto. Per
default 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 monitoraggio
tramite 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
Nota
Per 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).
Nota
Per 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 le
proprietà ServizioApplicativoGestoreEventi (default, nome_servizio_applicativo=ServizioApplicativoGestoreEventi).
Nota
Per 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 di
autorizzazione. Tale classe deve implementare l’interfaccia presente in tools/web_interfaces/control_station/src/org/openspcoop/web/ctr
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
67 / 84
Nota
Per la gestione del sistema di autorizzazione deve essere aggiunta una coda JMS come descritto in Sezione 6.1.3.6.
Nota
Non vengono fornite built-in in OpenSPCoop classi che implementano la configurazione del sistema di autorizzazione.
6.1.3.5
Accesso al DBMS
L’accesso al database dell’interfaccia web (vedi Sezione 6.1.2.1), viene definito tramite il file di configurazione datasource.properties dove viene indicato, tramite la voce dataSource, il 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/valore dove il nome viene preso al posto del carattere speciale *. (Default: dataSource=org.openspcoop.dataSource.pddConsole 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 gestiti
sono: postgresql/mysql/oracle (default: postgresql).
6.1.3.6
Accesso al broker JMS
L’accesso al broker JMS viene indicato, all’interno del file queue.properties, tramite la proprietà ConnectionFactory. Tale proprietà indica il nome jndi utilizzato dall’interfaccia web per accedere ad una connection factory registrata nell’albero JNDI
dell’A.S. Il pool permetterà di creare connessioni e effettuare lookup verso il broker JMS sul quale è presente la coda descritta
in Sezione 6.1.2.3. È possibile fornire informazioni di contesto per la ricerca delle risorse, attraverso una o più voci ConnectionFactory.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 attraverso la proprietà RegistroServiziQueue
• queue/NOMEPdD, code per la propagazione verso le porte di dominio OpenSPCoop; i nomi JNDI sono composti da un
prefisso comune definito tramite la proprietà PdDQueuePrefix e dal nome delle porte di dominio realmente configurate tramite
l’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 la
proprietà SmistatoreQueue
6.1.3.7
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 un
certo tipo. Ad ogni Category sono associabili uno o più Appender (log4j.appender.*, ad esempio log4j.appender.tracer.file) che
rappresentano una risorse su cui memorizzare i log. Le risorse utilizzabili tramite il framework sono svariate, da filesystem, a
database, 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.ctrlcore.
Per default tale category emette log sul file /var/openspcoop/log/ControlStationCore.log con verbosità DEBUG.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
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.DR
Per default tali categories emettono log, con verbosità DEBUG, rispettivamente sui file /var/openspcoop/log/DriverConfigurazioneDB.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 sul
file /var/openspcoop/log/AuditingControlStation.log con verbosità DEBUG.
• Informazioni sulla configurazione remota delle porte di dominio, l’interfaccia emette informazioni di debug, riguardanti lo
smistamento delle configurazioni verso le porte di dominio remote, tramite la category log4j.category.tracergestorepdd. Per
default 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 lo
smistamento delle configurazioni verso il registro dei servizi, tramite la category log4j.category.traceruddi. Per default tale
category 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 smistamento delle configurazioni verso il gestore eventi, tramite la category log4j.category.gestore_eventi. Per default tale category
emette 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 lo
smistamento delle configurazioni verso il sistema di autorizzazione, tramite la category log4j.category.tracerldap. Per default
tale 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 delle 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.
6.1.3.8
Personalizzazione dell’interfaccia
Le proprietà presenti nel file infoGeneral.cfg permettono di personalizzare l’interfaccia web. Di seguito vengono riportate tali
proprietà, catalogate funzionalmente:
• Package CNIPA, gli accordi di servizio parte comune e specifica e gli accordi di cooperazione possono essere importati/esportati
in package CNIPA (vedi Release Notes: Versione 1.3, Import/Export degli accordi nel registro dei servizi compatibili con
ClientSICA ).
Tale funzionalità è attiva nell’interfaccia se l’opzione IMPORTA_ESPORTA assume il valore true (Default: true, valori
possibili: true/false).
• Ciclo di vita degli accordi, l’interfaccia grafica del registro dei servizi permette agli utenti di gestire il ciclo di vita degli accordi
di 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, valori
possibili: true/false).
• Gestione accordi di servizio, nella versione 1.0 di OpenSPCoop un Accordo di Servizio poteva corrispondere ad un unico
PortType del WSDL del Servizio. Questo limite è stato superato nella versione 1.1, introducendo la gestione esplicita dei
PortType 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 WSDL
che 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 parte
comune. 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 definire
un soggetto referente ed una versione. Tale comportamente è modificabile tramite l’opzione backward_compatibility_1.1
(Default: false, valori possibili: true/false).
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
69 / 84
• Gestione correlazione asincrona, la correlazione tra la cooperazione asincrona di richiesta e quella di risposta può essere
specificata direttamente nell’accordo di servizio parte comune. L’accordo di servizio parte specifica viene automaticamente
gestito 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’opzione
accordi.showCorrelazioneAsincrona assume il valore true (Default: true, valori possibili: true/false).
• Gestione accordi di cooperazione, gli accordi di cooperazione e i servizi composti vengono gestiti dall’interfaccia web solo se
l’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 di
conversazione.
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 i
servizi. Tali endpoint possono essere semplici url http o connettori più complessi (es. JMS). L’interfaccia grafica è configurabile
per 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 deve
impostare 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 riguarda connettori e meccanismi di autenticazione/autorizzazione dei servizi applicativi. Questo poichè oltre alla possibilità di
selezionare un componente built-in, è permesso anche di indicarne uno creato e registrato dall’utente. Per ulteriori dettagli vedi
Sezione 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, valori
possibili: true/false).
• Terminologia degli Accordi di Servizio, la terminologia sugli accordi di servizio presente nelle interfacce grafiche è stata
adeguata ai documenti CNIPA, dalla versione 1.3. Per ulteriori dettagli vedi Release Notes: Versione 1.3, Miglioramenti
principali 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, AccordiServizioComposti e Adesioni
– openspcoop, i termini utilizzati saranno AccordiServizio, ServizioSPCoop, AccordiCooperazione, AccordiServizio + opzione composto e Fruitori
• generazioneAutomaticaPorteDelegate, all’aggiunta di una adesione in un accordo di servizio parte specifica, viene creata
automaticamente il componente di integrazione (PortaDelegata) necessario ad un servizio applicativo per poter effettivamente
fruire 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 non
devono essere configurabili tramite PddConsole. La proprietà org.openspcoop.pdd.server permette proprio di indicare quale
ambiente 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)
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
70 / 84
• pa.SPCoopProperties.valoriPredefiniti, la porta applicativa permette di configurare delle proprietà relative a informazioni SPCoop, che verranno utilizzate dalla Porta di Dominio per propagare le informazioni presenti nella busta eGov all’interno
dell’header di trasporto utilizzato per invocare un servizio applicativo (vedi Guida Utente XML: Configurazione PdD, SPCoop
Property ).
L’inserimento delle proprietà da parte dell’utente, può essere pilotato tramite un insieme di valori ammissibili o può essere
lasciato libero. Tale comportamento è configurato dalla proprietà pa.SPCoopProperties.valoriPredefiniti. (Default: true, valori
possibili: true/false).
• Pulsante Aggiungi nel menù dell’interfaccia, l’interfaccia è modificabile per poter far comparire o meno il punsante Aggiungi
direttamente all’interno delle sezioni del menù. Il pulsante viene visualizzato se la proprietà menu.visualizzazioneLinkAggiungi
assume il valore true (Default: false).
• Pulsante Aggiungi nell’elenco degli oggetti, l’interfaccia è modificabile per poter far comparire o meno il punsante Aggiungi all’interno dell’elenco degli oggetti gestiti dall’interfaccia. Il pulsante viene visualizzato se la proprietà elenchi.visualizzaPulsanteAggiun
assume il valore true (Default: true).
• Visualizzazione del numero di elementi di una lista, l’interfaccia è modificabile per poter far comparire o meno il totale degli
elementi 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 destinate
a 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).
• Visibilità utenti, un utente che ha i permessi di gestione dei servizi ’S’ (Release Notes: Versione 1.3, Introduzione dei
Permessi per l’accesso alle funzionalità delle console grafiche ) puo avere due tipologie di visibilità degli oggetti presenti
nell’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).
Nota
La proprietà singlePdD presente nel file infoGeneral.cfg non deve essere modificata. Tale proprietà indica all’interfaccia di
lavorare in una modalità di gestione centralizzata; se modificata l’interfaccia funzionerà in modalità di gestione locale delle Pdd
e del Registro dei Servizi descritto nella sezione Sezione 5.1
Nota
Le altre proprietà presenti nel file infoGeneral.cfg non vengono interpretate dalla versione della PddConsole descritta in questa
sezione; verrano utilizzate per la gestione locale delle Pdd e del Registro dei Servizi descritto nella sezione Sezione 5.1
6.2
6.2.1
Interfaccia WebService per la gestione CRUD del Registro dei Servizi
Compilazione dei sorgenti
I sorgenti dell’applicazione sono disponibili all’interno della distribuzione nella directory tools/ws/management/src. Per procedere 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 installabile
in un application server J2EE. L’archivio deve essere installato sulla macchina dove risiede il registro dei servizi da gestire.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
6.2.2
71 / 84
Installazione
I paragrafi di questa sezione descrivono come procedere con l’installazione dell’interfaccia web service utilizzabile per la configurazione di un registro dei servizi. Il web servizi può essere utilizzato per la configurazione di una qualsiasi tipologia di registro
dei servizi, ad esclusione della versione XML. Come prerequisito è quindi richiesta una installazione di una tipologia di registro
dei servizi descritta in Sezione 4
L’applicazione viene fornita sotto forma di archivio openspcoopRegistroServizi.war come risultato della compilazione dei sorgenti descritta in Sezione 6.2.1.
6.2.2.1
Configurazione Iniziale
L’interfaccia web service per la configurazione del Registro dei Servizi di OpenSPCoop è preconfigurata per gestire un registro
basato 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’interno
dell’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.
6.2.2.2
Deploy del Software
È sufficiente copiare il file dist/openspcoopRegistroServizi.war nella directory di deploy dell’application server: JBOSS_DIR/server/ISTA
(es. /var/lib/jbossas/server/default/deploy).
Una volta effettuato il deploy, l’applicazione dovrebbe essere disponibile all’indirizzo:
• http://localhost:8080/openspcoopRegistroServizi/Management
Per ottenere il WSDL dell’interfaccia web service è possibile utilizzare la seguente url:
• 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.
6.2.3
Configurazione
L’interfaccia web service per la configurazione del Registro dei Servizi di OpenSPCoop è preconfigurato per gestire un registro
su database di tipo postgresql. Il prodotto è tuttavia configurabile agendo sui file di proprietà presenti all’interno dell’archivio in
openspcoopRegistroServizi.war/WEB-INF/classes.
In questa sezione verrano descritti alcuni aspetti di configurazione avanzata riguardante:
• Tipologia del Registro dei Servizi
• Logging
6.2.3.1
Tipologia del Registro dei Servizi
L’applicazione web service si interfaccia per default ad un Registro dei Servizi DB di tipo postgresql. Se si vuole modificare
la tipologia del registro dei servizi si deve agire sul file di configurazione infoGeneralManagement.properties impostando le
proprietà factory e fileProperties relative alla tipologia desiderata. Il file di proprietà varia a seconda della tipologia di registro
dei servizi scelto:
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
72 / 84
• DB (registro basato su db, factory=org.openspcoop.dao.registry.driver.FactoryDriverRegistroServiziDBCreator e fileProperties=registroDB.properties), gli accordi di servizio sono mantenuti su un database relazionale; devono essere indicati il tipo di
database 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/valore
dove il nome viene preso al posto del carattere speciale *. (Default: dataSource=org.openspcoop.dataSource.regserv e
dataSource.property non definite).
• WEB (registro basato su Web, factory=org.openspcoop.dao.registry.driver.FactoryDriverRegistroServiziWEBCreator e fileProperties=registroWEB.properties), gli accordi di servizio sono mantenuti su un repository web accessibile tramite http; deve
essere 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 fileProperties=registroUDDI.properties), gli accordi di servizio sono mantenuti su un repository web accessibile tramite http e
indicizzati tramite un Registro UDDI; deve essere indicato come accedere all’area dati del repository web e come accedere al
registro 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 occupa
di creare gli oggetti sul registro. Tale utente viene definito dalla proprietà superUser all’interno del file iinfoGeneralManagement.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.
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 un
certo tipo. Ad ogni Category sono associabili uno o più Appender (log4j.appender.*, ad esempio log4j.appender.tracer.file) che
rappresentano una risorse su cui memorizzare i log. Le risorse utilizzabili tramite il framework sono svariate, da filesystem, a
database, ad e-mail etc...
Le category presenti riguardano le seguenti tipologie di log:
• 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
6.3.1
Interfaccia WebService per la gestione CRUD della configurazione di una PdD
Compilazione dei sorgenti
I sorgenti dell’applicazione sono disponibili all’interno della distribuzione nella directory tools/ws/management/src. Per procedere 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 installabile in un application server J2EE. L’archivio deve essere installato sulla macchina dove risiede la configurazione della porta di
dominio da gestire.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
6.3.2
73 / 84
Installazione
I paragrafi di questa sezione descrivono come procedere con l’installazione dell’interfaccia web service utilizzabile per la configurazione 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 dei
sorgenti descritta in Sezione 6.3.1.
6.3.2.1
Configurazione Iniziale
L’interfaccia web service per la configurazione di una porta di dominio OpenSPCoop è preconfigurata per gestire una configurazione 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’interno
dell’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 Sezione 6.3.3.1.
6.3.2.2
Deploy del Software
È sufficiente copiare il file dist/openspcoopConfigurazionePdD.war nella directory di deploy dell’application server: JBOSS_DIR/server/
(es. /var/lib/jbossas/server/default/deploy).
Una volta effettuato il deploy, l’applicazione dovrebbe essere disponibile all’indirizzo:
• http://localhost:8080/openspcoopConfigurazionePdD/Management
Per ottenere il WSDL dell’interfaccia web service è possibile utilizzare la seguente url:
• 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.
6.3.3
Configurazione
L’interfaccia web service per la configurazione di una porta di dominio OpenSPCoop è preconfigurata per gestire una configurazione su database di tipo postgresql. Il prodotto è tuttavia configurabile agendo sui file di proprietà presenti all’interno
dell’archivio in openspcoopConfigurazionePdD.war/WEB-INF/classes.
In questa sezione verrano descritti alcuni aspetti di configurazione avanzata riguardante:
• 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 tipologia si deve agire sul file di configurazione infoGeneralManagement.properties impostando le proprietà factory e fileProperties
relative 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 fileProperties=configDB.properties), i componenti di integrazione sono mantenuti su un database relazionale; devono essere indicati
il tipo di database e le informazioni per accedervi tramite le seguenti proprietà
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
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 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: dataSource=org.openspcoop.dataSource.pdd e
dataSource.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.
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 un
certo tipo. Ad ogni Category sono associabili uno o più Appender (log4j.appender.*, ad esempio log4j.appender.tracer.file) che
rappresentano una risorse su cui memorizzare i log. Le risorse utilizzabili tramite il framework sono svariate, da filesystem, a
database, ad e-mail etc...
Le category presenti riguardano le seguenti tipologie di log:
• 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 di
dominio (consulta il database descritto in Sezione 3.2.3), sia di visualizzare i messaggi diagnostici emessi dalla porta (vedi
Sezione 3.3.2.1).
6.4.1
Compilazione dei sorgenti
I sorgenti dell’applicazione sono disponibili all’interno della distribuzione nella directory tools/ws/monitor/src. Per procedere
con 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 un
application server J2EE. L’archivio deve essere installato sulla macchina dove risiede la porta di dominio da tenere sotto
monitoraggio.
6.4.2
Installazione
I paragrafi di questa sezione descrivono come procedere con l’installazione dell’interfaccia web service utilizzabile per il monitoraggio di una porta di dominio. Come prerequisito è quindi richiesta una installazione di una porta di dominio; il web service
si interfaccia verso il database dei messaggi Sezione 3.2.3 e verso il database utilizzato per la raccolta dei messaggi diagnostici
Sezione 3.3.2.1.
L’applicazione viene fornita sotto forma di archivio openspcoopMonitor.war come risultato della compilazione dei sorgenti
descritta in Sezione 6.4.1.
6.4.2.1
Configurazione Iniziale
L’interfaccia web service per il monitoraggio di una porta di dominio OpenSPCoop è preconfigurata per monitorare un database
di 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/WE
INF/classes (vedi Sezione 6.4.3.1 e Sezione 6.4.3.2.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
6.4.2.2
75 / 84
Deploy del Software
È sufficiente copiare il file dist/openspcoopMonitor.war nella directory di deploy dell’application server: JBOSS_DIR/server/ISTANZA/d
(es. /var/lib/jbossas/server/default/deploy).
Una volta effettuato il deploy, l’applicazione dovrebbe essere disponibile all’indirizzo:
• http://localhost:8080/openspcoopMonitor/Monitor
Per ottenere il WSDL dell’interfaccia web service è possibile utilizzare la seguente url:
• http://localhost:8080/openspcoopMonitor/Monitor?wsdl
L’applicazione produce dei log che registrano le operazioni effettuate nel file /var/openspcoop/log/WSMonitorCore.log. Per
ulteriori informazioni su come personalizzare i log vedi Sezione 6.4.3.3.
6.4.3
Configurazione
L’interfaccia web service per il monitoraggio di una porta di dominio OpenSPCoop è preconfigurata per gestire un repository dei
messaggi di tipo postgresql. Il prodotto è tuttavia configurabile agendo sui file di proprietà presenti all’interno dell’archivio in
openspcoopMonitor.war/WEB-INF/classes.
In questa sezione verrano descritti alcuni aspetti di configurazione avanzata riguardante:
• 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 file 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 del
dataSource, attraverso una o più voci org.openspcoop.monitor.dataSource.openspcoop.property.*, tramite la definizione di coppie nome/valore dove il nome viene preso al posto del carattere speciale *. (Default: dataSource=org.openspcoop.dataSource e
dataSource.property non definite).
Il tipo di database viene indicato tramite la voce org.openspcoop.monitor.dataSource.openspcoop.tipoDatabase. I tipi di database
gestiti 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 di
configurazione 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 del
dataSource, attraverso una o più voci org.openspcoop.monitor.dataSource.msgdiagnostici.property.*, tramite la definizione di
coppie nome/valore dove il nome viene preso al posto del carattere speciale *. (Default: dataSource=org.openspcoop.dataSource.msgDiag
e dataSource.property non definite).
Il tipo di database viene indicato tramite la voce org.openspcoop.monitor.dataSource.msgdiagnostici.tipoDatabase. I tipi di
database gestiti sono: postgresql/mysql/oracle (default: postgresql).
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
6.4.3.3
76 / 84
Logging
L’interfaccia web è configurabile, per quanto riguarda le funzionalità di logging, tramite il file tracerMonitor.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 un
certo tipo. Ad ogni Category sono associabili uno o più Appender (log4j.appender.*, ad esempio log4j.appender.tracer.file) che
rappresentano una risorse su cui memorizzare i log. Le risorse utilizzabili tramite il framework sono svariate, da filesystem, a
database, ad e-mail etc...
Le category presenti riguardano le seguenti tipologie di log:
• 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’accesso al database dei messaggi della porta di dominio, tramite la category log4j.category.DRIVER_DB_MONITORAGGIO. Per
default 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 database
contenente i diagnostici emessi dalla porta di dominio, tramite la category log4j.category.DRIVER_DB_LOGANALIZER. Per
default 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 scambio
di 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 di
vista, il Gestore Eventi può essere considerato un normale servizio SPCoop, con una sua logica applicativa che consiste appunto
nel coordinare, secondo una logica EDA, richiedenti e fruitori dei servizi SPCoop. Per ulteriori dettagli è possibile consultare il
documento 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
Nota
Non è 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 procedere 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 application server J2EE.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
7.1.2
77 / 84
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 seguente
comando:
ant clean build
La compilazione produce come risultato un archivio ge.war all’interno della directory dist installabile in un application server
J2EE.
7.2
Installazione
I paragrafi di questa sezione descrivono come procedere con l’installazione dell’applicazione GestoreEventi e dell’interfaccia
web 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 il
risultato 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 per
la 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.
Nota
L’interfaccia deve possedere i diritti per leggere ed inserire elementi nelle tabelle.
A titolo esemplificativo, vengono elencati i passi di configurazione da effettuare per la configurazione del Database PostgreSQL
su sistema operativo Linux.
1. Creazione Utente
[user@localhost]$ su
Parola d’ordine: XXX
[root@localhost]# su - postgres
-bash-3.1$ createuser -P
Enter name of role to add: ge
Enter password for new role: ge
Conferma password: ge
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n
CREATE ROLE
2. Crezione Database
[user@localhost]$ su
Parola d’ordine: XXX
[root@localhost]# su - postgres
-bash-3.1$createdb -O ge ge
CREATE 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:
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
78 / 84
local ge ge md5
host ge ge 127.0.0.1 255.255.255.255 md5
4. Creazione tabelle SQL
[user@localhost]$ psql ge ge < tools/web_interfaces/ge/deploy/sql/TIPO_DATABASE/ ←GestoreEventi.sql
Password for user ge: ge
5. Fornire infine all’application server il driver JDBC del DB utilizzato. Ad es. per l’A.S. JBoss copiare l’apposito jar nella
cartella JBOSS/server/default/lib.
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.dataSo
Un datasource di esempio per l’application server JBoss viene fornito in tools/web_interfaces/ge/deploy/datasource/jboss/gestoreeventids.xml. Il file permette di creare la risorsa nella propria installazione dell’A.S., attraverso la configurazione e la successiva copia
del file in JBOSS_DIR/server/default/deploy.
In alternativa, per l’application server JBoss, è possibile utilizzare un datasource realizzato tramite l’applicazione openspcoopSysconfig; per ulteriori dettagli è possibile leggere la documentazione dell’applicazione in doc/sysconfig.readme.
Nota
Per ulteriori informazioni su come utilizzare un datasource registrato con nome JNDI diverso dal default è possibile consultare
i paragrafi Sezione 7.3.1.1 e Sezione 7.3.2.1.
Nota
L’applicazione openspcoopSysconfig, disponibile nella distribuzione in tools/sysconfig, permette di creare pool di risorse e registrarli nell’albero JNDI del proprio Application Server. La definizione dei pool deve essere fornita tramite un file xml che rispetti
lo schema in tools/sysconfig/src/schemi/sysconfig.xsd . Tutti i pool indicati nella guida utente/installazione e richiesti dai vari
prodotti rilasciati con la distribuzione di OpenSPCoop sono descritti in una configurazione di esempio dell’applicazione openspcoopSysconfig 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.
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 vengono
fornite 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 attraverso
la 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.x
attraverso 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 GestoreEventi.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.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
7.2.5
79 / 84
Deploy del Software GestoreEventi
L’applicazione GestoreEventi GestoreEventi.ear deve essere copiata nella directory di deploy dell’application server: JBOSS_DIR/server
(es. /var/lib/jbossas/server/default/deploy).
Una volta effettuato il deploy, l’applicazione GestoreEventi fornisce tre servizi, rispettivamente per la pubblicazione/prelevamento di messaggi, per la gestione della configurazione, ed un esempio di webService utilizzato per la ricezione delle notifiche da
parte 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 ulteriori
informazioni 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/deplo
(es. /var/lib/jbossas/server/default/deploy).
Una volta effettuato il deploy dovrebbe essere possibile accedervi all’indirizzo:
• http://localhost:8080/ge/login.do
Per effettuare il login di accesso è possibile utilizzare come login amministratore e come password secret. Una volta acceduti
all’interfaccia sarà possibile cambiare la password dell’amministratore.
L’applicazione produce dei log che registrano le operazioni effettuate nel file /var/openspcoop/log/InterfacciaGE.log. Per
ulteriori 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 nel
documento 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 dalla
PdD;
• 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 possono
essere create anche tramite le altre tipologie della configurazione della PdD e del registro dei servizi descritte in Sezione 3.2.5 e
Sezione 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 Il
Gestore Eventi di OpenSPCoop
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
7.2.7.1
80 / 84
Configurazione del Registro dei Servizi
Di seguito viene mostrato un frammento di registro dei servizi, di tipologia xml, necessario per il corretto funzionamento del
Gestore Eventi.
<!-- Accordo di Servizio per l’accesso a Messaggi Notificati -->
<accordo-servizio nome="ASGetMessaggioNotificato" profilo-collaborazione="sincrono"
utilizzo-senza-azione="true" />
←-
←-
<!-- Aggiungere qui gli accordi di servizio dei servizi da gestire come pubblicazione di
eventi -->
...
<!-- Soggetto che esporta i servizi di Gestione Eventi, non necessariamente un Soggetto
dedicato -->
<soggetto-spcoop tipo="SPC" nome="GestoreEventi">
←-
<connettore tipo="http" nome="PdDGestoreEventi">
<property nome="location" valore="http://localhost:8080/openspcoop/PA" />
</connettore>
<!-- Servizio di Get evento Notificato -->
<servizio tipo="SPC" nome="GetMessaggioNotificato" accordo-servizio=" ←ASGetMessaggioNotificato"/>
<!-- Aggiungere qui l’erogazione dei vari servizi da gestire come pubblicazione di eventi ←-->
...
</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 corretto
funzionamento del Gestore Eventi.
<soggetto-spcoop tipo="SPC" nome="GestoreEventi" >
<!-- Servizio Applicativo GestoreEventiWS -->
<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 Gestore Messaggi Notificati -->
<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>
←-
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
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 ConsegnaEventi -->
<servizio-applicativo nome="ConsegnaEventi" >
<invocazione-porta invio-per-riferimento="abilitato">
<credenziali tipo="basic" user="consegnatoreEventi" password="123456" />
</invocazione-porta>
</servizio-applicativo>
<!-- Servizio Applicativo NotificatoreEventi -->
<servizio-applicativo nome="NotificatoreEventi" >
<invocazione-porta>
<credenziali tipo="basic" user="notificatoreEventi" password="123456" />
</invocazione-porta>
</servizio-applicativo>
<!-- Consegna Evento -->
<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>
<!-- Notifica Evento -->
<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>
<!-- Pubblicazione Evento -->
<porta-applicativa nome="PubblicaEvento">
<servizio tipo="SPC" nome="PubblicazioneEvento" />
<servizio-applicativo nome="GestoreEventiWS" />
</porta-applicativa>
<!-- Get Evento precedentemente Notificato -->
<porta-applicativa nome="GetMsgNotificato">
<servizio tipo="SPC" nome="GetMessaggioNotificato" />
<servizio-applicativo nome="GestoreMessaggiNotificati" />
</porta-applicativa>
</soggetto-spcoop>
7.3
7.3.1
Configurazione
Configurazione del Gestore Eventi
Il GestoreEventi è preconfigurata per gestire un database di tipo postgresql. Il prodotto è tuttavia altamente configurabile agendo
sui file di proprietà presenti all’interno dell’archivio in GestoreEventi.ear/properties.
In questa sezione verrano descritti alcuni aspetti di configurazione avanzata riguardante:
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
82 / 84
• Accesso al DBMS
• Accesso al broker JMS
• Logging
• Personalizzazione dell’applicazione
7.3.1.1
Accesso al DBMS
L’accesso al database (vedi Sezione 7.2.1), viene definito tramite il file di configurazione GestoreEventi.properties dove viene
indicato, tramite la voce org.openspcoop.gestoreeventi.datasource, il 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 org.openspcoop.gestoreeventi.da
tramite la definizione di coppie nome/valore dove il nome viene preso al posto del carattere speciale *. (Default: dataSource=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).
7.3.1.2
Accesso al broker JMS
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 web
per accedere ad una connection factory registrata nell’albero JNDI dell’A.S. Il pool permetterà di creare connessioni e effettuare
lookup verso il broker JMS sul quale sono presenti la coda descritte in Sezione 7.2.3. È possibile fornire informazioni di
contesto per la ricerca delle risorse, attraverso una o più voci org.openspcoop.gestoreeventi.connectionFactory.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 vengono indicate tramite le proprietà org.openspcoop.gestoreeventi.consegnaEventiQueue e org.openspcoop
È possibile fornire informazioni di contesto per la ricerca delle code attraverso una o più voci org.openspcoop.gestoreeventi.queue.propert
tramite la definizione di coppie nome/valore come viene fatto per la ConnectionFactory. (Default: consegnaEventiQueue=queue/Consegn
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 sistema di log utilizza il framework Apache Log4J .
Il file contiene delle Category (log4j.category.*) che rappresentano un Logger utilizzato dal GestoreEventi per emettere log di un
certo tipo. Ad ogni Category sono associabili uno o più Appender (log4j.appender.*, ad esempio log4j.appender.tracer.file) che
rappresentano una risorse su cui memorizzare i log. Le risorse utilizzabili tramite il framework sono svariate, da filesystem, a
database, 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.openspcoop.gestor
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 category log4j.category.openspcoop.gestoreeventi.consegna. Per default tale category emette log sul file /var/openspcoop/log/gestoreEventiMDBConsegna.log con verbosità DEBUG.
• Informazioni di notifica di un evento, l’interfaccia emette informazioni riguardanti la notifica di un evento tramite la category
log4j.category.openspcoop.gestoreeventi.notifica. Per default tale category emette log sul file /var/openspcoop/log/gestoreEventiMDBNotifica.log con verbosità DEBUG.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
83 / 84
• Informazioni di verifica della consistenza del repository degli eventi, l’interfaccia emette informazioni riguardanti la verifica
della consistenza del repository degli eventi, effettuata da un componente schedulato ad intervalli regolari, tramite la category
log4j.category.openspcoop.gestoreeventi.timerMsgEvasi. Per default tale category emette log sul file /var/openspcoop/log/gestoreEventiWSNotifica.log con verbosità DEBUG.
• Informazioni emesse dall’esempio di webService utilizzato per la ricezione delle notifiche, l’interfaccia emette tali informazioni 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. Di
seguito 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 Gestore
Eventi. (Default: url=http://localhost:8080/openspcoop)
Tramite le proprietà org.openspcoop.gestoreeventi.consegna.* vengono indicati i parametri di consegna di un evento quali la
porta 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 la
porta 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 del
servizio applicativo che impersonifica l’applicazione Gestore Eventi nella porta di dominio. (Default: user=gestoreEventi e
password=123456). Vedi Sezione 7.2.7.
• Scadenza Eventi
La proprietà org.openspcoop.gestoreeventi.scadenzaMessaggiDefault, indica l’intervallo di validità di un evento in minuti.
Nota
L’intervallo di scadenza di un messaggio pubblicato deve essere minore dell’intervallo di scadenza dei messaggi gestiti dalla Porta di Dominio OpenSPCoop posta davanti all’applicazione GestoreEventi (vedi proprietà 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’architettura dell’applicazione per gestire gli eventi scaduti. È possibile fornire informazioni di contesto per la ricerca nell’albero
JNDI, attraverso una o più voci org.openspcoop.gestoreeventi.ejb.property.*, tramite la definizione di coppie nome/valore dove
il nome viene preso al posto del carattere speciale *. (Default: timerMsgEvasiScaduti=ejb/MessaggiEvasiEJB e ejb.property
non definite);
L’intervallo di tempo, in minuti, con cui viene eseguito il timer è definito dalla proprietà org.openspcoop.gestoreeventi.timeoutMsgEvas
(Default timeoutMsgEvasiScaduti=1).
• BeanCore del GestoreEventi
Le funzionalità implementate dal GestoreEventi sono tutte disponibili tramite un EJB Bean. La proprietà org.openspcoop.gestoreeventi
indica il nome jndi di EJB di tale bean. È possibile fornire informazioni di contesto per la ricerca nell’albero JNDI, attraverso
una o più voci org.openspcoop.gestoreeventi.ejb.property.*, tramite la definizione di coppie nome/valore dove il nome viene
preso al posto del carattere speciale *. (Default: beanCore=ejb/GestoreEventiEJB e ejb.property non definite);
Nota
Il file di proprietà CodiciErrore.properties contiene i codici di errore generati dal Gestore Eventi.
Guida Installazione della distribuzione
sorgente di OpenSPCoop 1.4
7.3.2
84 / 84
Configurazione dell’interfaccia web di gestione
L’interfaccia di gestione del GestoreEventi è preconfigurata per gestire un database di tipo postgresql. Il prodotto è tuttavia
altamente configurabile agendo sui file di proprietà presenti all’interno dell’archivio in ge.war/WEB-INF/classes.
In questa sezione verrano descritti alcuni aspetti di configurazione avanzata riguardante:
• Accesso al DBMS
• Logging
• Personalizzazione dell’interfaccia
7.3.2.1
Accesso al DBMS
L’accesso al database (vedi Sezione 7.2.1), viene definito tramite il file di configurazione datasource.properties dove viene
indicato, tramite la voce dataSource, il 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/valore dove il nome viene preso al posto del carattere speciale *. (Default: dataSource=org.openspcoop.dataSource.ge 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 gestiti
sono: postgresql/mysql/oracle (default: postgresql).
7.3.2.2
Logging
L’interfaccia web del GestoreEventi è 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 un
certo tipo. Ad ogni Category sono associabili uno o più Appender (log4j.appender.*, ad esempio log4j.appender.tracer.file) che
rappresentano una risorse su cui memorizzare i log. Le risorse utilizzabili tramite il framework sono svariate, da filesystem, a
database, 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.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 sul
file /var/openspcoop/log/AuditingGE.log con verbosità DEBUG.
7.3.2.3
Personalizzazione dell’interfaccia
Le proprietà presenti nel file infoGeneral.cfg permettono di personalizzare l’interfaccia web. Di seguito vengono riportate tali
proprietà, catalogate funzionalmente:
• Pulsante Aggiungi nel menù dell’interfaccia, l’interfaccia è modificabile per poter far comparire o meno il punsante Aggiungi
direttamente all’interno delle sezioni del menù. Il pulsante viene visualizzato se la proprietà menu.visualizzazioneLinkAggiungi
assume il valore true (Default: false).
• Pulsante Aggiungi nell’elenco degli oggetti, l’interfaccia è modificabile per poter far comparire o meno il punsante Aggiungi all’interno dell’elenco degli oggetti gestiti dall’interfaccia. Il pulsante viene visualizzato se la proprietà elenchi.visualizzaPulsanteAggiun
assume il valore true (Default: true).