README.md

# SIMEL2

Sistema Informativo Multicanale Enti locali 2

Il Sistema Informativo Multicanale Enti Locali 2 (SIMEL2) è una soluzione per l'erogazione di servizi comunali, integrata in logica ERP in una banca dati unica.

SIMEL2 ha un sistema di gestione del workflow che consente di controllare e gestire il flusso dei processi amministrativi e decisionali automatizzando il passaggio di competenze tra i vari uffici coinvolti nell'iter amministrativo di un procedimento. Tale sistema, associato ad una preventiva analisi di razionalizzazione ed ottimizzazione delle attività, risponde alla primaria esigenza di efficacia, efficienza ed economicità dell'azione amministrativa, distribuendo in maniera tempestiva ed automatica i compiti affidati alle strutture organizzative presenti nell'Ente.

L'ERP, inoltre, si compone di più moduli applicativi, tra i quali: servizi demografici, per supportare gli operatori con l'automazione delle operazioni e con un flusso di comunicazioni che si propaga da un'area applicativa all'altra; protocollo, che, oltre alle funzioni base di registrazione della corrispondenza in ingresso e in uscita, predispone il sistema all'interoperabilità tra differenti sistemi di protocollo delle pubbliche amministrazioni; gestione documentale, certificazioni, posta certificata, SUAP, SUE e Tributi.

# Struttura del repository

La struttura del repository è articolata in un unico branch avente le seguenti directories:

- Struttura database
- ambiente\_svil\_prod
- jar\_html
- jar\_std
- simel2\_home
- src\_html
- src\_std




# Note sviluppo

Il modulo "infra-app", del quale non vengono forniti i sorgenti ma solo le librerie compilate, è costituito dai seguenti moduli:

- it.saga.library.authentication
- it.saga.library.baseForms
- it.saga.library.common
- it.saga.library.commonDataTypes
- it.saga.library.ddl
- it.saga.library.repository
- it.saga.library.search
- it.saga.library.workflow

Seguendo il manuale di prima installazione utilizzare il file contenente la chiave del comune di prova: prova.txt

Inserire il banner dell'ente nel repository e cambiare, nel file sicraweb.server.config, il riferimento a questo.

In questo modo si può avere una prima installazione funzionante in modalità "demo".

Per poter produrre in autonomia chiavi di attivazione, è necessario predisporre un'installazione in modalità sviluppatore. Per farlo occorre seguire i seguenti passi:

rimuovere tutti i jar dalle seguenti directory:

- lanciare tool sicraweb\_home/tools/swcc.bat e, dalla scheda "Tools", premere il tasto "cancella jars in JBoss";
- sicraweb\_home/client;
- sicraweb\_home/server;
- sicraweb\_home/setup/apps;
- sicraweb\_home/setup/jdbc;
- sicraweb\_home/setup/jdbc4;

Prendere i jar contenuti nella simel2\_home e metterli nella sicraweb\_home

Compilare il progetto it.saga.library.activation.encode facendo in modo che l'artefatto risultante finisca nella sicraweb\_home/server (Questa operazione è indispensabile solamente per le installazioni che devono produrre chiavi di attivazione).

Procedere con i passi previsti dal setup utilizzando swcc e non swca.

Entrare in Simel2 e produrre la chiave di attivazione per un'altra installazione che si intende predisporre.

Procedere quindi alla configurazione di una nuova installazione (da DB vuoto) rimuovendo i jar come indicato in precedenza e utilizzando la libreria it.saga.library.activation ricompilata che sarà in grado di recepire la chiave di attivazione prodotta in autonomia.

Per compilare ogni singola libreria è necessario utilizzare Maven nella versione 3.x.

Ogni libreria può produrre gli artefatti corrispondenti utilizzando il comando: mvn clean install

Le dipendenze richieste possono essere risolte andando a specificare la direttiva "system" oppure caricando le librerie incluse nella distribuzione (jar\_std e jar\_html) su un repository maven.

Per caricare queste librerie nel repository locale utilizzare il comando:

mvn install

Per caricarle su un repository remoto utilizzare il comando:

mvn deploy:deploy-file

In entrambi i casi è necessario specificare i parametri che permettano di creare sul repository l'artefatto con group-id, artifact-id, ecc.. come si aspetta la libreria.

Il file settings.xml allegato può essere utilizzato al fine di configurare la postazione locale per dialogare con un repository remoto Maven.

**Struttura dei POM**

I POM per l'applicativo Simel2 sono organizzati in forma gerarchica. Ogni POM eredita le caratteristiche dei progenitori, che può sovrascrivere (entro certi limiti) ed imposta le proprie.

**maggioli base**

Contiene le impostazion aziendali, valide anche per applicativi diversi da simel2, quali:

posizione dei repository di release e snapshot

definizione e configurazione di plugin utilizzati a livello di gruppo

**sicraweb-produzione-base**

E' il POM che, nella terminologia corrente, è definito nonno. Il termine deriva dalla gerarchia inizialmente adottata, a tre livelli, di cui questo era il primo Contiene le informazioni a livello di suite Simel2, in particolare:

codifica il contenuto della Simel2 di produzione

contiene il codice che crea i file Manifest nel formato proprietario

contiene il codice che risolve le dipendenze circolari fra pacchetti

contiene le regole di build valide per l'intera suite, ad esempio il JDK da utilizzare



La parte significativa del POM e' la codifica del contenuto della simel2, che avviene in due fasi:

Nella parte iniziale del POM sono definite le versioni degli applicativi in uso nella simel2 di produzione:

\<properties\>

    \<sicraweb.version\>2012.02.28.171325\</sicraweb.version\>

    \<it.saga.pubblici.statocivile.extra.version\>1.0.61.0000\</it.saga.pubblici.statocivile.extra.version\>

    \<it.saga.pubblici.ici.reports.version\>1.3.55.0002\</it.saga.pubblici.ici.reports.version\>

    \<it.saga.pubblici.anagrafe.version\>1.3.31.0002\</it.saga.pubblici.anagrafe.version\>

    ...

\</properties\>

sicraweb.version è la data di generazione del POM, le altre properties codificano in maniera algoritmica le versioni dei vari applicativi presenti nella sicraweb di produzione.

Queste informazioni sono utilizzate più avanti per fattorizzare le versioni degli artefatti presenti nella sicraweb, come si vede dal seguente frammento:

   \<dependency\>

       \<groupId\>it.saga.pubblici\</groupId\>

       \<artifactId\>anagrafe-server\</artifactId\>

       \<version\>${it.saga.pubblici.anagrafe.version}\</version\>

   \</dependency\>

   \<dependency\>

       \<groupId\>it.saga.pubblici\</groupId\>

       \<artifactId\>anagrafe-core\</artifactId\>

       \<version\>${it.saga.pubblici.anagrafe.version}\</version\>

   \</dependency\>

**POM singolo applicativo**

Sempre in riferimento alla prima versione dei POM, è chiamato a volte padre

E' versionato nella cartella radice del progetto cui si riferisce

Contiene le caratteristiche del singolo applicativo (anagrafe, workflow, finanziaria, ...) in particolare

versione

indirizzo svn da utilizzare per le operazioni

eventuali versioni di altre applicazioni necessarie al funzionamento dell'applicativo in oggetto, che sovrascrivono quelle dichiarate nel nonno

Il POM applicativo dichiara inoltre due moduli, uno contenente tutti i sottomoduli client (menu, core, admin, ...) ed uno contenente tutti i sottomoduli server (server, setup, ...). Se XYZ e' la tripletta che identifica l'applicazione (es: ANA, STC, ...) i due moduli si chiameranno XYZ-client e XYZ-server

**POM intermedio**

Raggruppa tutti gli artefatti (==jar) lato client o lato server

Contiene

la dichiarazione di tutti i sottomoduli lato client o server

le dipendenze di tutti questi sottomoduli (in pratica il modulo client e quelllo admin, ad esempio, condividono le dipendenze)

Le dipendenze sono codificate nella forma

   \<dependency\>

       \<groupId\>it.saga.library\</groupId\>

       \<artifactId\>check-version-client\</artifactId\>

   \</dependency\>

manca cioè la versione esplicita della libreria check-version-client. La cosa è voluta, essendo la versione ereditata dal nonno (o dal padre se, come vedremo in seguito, ne facciamo l'overload). In questo modo non dobbiamo modificare questi pom quando viene aggiornata la libreria check-version-client

Fanno eccezione le dipendenze fra elementi appartenenti allo stesso progetto. Ad esempio, nel POM CMN-server troverò la dipendenza dal client codificata nella forma

   \<dependency\>

       \<groupId\>it.saga.library\</groupId\>

       \<artifactId\>common-client\</artifactId\>

       \<version\>${project.version}\</version\>

   \</dependency\>

La sintassi usata per specificare la versione è usata per TUTTE le dipendenze fra jar della stessa apllicazione, e garantisce che l'applicazione venga sempre compilata rispetto ai jar della stessa versione **(cioè eviteremo** ad esempio di compilare common-server 1.0.60 usando la dipendenza common-client 1.0.59, importata transitivamente da un altro progetto)

**POM figlio**

Genera fisicamente un jar (client, server, setup, ...) Contiene

le regole per il deploy nella sicraweb dell'artefatto generato

alcune dipendenze ad hoc (o cartelle di sorgenti extra) usate per risolvere le dipendenze circolari fra progetti

eventuali risorse o profili extra

**Operazioni comuni con i POM**

Indichiamo di seguito come svolgere alcune operazioni abbastanza comuni con i propri POM di progetto.

**Sincronizzare il proprio applicativo con la Simel2 di riferimento**

Quando vengono rilasciate nuove versioni degli applicativi, cambia la simel2 di produzione ed occorre far puntare il POM padre al nuovo POM nonno che la descrive. Il POM nonno è generato dal personale addetto ai test, per aggiornare il proprio POM occorre seguire le istruzioni di sincronizzazione

E' importante mantenere sincronizzato il proprio POM con quello che descrive la simel2, per non compilare il proprio progetto rispetto a versioni datate degli altri applicativi, l'ideale sarebbe effettuare la sincronizzazione ad ogni aggiornamento della Simel2 di produzione.

**Utilizzare versioni più avanzate di dipendenze rispetto a quelle specificate nella simel2 di riferimento**

Si presenta a volte la necessità di compilare la propria applicazione rispetto ad una dipendenza non ancora rilasciata. In questo caso è sufficiente inserire nel padre la property con la versione di libreria da utilizzare, nello stesso formato usato nel nonno.

Così facendo sovrascriviamo la versione usata da maven come dipendenza.

Quando la cosa non sarà più necessaria, ad esempio perchè la dipendenza in questione viene rilasciata, elimineremo la riga dal POM

**Esempio**

Supponiamo che nel POM nonno sia presente elettorale, alla versione 2.1.63.0000. Ciò si traduce nella presenza delle seguenti righe nel POM sicraweb-produzione-base:

\<properties\>

   \<it.saga.pubblici.elettorale.version\>2.1.63.0000\</it.saga.pubblici.elettorale.version\>

   ...

\</properties\>

Se ho bisogno di usare la 66, non ancora rilasciata, inserisco nel padre la property con la versione corretta:

\<properties\>

   \<it.saga.pubblici.elettorale.version\>2.1.66.0000\</it.saga.pubblici.elettorale.version\>

   ...

\</properties\>

che fa l'overload del numero di versione.

Quando verrà rilasciata la 66 (o maggiore) toglieremo la riga dal POM (in futuro l'eliminazione della riga dal POM sarà automatica, al momento della sincronizzazione col nonno verranno eliminate le dipendenze non più necessarie)

**Introdurre nuove dipendenze nella propria applicazione**

Se devo aggiungere delle dipendenze alla mia applicazione, le inserisco nei pom XXX-server ed XXX-client: nel primo metterò tutte le dipendenze che interessano moduli lato server, nel secondo quelle lato client.

Non si deve indicare il numero di versione, che viene ereditato dal nonno, come già spiegato nella sezione relativa ai pom intermedi

**Compilare il progetto da linea di comando**

La compilazione del codice a riga di comando è utile per verificare che tutta la catena maven sia correttamente configurata, che il settings.xml sia a posto, che il jdk sia installato bene. La compilazione produce gli stessi jar prodotti nell'ambiente jdev

Per compilare a linea di comando, aprire una shell nella cartella radice del progetto (quella che contiene la cartella src) e lanciare il comando

mvn clean install

Se tutto va bene i sorgenti vengono compilati, ed in ogni sottoprogetto figlio troveremo una cartella target contenente il jar pronto per l'uso

**File settings.xml**

Contiene le impostazioni relative all'utente ed alla postazione di lavoro in uso. In particolare, vi sono configurati

il repository aziendale, od il suo mirror

i profili maven di uso comune

alcune properties specifiche della postazione di lavoro, ad esempio la posizione della sicraweb e del jdk.

# Librerie commerciali

Simel2 utilizza le seguenti librerie commerciali per le quali occorre dotarsi, in sviluppo, di opportuna licenza:

* **Aspose cells, words e pdf.**

La licenza di queste libreria va inserita in questa classe: it.saga.library.documentiCollegati\src\DOC-client\client\src\main\java\it\saga\library\gestioneDocumentale\javaProcessor\DocAsposeSetup.java

* **JxBrowser**

La licenza di questa libreria va inserita all'interno del jar jxbrowser-6.22.2.0000.jar, in particolare qui: META-INF\teamdev.licenses

* **KendoUI**

Queste librerie non prevedono una chiave di attivazione.

---
* **Status del progetto** : Stabile

* **Ente proprietario (diritti Copyright)**: Comune di Salerno

* **Soggetto incaricato del mantenimento del software** : Maggioli

* **Indirizzo mail per le segnalazioni di sicurezza:** [sistemiinformativi@comune.salerno.it](mailto:sistemiinformativi@comune.salerno.it)