Vous êtes sur la page 1sur 32

Spcification technique Socle applicatif

support dune solution open source dENT pour les EPLE


de la rgion le-de-France

Spcification Technique
Socle applicatif

Auteur

: Logica et Rgion le-de-France

Version

: 1.0

Gestion des changements de version


Ce tableau gre les modifications apportes au document au-del de sa version initiale. Les petites modifications de type erreurs de
frappe ou changements de syntaxe ne font pas lobjet dun suivi. Toute nouvelle version du document ne conserve pas
systmatiquement les changements apports lors de la version prcdente.

Version

Date

Auteur

Objet de la mise jour

1.0

04/03/2011

MMAU

Initialisation du document

SOMMAIRE
Objet du document

1. Fonctionnalits proposes par le socle

1.1. Quest-ce que le socle ?

1.2. Scurit

1.3. Autour de lannuaire

1.4. Console dadministration de lENT

1.5. Socles techniques

1.6. Utilitaires divers pour les modules

1.7. Vue densemble

2. Dcoupage technique et fonctionnement du socle


2.1. Organisation gnrale

9
9

2.2. CAS

10

2.3. Batchs

11

2.3.1.

Description des batchs

11

2.3.2.

Packaging et dploiement

11

2.3.3.

Fonctionnement gnral

12

2.4. APIs

12

2.4.1.

Description des apis

12

2.4.2.

Packaging et dploiement

13

2.4.3.

Utilisation des apis par un module

13

2.4.4.

Configuration interne des apis

15

2.5. Frameworks core

17

2.6. Customisation de serveurs

19

2.6.1.

Portail

19

2.6.2.

Solr

19

2.6.3.

Jabber

19

2.7. Web Services

20

2.8. Console dadministration

21

2.8.1.

Rle de la console

21

2.8.2.

Ajout dun nouveau module

21

2.8.3.

Fonctionnement gnral

22

2.9. Projet modle pour cration dune webapp

22

2.9.1.

Principe

22

2.9.2.

Utilisation pour cration dun module

22

2.9.3.

Modification de larchetype

23

2.10.

Tableau de correspondance des fonctionnalits

23

2.11.

Interactions et flux entre les projets

25

Objet du document
Le but de ce document est de dcrire le socle applicatif de lENT selon ces trois aspects :

le contenu et les services fournis


le fonctionnement technique sous-jacent
lutilisation du socle par les modules

Lutilisation et les configurations communes diffrentes parties du socle (utilisation gnrale des apis p
exemple) sont dcrites dans ce document. Par contre, le dtail de chaque projet, quand ncessaire, f
lobjet dune documentation technique spcifique supplmentaire.

1.

Fonctionnalits proposes par le socle


1.1.

Quest-ce que le socle ?

Le socle se veut tre une base stable commune tous les modules de lENT :

Il permet de fournir un certain nombre de fonctionnalits et choix techniques, sous la forme d


ensemble de projets (librairies, webapps, batchs) avec chacun sa spcialit.
Cela assure une centralisation des rgles mtier communes et incite garder une cohrence la fo
fonctionnelle et technique entre tous les modules.
Il simplifie galement le dveloppement dun module, car celui-ci peut directement rutiliser les out
proposs.

1.2.

Scurit

Plusieurs aspects de scurit sont fournis par le socle. Lutilisation de loutil CAS permet de grer :

Lauthentification/connexion
Le SSO (Single-Sign-On) avec les diffrents services externes relis lENT
La scurisation des droits daccs dans le portail

Dautre part, les flux et accs aux donnes sont galement scuriss par dautres moyens grs dans
socle :

Utilitaire de scurisation des urls http pour appeler les parties serveur (accs aux donnes)
fonction des droits de la personne connecte
Utilitaire de cryptage MD5 et AES pour les diffrents besoins de stockage de mots de passe

1.3.

Autour de lannuaire

La gestion des utilisateurs et groupes dans lENT est bas sur lannuaire fdrateur fourni par les acadmie
Ces donnes sont importes dans une base de donnes du socle. Elles sont adaptes et rorganises a
dtre utilises par les diffrents services. Les services proposs par le socle au sujet de lannuaire so
donc :

Alimentation partir des fichiers xml de lannuaire fdrateur


Synchronisation des donnes vers le portail
Encapsulation des appels au portail pour grer les accs et pages des personnes
Services daccs aux donnes de lannuaire
Rgles de gestion mtier autour des donnes de lannuaire
Centralisation des droits des personnes sur lannuaire (en fonction des groupes et profils)
Identifiants de connexion des utilisateurs

1.4.

Console dadministration de lENT

La console dadministration permet de grer le paramtrage et lactivation des diffrents modules par l
administrateurs des tablissements. Celle-ci est considre comme faisant partie du socle dans le sens
elle centralise un certain nombre dinformations utiles tous les modules. Elle contient notamment l
fonctionnalits suivantes :

Visualisation/export des donnes de lannuaire


Cration de groupes supplmentaires
Gestion de comptes supplmenatires comme les comptes invits et administrateurs
Activation/dsactivation des modules
Paramtrage et droits d'accs aux modules selon les profils
Remonte d'incidents
Services d'accs ces donnes de paramtrage utilisables par les modules

1.5.

Socles techniques

Le socle est galement un socle technique proposant des encapsulations de frameworks techniques et d
traitements centraliss permettant de :

garder une cohrence technique entre les modules


faciliter les dveloppements

Il contient les aspects suivants :

socles dabstraction des frameworks et classes de rfrence pour les diffrentes couche
persistance Ibatis, mtier, contrleur/vue (Struts2, GWT, PureMVC)
gestion des exceptions
gestion des fichiers de configuration
gestion du principe de conversations pour les donnes en session
cache mtier
gestion des logs
centralisation des feuilles de style ENT
template de gnration dun projet module

1.6.

Utilitaires divers pour les modules

Le socle propose galement des outils plus fonctionnels utiliser par les modules qui ont un beso
fonctionnel similaire. Dans le cas dun besoin fonctionnel correspondant ce que fournit lun de ces outils
est prfrable - pour des raisons dhomognit, de maintenance volutive, et de simplicit - dutiliser
dernier plutt que de refaire un traitement similaire en doublon dans chaque module.
Les fonctionnalits sont les suivantes :

Rcupration des informations de lutilisateur connect


Moteur de recherche Solr et api associe (indexation + recherche)
Gestion des droits sur les entits et contenu des modules (traitements mtier + interface avec ong
commun aux modules concerns)
Gestion des changes de donnes entre modules (flux REST)
Gestion des fichiers uploads sur le serveur applicatif
Utilitaire de cryptage MD5 et AES
Envoi demails
Api dinterfaage avec Jira
Customisation dun serveur Jabber par rapport lannuaire ENT

1.7.

Vue densemble

2.

Dcoupage technique et fonctionnement du socle


2.1.

Organisation gnrale

Techniquement, le socle se dcoupe en plusieurs projets de diffrents types. On retrouve des batchs, d
APIs, des frameworks-socles et divers projets de customisation. Selon leur type, ils sont utiliss et dploy
diffremment pour les modules.

2.2.

CAS

Loutil CAS est utilis pour toute la partie authentification et SSO des applications ENT. Dans les sourc
Lilie, cela reprsente sept projets regroups dans le dossier parent cas . Afin de rpondre aux besoi
spcifiques, certaines parties du logiciel ont t redveloppes. On peut distinguer trois aspects diffrents :

La partie cas-server : dploye indpendamment, elle permet dauthentifier les utilisateurs et d


conserver les informations. Les projets cas-server-webapp-lvl1 et cas-server-webapp-lvl2 dfinisse
les interfaces de connexion pour lutilisateur (lvl1 et lvl2 car il y a deux niveaux de connexion pour l
enseignants).

La partie cas-client-ent customise pour les webapps : elle est dploye avec les webapps po
intercepter les appels vers celles-ci et les envoyer au cas-server

La partie cas-client-portail customise pour le portail : elle a le mme rle que la prcdente ma
pour le portail

2.3.

Batchs

2.3.1. Description des batchs

Les batchs ncessaires lENT sont regroups dans le dossier bat du socle. Ce sont pour linsta
principalement des batchs autour de lannuaire.

Lannuaire ENT est reprsent sous la forme dune base de donnes alimente par des fichiers de lannuai
fdrateur fournis par les acadmies. Cette base de donnes est enrichie par des donnes provenant
lENT lui-mme. Ces donnes servent ensuite toutes les webapps de lENT, ainsi quau portail pour gr
ses pages.

bat-importfederateur : il soccupe de rcuprer les fichiers xml des acadmies pour les mettre
disposition pour lalimentation, puis de renvoyer le fichier derreurs fonctionnelles de lalimentation a
acadmies. Il est complt par des scripts shell pour grer lordonnancement, le passage d
deltas par rapport aux complets etc

bat-alimentation : cest celui qui fait lalimentation effective des donnes en base depuis les fichie
xml. Il se dcoupe en trois parties :
o la purge : elle remanie les fichiers xml dentre qui ne seraient pas tout fait daplomb (enlev
les tablissements que lon ne veut pas dployer, transformer des ordres d ajout en ordres
modification lorsquun complet fourni des ordres dajout de personnes dj prsentes
base)
o lalimentation : elle parse les diffrents xml dans lordre logique en fonction des relations ent
les types de donnes. Des contrles fonctionnels sont appliqus puis lordre est soit rejet, s
appliqu en base.
o le chargement des groupes : les donnes insres en base sont remanies par des procdur
pour alimenter une table de groupes oriente performances pour la lecture des donnes

bat-initportail : il sert synchroniser le portail aprs chaque alimentation. Le portail se sert d


donnes de lannuaire pour grer la cration de ses pages et les accs.

2.3.2. Packaging et dploiement


Les batchs sont tous packags de la mme manire : deux paquets sont gnrs

un jar contenant les sources et configurations du batch


un zip contenant le jar lui-mme plus les librairies dont dpend le batch. Ces librairies sont ajout
au classpath lors de lutilisation du batch.

2.3.3. Fonctionnement gnral


Ces batchs sont sous la forme dune main java, avec un back suivant les mmes rgles
dveloppement en couche que les autres projets, et faisant des appels aux apis.

Limport des diffrents contextes Spring utiliss par un batch (contexte du batch lui-mme et contextes d
apis) est fait par lintermdiaire dune classe SpringFactory propre au batch. Celle-ci est dans le packa
utils de chaque batch.

La proprit DATABASE_DEFINITION_TYPE du config.properties du batch doit tre dfinie avec la vale


dataSource . Cela signifie que les accs aux bases de donnes ventuelles (par lintermdia
notamment des apis) se feront par les datasources dfinies dans le contexte Spring de lapi en question,
non par la datasource JNDI de Tomcat. (la valeur dataSourceJNDI servant aux webapps dployes da
Tomcat). A terme, si les batchs sont dploys avec Quartz au sein dun war, ils pourront galement utiliser l
datasources JNDI.

2.4.

APIs

2.4.1. Description des apis

Un certain nombre dapis permettent dencapsuler les diffrents traitements et accs aux ressources util
pour les modules. Elles sont pour la plupart principalement constitues dune partie back, et suivent le mm
modle en couches (business/dao) que les modules web.

api-annuaire : elle regroupe tous les traitements daccs, rgles de gestion et droits concernant l
donnes de la base annuaire. Elle met disposition un certain nombre de mthodes publiques po
utilisation par les autres projets du socle ou les modules web.

api-admin : elle regroupe tous les traitements daccs et rgles de gestion concernant les donnes d
la base dadministration. Les donnes sont principalement mises jour par la console dadmin, ma
consultes par tous les projets.

api-liferay : cette api permet dencapsuler les rgles de gestion relatives au portail et les appels a
web-services de celui-ci. Les mthodes disposition sont surtout des mthodes de mises jour po
synchroniser ponctuellement le portail avec les informations saisies dans lENT.

api-recherche : elle permet dencapsuler les traitements dindexation et de recherche avec Solr. L
mthodes publiques disposition permettent de modifier les indexations de contenu propres chaq
webapp. La recherche peut ensuite tre faite sur la globalit.

api-portail : celle-ci est une api faade, servant dintermdiaire entre les modules web et les apis. E
dpend des quatre apis prcdentes. Lorsquune fonctionnalit ncessite lappel diffrentes ap
elle permet de centraliser et ordonnancer les traitements entre les diffrentes apis, afin que cela s
transparent pour le module appelant. Les mthodes publiques disposition sont principalement de
consultation qui se prsentent sour la forme de business utilisables par les modules.

api-portail-gestion : de manire similaire lapi-portail, elle permet de centraliser et ordonnancer l


traitements entre les diffrentes apis, mais regroupe cette fois-ci principalement les mthodes d
mises jour. Elle nest donc pas disponible pour les modules, mais seulement pour les autres proje
du socle (console dadmin, batchs).

api-web-droits : cette api est un peu particulire car elle nest pas constitue que dune partie bac
Elle contient galement toute une partie front (interface JSP + contrleur Struts) quivalente ce
des modules webapps ENT. La partie back peut tre utilise de la mme manire que les autres ap
mais lintgration totale avec le front se fait en suivant plusieurs recommandations prcises dans
spcification technique de lapi elle-mme.

Cette api permet donc de centraliser toute la gestion des droits propres aux entits des modul
(contenus spcifiques des webapps). Elle centralise la fois les rgles de gestion mtier et long
dinterface commun tous les modules, permettant daffecter des droits aux personnes et groupes s
les contenus. Les actions Struts de lapi peuvent ainsi tre appeles par les webapps qui intgrent
configuration ncessaire.

Le projet api-web-droits-portlet redfinit certaines classes et configurations de lapi-web-droits dans


but de fonctionner avec les modules de type portlet (version de Struts diffrente).

api-logging : cette api fournit simplement une classe dextension de log4j pour grer le back
journalier des fichiers de logs. Elle est utilise dans les lo4j.xml de chaque projet du socle et d
modules web.

api-jira : elle permet dencapsuler les appels aux web-services Jira. Les mthodes propos
permettent de crer des comptes et dajouter des demandes dans Jira.

2.4.2. Packaging et dploiement

Les apis sont toutes packages sous forme de jar que les modules peuvent ajouter en dpendance. Ell
sont alors intgres au war de lapplication et dployes avec chaque webapp.
2.4.3. Utilisation des apis par un module

A part lapi-logging, les apis fonctionnent toutes de la mme faon. Elles sont configures notamment av
Spring qui permet de mettre facilement disposition les services : par lintermdiaire de son interfac
chaque implmentation de business contenant des mthodes publiques utilisables par dautres projets, e
dfinie par un bean Spring. Ces beans peuvent tre ajouts au contexte Spring du module appelant,
injects dans les business du module.

Ajout de la dpendance sur lartifact Maven dans le pom.xml du module


<dependency>
<groupId>org.lilie.socle</groupId>
<artifactId>api-portail</artifactId>
</dependency>

Ajout de limport du contexte Spring de lapi dans le web.xml (ou dans une SpringFactory pour u
batch)
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
classpath:spring/applicationContext.xml
classpath:spring/applicationContext_api-portail.xml
classpath:spring/applicationContext_fmk-core-web.xml
</param-value>

</context-param>

Ajout du business api utiliser en attribut du business du module (ne pas oublier le setter po
linjection Spring, le getter nest pas ncessaire). Il faut utiliser le type interface et non limplmentatio
directement, car celle-ci sera injecte par Spring.
private ElevePortailBusiness elevePortailBusiness;
public void setElevePortailBusiness(ElevePortailBusiness elevePortailBusiness) {
this.elevePortailBusiness = elevePortailBusiness;
}

Ajout du business api en proprit du bean Spring du module


<bean id="moduleBusiness" class="org.lilie.services.module.business.impl.ModuleBusinessImpl">
<property name="elevePortailBusiness" ref="elevePortailBusiness" />
</bean>

Les DTOs des apis peuvent tre utiliss directement par les modules.
Prcisions concernant les fichiers de configuration :

La gestion des fichiers de configuration des modules et apis (paramtrage de proprits externalis
des sources) est centralise par la classe ConfigAppli du fmk-core-ent, qui est dcrite dans
spcification technique du core. Pour les apis, lappel de la mthode ConfigAppli.getProprieteStr() d
prendre en paramtre le nom de lapi dont on veut rcuprer un paramtre de configuration. Le bea
ConfigAppli peut galement tre inject par Spring dans le business du module de la mme mani
que les business des apis.

Comme pour les batchs, les modules utilisant des apis ou une base de donnes spcifique doive
prciser la proprit DATABASE_DEFINITION_TYPE dans le config.properties du module (pas d
apis). La valeur doit tre dataSourceJNDI pour utiliser les datasources JNDI dfinies dans Tomc
Sinon ce sont les datasources dfinies dans le contexte Spring qui sont utilises (par exemple sur l
postes de dveloppement).

2.4.4. Configuration interne des apis

Nommage

Afin de garder une homognt entre les diffrentes apis et un bon fonctionnement lorsque plusieurs so
utilises en mme temps, certaines rgles de nommage sont dfinies :
Les diffrents fichiers de configuration ont tous une racine commune et un suffixe portant le nom de lapi :

Configuration de lapplication : src/main/resources/config_<nomApi>.properties


Mapping DTO/POJO avec dozer : src/main/resources/dozer/dozerMappings_<nomApi>.xml
Chargement des map Ibatis : src/main/resources/SqlMapConfig_<nomApi>.xml
Les fichiers de contextes Spring sont dcoups par couche et contiennent encore une fois le nom d
lapi en suffixe : src/main/resources/spring/applicationContext_<nomApi>.xml

De mme, quand tous les contextes Spring sont chargs en mme temps, il ne faut pas quil y ait de confl
dans les noms des beans. Le nom de lapi est donc prsent dans chacun (ou au moins dans ceux pouva
prter confusion car similaires dans chaque api) : par exemple, annuaireAdapter , annuaireSqlMap
ou personnePortailBusiness .
Configuration des datasources
La configuration de laccs aux donnes pour les apis fonctionne de la mme manire que pour les bases
donnes de chaque module ENT. Deux types de datasources diffrents sont grs systmatiquement :

JNDI dfinie dans Tomcat


o Nom du bean spring : dataSourceJNDI<nomApi>
o Le nom JNDI utilis est valu dans le config.properties de lapi par la propri
DATABASE_JNDI.
Datasource simple dfinie dans le contexte Spring : org.postgresql.ds.PGPoolingDataSource
o Nom du bean spring : dataSource<nomApi>
o Les proprits de la source de donnes sont dfinies dans le config.properties de lapi :
DATABASE_SERVER_NAME, DATABASE_PORT_NUMBER, DATABASE_NAME,
DATABASE_USER, DATABASE_PASSWORD, DATABASE_DATASOURCE_NAME,
DATABASE_INITIAL_CONNECTIONS, DATABASE_MAX_CONNECTIONS

Les deux beans spring sont dclars en lazy-init afin que seul celui qui est rellement utilis au lanceme
soit effectivement charg.

Le bean <nomApi>sqlMap permet de dfinir la datasource et le fichier de mapping Ibatis utiliser. Le cho
de la datasource entre JNDI ou non est variabilis, afin que le module puisse dcider de manire globa
pour toutes les datasources quil utilise. Cest le paramtre DATABASE_DEFINITION_TYPE qui est met
dans le config.properties du module (et non de lapi), comme prcis dans le paragraphe prcdent.

Chargement des fichiers de configuration

Le chargement du fichier config.properties se fait de manire centralise par un bean Spring customis po
lENT. Cela permet de regrouper tous les paramtres de toutes les apis ncessaires au module et d
accder de manire centralise. Chaque api prcise donc ce bean spcifique les informations qui lui so
propres :
Dans le applicationContext_<nomApi>.xml, on dfinit le bean suivant :
<bean id="propertyConfigurerApiAnnuaire"
class="org.lilie.socle.core.utils.spring.CustomPropertyPlaceholderConfigurer">
<property name="configAppli" ref="configAppli"/>
<property name="fichierConfigVarEnvirStr" value="annuaire.config"/>
<property name="fichierConfigInterneStr" value="config_api-annuaire.properties"/>
<property name="placeholderPrefix" value="$annuaire{"/>
<property name="nomApi" value="api-annuaire"/>
</bean>

configAppli : instance dun objet du core associ au CustomPropertyHolder. Cest le point dentr
ensuite pour accder aux proprits dans le code
fichierConfigVarEnvirStr : le nom de la variable denvironnement contenant le chemin du fichier
config.
fichierConfigInterneStr : sil ny a pas de variable denvironnement (en environnement de dev), ce
proprit dfinit le nom du fichier en interne dans le jar de lapi. Dans le packaging cible des release
les fichiers de config sont externaliss et il ny a rien dans le jar.
placeHolderPrefix : cest le prfixe utilis dans les fichiers de contexte Spring pour accder u
variable du fichier config.properties de lapi (par exemple pour les informations de la datasource).
nomApi : cest le nom de lapi utilis dans ConfigAppli lorsque lon veut rcuprer une proprit de la
dans le code

Configuration pour les tests dune api

Pour tester une api avec de simples main() Java, il faut configurer le lancement de cette classe de la mm
manire quun module utilisant lapi (comme un batch utilisant lapi), afin que les donnes entrant
ncessaires lapi soient prsentes :

un fichier config.properties de module contenant DATABASE_DEFINITION_TYPE


un log4j.xml
un fichier de contexte spring de type module : applicationContext.xml, contenant un bean
chargement de fichier de configuration customis pour un module (lgrement diffrent de celui d
apis) :

<bean id="propertyConfigurer"
class="org.lilie.socle.core.utils.spring.CustomPropertyPlaceholderConfigurer">
<property name="configAppli" ref="configAppli"/>
<property name="fichierConfigVarEnvirStr" value="vide.config"/>
<property name="fichierConfigInterneStr" value="config.properties"/>
<property name="fichierLog4jVarEnvirStr" value="vide.log4j"/>
<property name="fichierLog4jInterneStr" value="log4j.xml"/>
<property name="delaiRechargementLog4jStr" value="60000"/>
</bean>

Le prfixe et le nom de lapi ne sont pas ncessaires pour les modules, car par dfaut sans prfixe
considre toujours celui du module englobant.

Dans la classe, avant de commencer le test, il faut charger le contexte Spring avec le contexte
module et celui de lapi tester :
String FICHIER_APPLICATION_CONTEXT_TEST = "spring/applicationContext.xml";
String [] tabCtx = {FICHIER_APPLICATION_CONTEXT_TEST,
ConstantesApiAnnuaire.FICHIER_APPLICATION_CONTEXT};
ClassPathXmlApplicationContext classPathXmlApplicationContext = new ClassPathXmlApplicationContext(tabCtx);
PersonneBusiness pBusiness = (PersonneBusiness) classPathXmlApplicationContext.getBean("personneBusiness");

2.5.

Frameworks core

Le dossier fmk contient plusieurs projets plutt orients socles techniques. Ce sont des framewor
spcifiques ENT qui ont plusieurs rles :

Donner une couche dabstraction des outils techniques utiliss


Proposer un socle technique de dpart pour les nouveaux projets
Centraliser les traitements qui peuvent tre commun tous les projets

Il en existe pour linstant 6 (3 pour les clients riches, 1 pour tous les projets, 2 pour les clients lgers) :

fmk-ria-ihm :

framework de gestion dinterface pour les applications ria de lENT. Ce framework propose un
interface plus ou moins gnrique servant de cadre pour les applications GWT. Linterface e
paramtrable pour tre adapte au besoin du projet.

fmk-ria-serveur :

framework permettant la mise en place de la partie back dune application ria en GWT (configurati
des services RPC)

fmk-ria-puremvc :

framework permettant de mettre en place le concept MVC pour les applications ria de lENT. Ce pro
contient les traitements et classes de rfrence dabstraction du framework externe PureMV
(changes entre les couches par notifications).
Lutilisation de ces projets est plus dtaille dans la STD spcifique.

fmk-core-ent :
framework core de tous les projets ENT, aussi bien pour les modules web que les apis et les batchs.

o Il sert de socle technique de dpart afin que tous les projets partent sur les mmes bas
techniques : gestion des exceptions, des logs, des fichiers de configuration, classes
rfrence dabstraction des frameworks du back (Ibatis, Dozer), cache mtier

o Il regroupe galement des constantes et DTOs de donnes ENT utiles tous les nivea
(donnes utilisateurs, constantes de profils etc).

o Un certain nombre dutilitaires sont galement disponibles afin de faciliter le dveloppement


dhomognser lutilisation des outils externes : upload de fichiers, changes de donnes ent
modules (REST), rcupration des informations de connexion, cryptage des donnes, env
demail
Tous les projets doivent normalement utiliser ce framework core.

fmk-core-web :

framework core de toutes les webapps ENT en client lger (Struts 2). Il a les mmes objectifs que fm
core-ent mais pour la partie front. Il regroupe donc :

o des parties de socle technique pour le front : classes de rfrence dencapsulation de Stru
gestion des pages derreur, gestion des donnes en session par le principe des conversation
centralisation des css et images des webapps, centralisation des tlds pour les librairies de ta
et sitemesh

o des constantes et donnes utiles toutes les webapps dans la partie front : noms d
paramtres passs dans la request

o des utilitaires divers pour faciliter le dveloppement de la vue et du contrleur : rcuprati


des informations de connexion dans la request, partie contrleur et vue de lupload/downloa
de fichiers, diteur WYSIWYG, utilisation dAjax et de JQuery dans la vue

Ces deux projets core sont utiliser de la mme manire que celle dcrite pour les apis dans
chapitre prcdent (notamment avec Spring). Le nommage des fichiers et la configuration interne e
galement similaire celle des apis. Ces projets suivent les mmes rgles de dveloppement
couche que les autres projets (dfinies dans la documentation des normes de dveloppement).

Les dtails dutilisation de chaque fonctionnalit se trouvent dans la spcification technique du projet
lui-mme.

fmk-core-web-portlet :

Comme pour lapi-web-droits-portlet par rapport lapi-web-droits, ce projet est le pendant de fm


core-web pour les portlets. Il a comme dpendance fmk-core-web, et redfinit seulement les classes
configurations adapter pour les portlets, en raison surtout de la version de Struts qui diffre. L
portlets font donc rfrence celui-ci plutt qu fmk-core-web (aussi bien dans le pom.xml que da
les fichiers de configuration dimports divers).

2.6.

Customisation de serveurs

Plusieurs projets sont en ralit des adaptations de serveurs dvelopps hors ENT afin de les intgrer d
manire complte au socle ENT et ses besoins. Ces projets sont open-source, la modification de leur co
source est donc autorise.

2.6.1. Portail
Deux projets servent adapter le portail Liferay aux specificits de lENT :

prt-custom : il est packag sous forme dun jar dploy dans le portail comme une nouvelle librair
disponible. Il permet de dfinir tous les traitements java spcifiques, comme linteraction avec CA
(filter, servlets de login/logout), les traitements daffichage du bandeau, linteraction avec Xiti

La gestion des fichiers de configuration log4j.xml et config.properties du projet est la mme que po
les modules ENT (bean spring customis + ConfigAppli).

prt-lookeliot : il permet de dfinir le look (images, css) du portail. Un zip de static diffrent est packag
pour chaque porteur grce des configurations de build Maven.

Les spcifications techniques du portail permettent de rentrer plus en dtail sur ces customisations.
2.6.2. Solr

Certains modules, pas tous, indexent des donnes dans un moteur de recherche afin de pouvoir t
disponibles de manire globale par lintermdiaire dun service de recherche.

Le projet solr-custom permet dadapter le serveur SolR, utilis pour lindexation et la recherche des diffren
contenus, aux besoins de lENT. En plus de quelques modifications/ajouts du code source, ce projet se
surtout stocker les diffrentes configurations du serveur et les schmas des contenus ENT indexer.
La specification technique sur lapi-recherche rentre plus en dtail sur ce sujet.
2.6.3. Jabber

Le dossier openfire contient plusieurs projets relatifs limplmentation du serveur Jabber pour les EN
Jabber est le protocole standard pour les communications de type messagerie instantane. Nous utilisons
serveur Openfire comme implmentation de la partie serveur du protocole.

Cependant, afin de bien sintgrer notre socle et plus particulirement lannuaire, des adaptations d
serveur ont t ncessaires :

openfire-custom : customisation des sources du serveur pour pointer sur lannuaire ENT p
lintermdiaire des apis ENT. Les comptes de chat dcoulent alors directement des utilisateurs
lannuaire. La connexion au serveur Jabber est transparente lorsque lutilisateur est dj connect
lENT.
Ce projet est packag dans un jar dploy avec les librairies du serveur Openfire.

Plusieurs plugins Openfire ont t galement adapts ou crs. Le modle de packaging de ceux-ci ta
prt, dautres pourraient ventuellement facilement tre ajouts dans lavenir : le contenu, le packaging et
dploiement dun plugin suivent des rgles dfinies par Openfire. Maven nous permet de grer cela
moment du build.

plugin-search-custom : adaptation du plugin de recherche des comptes pour pointer sur lannuaire p
lintermdiaire des apis ENT.
plugin-entpacketfilter : permet de filtrer tous les paquets envoys entre les clients et serveurs Jabb
en fonction des droits des utilisateurs dfinis par lapi-annuaire. Linterface du client chat EN
empche dj les communications non autorises, mais ce plugin est une scurit dans le c
dutilisation dautres clients de chat par les utilisateurs.

Toujours en suivant le principe de cohrence entre tous les projets ENT, le chargement des fichiers d
configuration se fait sur le mme modle que les autres projets, avec Spring et lutilisation du fmk-core-ent.
La spcification technique du chat permet de rentrer plus dans les dtails.

2.7.

Web Services

Plusieurs services externes proposent des web services pour accder leurs donnes. La gnration d
services Java partir des WSDL fournis a t centralise dans le dossier ws . Cela permet de regroup
les projets ayant besoin des mmes dpendances relatives aux web services :
ws-prt : web services du portail Liferay. Permet de mettre jour le portail lors des modifications
donnes dans lannuaire.
ws-jiraclient : web services daccs Jira pour crer ou modifier des demandes
Ils fonctionnent de la mme faon :
Utilisation dAxis 1.4 comme librairie Java pour les appels aux web services
Fichiers WSDL dans src/main/resources/wsdl
Utilisation du plugin Maven pour gnrer les classes :

<properties>
<dir.wsdl>${basedir}/src/main/resources/wsdl</dir.wsdl>
</properties>
<build>
<plugins>
<!-- Generation du java a partir des wsdl -->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>axistools-maven-plugin</artifactId>
<configuration>
<sourceDirectory>${dir.wsdl}</sourceDirectory>
<wsdlFiles>
<!-- Ne pas faire le lien en http mais en file Pour la rcupration :
ssh VM-ENTIDF-DEV2 cd /tmp mkdir wsdl cd wsdl for i in `cat list.txt`;
do wget $i; done rename ?wsdl .wsdl *wsdl -->
<wsdl>jirasoapservice-v2.wsdl</wsdl>
</wsdlFiles>
<packageSpace>org.lilie.socle.wsjiraclient</packageSpace>
<verbose>true</verbose>
<allElements>true</allElements>
<testCases>false</testCases>
</configuration>
<executions>
<execution>
<phase>process-resources</phase>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>

Les appels aux classes Java gnres sont ensuite encapsuls par lintermdiaire dapis (api-lifera
api-jira) pour permettre de rendre leur utilisation transparente au code appelant.

2.8.

Console dadministration

2.8.1. Rle de la console

Comme vu dans le premier chapitre, bien qutant une webapp avec une interface utilisateur, la conso
dadministration fait partie du socle. En effet, elle permet de centraliser les paramtrages des diffren
modules et de consulter/modifier certaines donnes de lannuaire. Elle sert de point dancrage pour chaq
module qui doit sinterfacer avec elle pour senregistrer en tant que nouveau module de lENT. Chaq
module peut ensuite tre activable au besoin par chacun des tablissements. Par lintermdiaire de son ap
admin (utilise par lapi-portail en faade vue plus haut), la console fournit galement un certain nombre d
mthodes publiques accessibles pour les modules et le portail, afin de rcuprer les paramtrages
informations diverses disponibles.
2.8.2. Ajout dun nouveau module
Lors de lajout dun nouveau module, il faut :

Dans le projet de la console dadmin : crer un cran dactivation et paramtrage similaire ceux d
autres modules (description prcise du code dans la spcification technique de la conso
dadministration)

Dans le module ajout : rcuprer les informations de paramtrage saisies grce lapi-port
(description de lutilisation de lapi dans les chapitres prcdents)

Dans les projets prt : modifier le bandeau du portail pour faire apparatre le nouveau modu
(description du code du bandeau dans la spcification du portail)

2.8.3. Fonctionnement gnral

La console est compose de trois projets dans le dossier ria/ria-admin. Cest une webapp client ric
dveloppe en GWT et PureMVC. Elle est dploye de la mme manire que les webapps des diffren
modules. Elle peut accder aux apis du socle au besoin (sans forcment passer par lapi-portail). Le code d
la console utilise galement les 3 projets socle fmk-ria dcrits plus haut.

Des spcifications techniques sur la console, ainsi que sur lutilisation du socle client riche, sont disponibles

2.9.

Projet modle pour cration dune webapp

2.9.1. Principe

Loutil Maven permet de crer des projets template servant de base de dpart pour la cration d
nouveau projet. Ceux-ci sappellent des archetype . lls permettent de prdfinir larborescence du proj
les diffrents packages de base, avec certaines classes, ressources et configurations dj prsentes.

Nous avons utilis ce principe pour crer un modle pour les modules ENT. Ainsi, il nest pas ncessaire
recrer un projet de zro chaque fois. Les dpendances et configurations de base dun module so
automatiquement cres laide de larchetype. Pour linstant, il nexiste quun modle pour les modules
client lger (Struts 2).
2.9.2. Utilisation pour cration dun module

Larchetype est un artifact Maven dploy comme toutes les autres librairies, avec son groupId et sa version
<groupId>org.lilie.services.archetype</groupId>
<artifactId>tem-web-archetype</artifactId>

En ligne de commande, se placer dans le workspace l o lon veut crer le projet


Utiliser la commande : mvn archetype:generate
Le catalogue utilis peut tre prcis (voir la documentation en ligne du maven-archetype-plugin po
les dtails), sinon il est demand en prompt.

On choisit larchetype parmi ceux proposs par la commande, puis on saisit les informations suivant
demandes :
o groupId : org.lilie.services
o artifactId : web-<nommodule>
o version en cours
o package : org.lilie.services.web<nommodule>
Le projet est alors cr. Toutes les configurations sont dj pr-remplies. Les noms de package
fichiers et beans Spring ont t automatiquement adapts pour prendre en compte le nom du module
Seule une configuration est changer la main : la configuration du CustomPropertyHolder da
applicationContext.xml. Il faut changer les noms des variables denvironnement du config et du log
pour les adapater avec le nom du module.
Pour importer le projet dans Eclipse, ne pas oublier de supprimer dabord le dossier .settings
existe dans le projet nouvellement cr.

2.9.3. Modification de larchetype


Le projet servant de source pour la cration de larchetype est le projet tem-web, dans la partie
services/services-initiaux-web.

Modifier les sources et ressources crer


Ne pas oublier de supprimer les dossiers et fichiers qui sont gnrs par le build, car ils ne doivent
pas tre prsents dans larchetype dploy (target, fichiers copis du core)
Se placer dans le dossier du projet tem-web
Lancer la commande :
mvn archetype:create-from-project -Darchetype.languages=java,xml,txt,groovy,cs,mdo,
aj,jsp,gsp,vm,html,xhtml,properties,.classpath,.project,resources
Ne pas oublier le resources pour que les noms de package soient galement changs dans les
dossiers de ressources.

Se placer dans \tem-web\target\generated-sources\archetype\


Lancer la commande mvn install pour le mettre dans le repository local (ou mvn deploy pour le
dployer sur le Nexus)

2.10.

Tableau de correspondance des fonctionnalits

Voici un tableau faisant correspondre les fonctionnalits dcrites dans le premier chapitre au dcoupag
technique des projets.

FONCTIONNALITE

PROJETS CONCERNES

Scurit
authentification

cas

SSO

cas

Droits daccs portail

prt-custom

Outils de scurisation des urls http

api-web-droits,
api-annuaire

Outil de cryptage

fmk-core-ent

Annuaire
Alimentation

bat-alimentation,
bat-importfederateur

Synchronisation portail

bat-initportail

Encapsulation appels portail

api-liferay
(par api-portail)

Accs aux donnes de lannuaire

api-annuaire
(par api-portail)

RG et droits sur lannuaire

api-annuaire

Donnes de connexion

api-annuaire

Administration

Visualisation/export annuaire

ria-admin

Cration de groupes supplmentaires

ria-admin

Gestion de comptes invits et administrateurs

ria-admin

Activation/dsactivation des modules

ria-admin

Paramtrage et droits d'accs aux modules selon les profils

ria-admin

Remonte d'incidents

ria-admin

Services d'accs ces donnes de paramtrage utilisables par les api-admin (api-portail)
modules
Socles techniques
abstraction frameworks et classes de rfrence : persistance Ibatis, fmk-core-ent
mtier
Abstraction frameworks et classes de rfrence : contrleur/vue fmk-core-web
(Struts2)
Abstraction frameworks et classes de rfrence : contrleur/vue (GWT, fmk-ria-ihm,
PureMVC)
fmk-ria-puremvc
gestion des exceptions

fmk-core-ent

gestion des fichiers de configuration

fmk-core-ent

gestion du principe de conversations pour les donnes en session

fmk-core-web

cache mtier

fmk-core-ent

gestion des logs

fmk-core-ent

centralisation des feuilles de style ENT

fmk-core-web

template de gnration dun projet module

tem-web

Utilitaires
Rcupration informations utilisateur connect

fmk-core-web, fmk-core-ent

Moteur de recherche

api-recherche (par api-portail), solrcustom

Gestion des droits sur les contenus des modules

api-web-droits

Gestion des changes de donnes entre modules

fmk-core-ent

Gestion des fichiers uploads sur le serveur applicatif

fmk-core-ent, fmk-core-web

Utilitaire de cryptage MD5 et AES

fmk-core-ent

Envoi demails

fmk-core-ent

Api dinterfaage avec Jira

api-jira

Customisation dun serveur Jabber par rapport openfire


lannuaire ENT

2.11.

Interactions et flux entre les projets

Point de dpart : fmk-core-ent est le projet central commun tous les projets. Il sert de framework d
base pour tous les autres qui ont une dpendance sur lui. Il na donc aucune dpendance sur le
autres projets ENT.

Le projet fmk-core-web dpend de fmk-core-ent et ltend pour complter la partie web. Les autre
projets du socle ne dpendent pas de ce projet qui est fait pour les modules.

Accs aux apis :

o Les fonctionnalits des apis ne sont pas accdes en direct par les modules mais p
lintermdiaire de lapi-portail qui centralise le tout et sert de faade pour proposer seuleme
ce qui est utile.

o Les projets du socle (console dadmin, batchs, cas) peuvent par contre accder directeme
aux apis sous-jacentes sans passer par la faade.

Les apis ont par contre des dpendances entre elles :

o lapi-portail pointe donc sur les quatres apis proposant des fonctionnalits aux modules : a
recherche, api-annuaire, api-admin, api-liferay

o lapi-portail-gestion a les mmes dpendances que lapi-portail. Elle est utilise par les proje
du socle (console dadmin, batchs) pour partager des traitements communs dappel aux ap
sous-jacentes.

o lapi-web-droits, qui est une api galement de front, est un niveau au dessus, comme le
modules, car elle dpend de ce que propose lapi-portail dans son ensemble

o les autres apis ne communiquent pas entre elles, elles grent chacune leurs fonctionnalit
spcifiques.

Les projets customisation de serveurs (openfire, prt-custom, solr-custom) sont au dessus des ap
dont ils se servent pour intgrer notamment les donnes annuaire.

Interactions avec les modules :

o Les projets ws ne sont pas accds directement par les modules. Ils sont encapsuls par le
apis (api-liferay, api-jira).

o Les projets du socle naccdent pas aux modules. Aucun flux nest prvu dans ce sens l p
larchitecture mise en place. Ce sont les modules qui utilisent le socle. De mme pour le ca
particulier de la webapp de la console dadmin : lapi-admin permet aux modules daccder a
donnes de la console, mais la console nappelle pas les diffrents modules qui grent tou
seuls leurs donnes spcifiques. Les paramtrages dactivation et droits par profil sont bien de
donnes internes la console, consultables par les modules.

o Les modules sont au plus haut niveau et dpendent des diffrents projets du socle, qu
embarquent dans leur war pour le dploiement.

o Les modules sont indpendants les uns des autres. Pour des besoins ponctuels dchanges d
donnes entre ces modules distants, des flux de type HTTP sont prvus : les traitemen
mtiers restent du ct du module contenant les donnes concernes, qui met dispositio
des services REST pour les autres modules.