Add README.md

7a7215e6 · Administrator · f4a0e9ea · 7a7215e6
Commit 7a7215e6 authored Jan 10, 2020 by Administrator
Hide whitespace changes
Inline Side-by-side

Showing with 307 additions and 0 deletions

README.md README.md +307 -0

No files found.
--- a/README.md
+++ b/README.md
+# SIMEL2
+
+Sistema Informativo Multicanale Enti locali 2
+
+Il Sistema Informativo Multicanale Enti Locali 2 (SIMEL2) è una soluzione per l&#39;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&#39;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&#39;azione amministrativa, distribuendo in maniera tempestiva ed automatica i compiti affidati alle strutture organizzative presenti nell&#39;Ente.
+
+L&#39;ERP, inoltre, si compone di più moduli applicativi, tra i quali: servizi demografici, per supportare gli operatori con l&#39;automazione delle operazioni e con un flusso di comunicazioni che si propaga da un&#39;area applicativa all&#39;altra; protocollo, che, oltre alle funzioni base di registrazione della corrispondenza in ingresso e in uscita, predispone il sistema all&#39;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 &quot;infra-app&quot;, 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&#39;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à &quot;demo&quot;.
+
+Per poter produrre in autonomia chiavi di attivazione, è necessario predisporre un&#39;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 &quot;Tools&quot;, premere il tasto &quot;cancella jars in JBoss&quot;;
+- 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&#39;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&#39;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 &quot;system&quot; 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&#39;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&#39;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&#39; 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&#39;intera suite, ad esempio il JDK da utilizzare
+
+
+
+La parte significativa del POM e&#39; 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:
+
+\&lt;properties\&gt;
+
+    \&lt;sicraweb.version\&gt;2012.02.28.171325\&lt;/sicraweb.version\&gt;
+
+    \&lt;it.saga.pubblici.statocivile.extra.version\&gt;1.0.61.0000\&lt;/it.saga.pubblici.statocivile.extra.version\&gt;
+
+    \&lt;it.saga.pubblici.ici.reports.version\&gt;1.3.55.0002\&lt;/it.saga.pubblici.ici.reports.version\&gt;
+
+    \&lt;it.saga.pubblici.anagrafe.version\&gt;1.3.31.0002\&lt;/it.saga.pubblici.anagrafe.version\&gt;
+
+    ...
+
+\&lt;/properties\&gt;
+
+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:
+
+   \&lt;dependency\&gt;
+
+       \&lt;groupId\&gt;it.saga.pubblici\&lt;/groupId\&gt;
+
+       \&lt;artifactId\&gt;anagrafe-server\&lt;/artifactId\&gt;
+
+       \&lt;version\&gt;${it.saga.pubblici.anagrafe.version}\&lt;/version\&gt;
+
+   \&lt;/dependency\&gt;
+
+   \&lt;dependency\&gt;
+
+       \&lt;groupId\&gt;it.saga.pubblici\&lt;/groupId\&gt;
+
+       \&lt;artifactId\&gt;anagrafe-core\&lt;/artifactId\&gt;
+
+       \&lt;version\&gt;${it.saga.pubblici.anagrafe.version}\&lt;/version\&gt;
+
+   \&lt;/dependency\&gt;
+
+**POM singolo applicativo**
+
+Sempre in riferimento alla prima versione dei POM, è chiamato a volte padre
+
+E&#39; 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&#39;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&#39; la tripletta che identifica l&#39;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
+
+   \&lt;dependency\&gt;
+
+       \&lt;groupId\&gt;it.saga.library\&lt;/groupId\&gt;
+
+       \&lt;artifactId\&gt;check-version-client\&lt;/artifactId\&gt;
+
+   \&lt;/dependency\&gt;
+
+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&#39;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
+
+   \&lt;dependency\&gt;
+
+       \&lt;groupId\&gt;it.saga.library\&lt;/groupId\&gt;
+
+       \&lt;artifactId\&gt;common-client\&lt;/artifactId\&gt;
+
+       \&lt;version\&gt;${project.version}\&lt;/version\&gt;
+
+   \&lt;/dependency\&gt;
+
+La sintassi usata per specificare la versione è usata per TUTTE le dipendenze fra jar della stessa apllicazione, e garantisce che l&#39;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&#39;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&#39; 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&#39;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:
+
+\&lt;properties\&gt;
+
+   \&lt;it.saga.pubblici.elettorale.version\&gt;2.1.63.0000\&lt;/it.saga.pubblici.elettorale.version\&gt;
+
+   ...
+
+\&lt;/properties\&gt;
+
+Se ho bisogno di usare la 66, non ancora rilasciata, inserisco nel padre la property con la versione corretta:
+
+\&lt;properties\&gt;
+
+   \&lt;it.saga.pubblici.elettorale.version\&gt;2.1.66.0000\&lt;/it.saga.pubblici.elettorale.version\&gt;
+
+   ...
+
+\&lt;/properties\&gt;
+
+che fa l&#39;overload del numero di versione.
+
+Quando verrà rilasciata la 66 (o maggiore) toglieremo la riga dal POM (in futuro l&#39;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&#39;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&#39;uso
+
+**File settings.xml**
+
+Contiene le impostazioni relative all&#39;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&#39;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)
\ No newline at end of file