Dossier de spcification technique - Socle applicatif

ENTSpcification Technique socle applicatif

Spcification technique Socle applicatifsupport dune solution open source dENT pour les EPLEde la rgion le-de-France

Spcification Technique Socle applicatif

Auteur : Logica et Rgion le-de-FranceVersion: 1.0

Gestion des changements de versionCe 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.

VersionDateAuteurObjet de la mise jour

1.004/03/2011MMAUInitialisation du document

Espace Numrique de Travail

SommaireObjet du document51.Fonctionnalits proposes par le socle51.1.Quest-ce que le socle?51.2.Scurit51.3.Autour de lannuaire61.4.Console dadministration de lENT71.5.Socles techniques71.6.Utilitaires divers pour les modules81.7.Vue densemble82.Dcoupage technique et fonctionnement du socle92.1.Organisation gnrale92.2.CAS102.3.Batchs112.3.1.Description des batchs112.3.2.Packaging et dploiement112.3.3.Fonctionnement gnral122.4.APIs122.4.1.Description des apis122.4.2.Packaging et dploiement132.4.3.Utilisation des apis par un module132.4.4.Configuration interne des apis152.5.Frameworks core172.6.Customisation de serveurs192.6.1.Portail192.6.2.Solr192.6.3.Jabber192.7.Web Services202.8.Console dadministration212.8.1.Rle de la console212.8.2.Ajout dun nouveau module212.8.3.Fonctionnement gnral222.9.Projet modle pour cration dune webapp222.9.1.Principe222.9.2.Utilisation pour cration dun module222.9.3.Modification de larchetype232.10.Tableau de correspondance des fonctionnalits232.11.Interactions et flux entre les projets25

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 modulesLutilisation et les configurations communes diffrentes parties du socle (utilisation gnrale des apis par exemple) sont dcrites dans ce document. Par contre, le dtail de chaque projet, quand ncessaire, fait lobjet dune documentation technique spcifique supplmentaire.Fonctionnalits proposes par le socleQuest-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 dun ensemble de projets (librairies, webapps, batchs) avec chacun sa spcialit. Cela assure une centralisation des rgles mtier communes et incite garder une cohrence la fois fonctionnelle et technique entre tous les modules. Il simplifie galement le dveloppement dun module, car celui-ci peut directement rutiliser les outils proposs.

ScuritPlusieurs 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 le socle:

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

Autour de lannuaire

La gestion des utilisateurs et groupes dans lENT est bas sur lannuaire fdrateur fourni par les acadmies. Ces donnes sont importes dans une base de donnes du socle. Elles sont adaptes et rorganises afin dtre utilises par les diffrents services. Les services proposs par le socle au sujet de lannuaire sont 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

Console dadministration de lENTLa console dadministration permet de grer le paramtrage et lactivation des diffrents modules par les administrateurs des tablissements. Celle-ci est considre comme faisant partie du socle dans le sens o elle centralise un certain nombre dinformations utiles tous les modules. Elle contient notamment les 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

Socles techniquesLe socle est galement un socle technique proposant des encapsulations de frameworks techniques et des traitements centraliss permettant de: garder une cohrence technique entre les modules faciliter les dveloppementsIl contient les aspects suivants: socles dabstraction des frameworks et classes de rfrence pour les diffrentes couches: 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

Utilitaires divers pour les modulesLe socle propose galement des outils plus fonctionnels utiliser par les modules qui ont un besoin fonctionnel similaire. Dans le cas dun besoin fonctionnel correspondant ce que fournit lun de ces outils, il est prfrable - pour des raisons dhomognit, de maintenance volutive, et de simplicit - dutiliser ce dernier plutt que de refaire un traitement similaire en doublon dans chaque module.Les fonctionnalits sontles 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 onglet 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

Vue densemble

Dcoupage technique et fonctionnement du socleOrganisation gnraleTechniquement, le socle se dcoupe en plusieurs projets de diffrents types. On retrouve des batchs, des APIs, des frameworks-socles et divers projets de customisation. Selon leur type, ils sont utiliss et dploys diffremment pour les modules.

CASLoutil CAS est utilis pour toute la partie authentification et SSO des applications ENT. Dans les sources Lilie, cela reprsente sept projets regroups dans le dossier parent cas. Afin de rpondre aux besoins 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 den conserver les informations. Les projets cas-server-webapp-lvl1 et cas-server-webapp-lvl2 dfinissent les interfaces de connexion pour lutilisateur (lvl1 et lvl2 car il y a deux niveaux de connexion pour les enseignants).

La partie cas-client-ent customise pour les webapps: elle est dploye avec les webapps pour 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 mais pour le portail

BatchsDescription des batchsLes batchs ncessaires lENT sont regroups dans le dossier bat du socle. Ce sont pour linstant principalement des batchs autour de lannuaire. Lannuaire ENT est reprsent sous la forme dune base de donnes alimente par des fichiers de lannuaire fdrateur fournis par les acadmies. Cette base de donnes est enrichie par des donnes provenant de lENT lui-mme. Ces donnes servent ensuite toutes les webapps de lENT, ainsi quau portail pour grer 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 aux acadmies. Il est complt par des scripts shell pour grer lordonnancement, le passage des deltas par rapport aux complets etc

bat-alimentation: cest celui qui fait lalimentation effective des donnes en base depuis les fichiers xml. Il se dcoupe en trois parties: la purge: elle remanie les fichiers xml dentre qui ne seraient pas tout fait daplomb (enlever les tablissements que lon ne veut pas dployer, transformer des ordres dajout en ordres de modification lorsquun complet fourni des ordres dajout de personnes dj prsentes en base) lalimentation: elle parse les diffrents xml dans lordre logique en fonction des relations entre les types de donnes. Des contrles fonctionnels sont appliqus puis lordre est soit rejet, soit appliqu en base. le chargement des groupes: les donnes insres en base sont remanies par des procdures 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 des donnes de lannuaire pour grer la cration de ses pages et les accs.

Packaging et dploiementLes 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 ajouter au classpath lors de lutilisation du batch.

Fonctionnement gnralCes batchs sont sous la forme dune main java, avec un back suivant les mmes rgles de 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 des apis) est fait par lintermdiaire dune classe SpringFactory propre au batch. Celle-ci est dans le package utils de chaque batch.La proprit DATABASE_DEFINITION_TYPE du config.properties du batch doit tre dfinie avec la valeur dataSource. Cela signifie que les accs aux bases de donnes ventuelles (par lintermdiaire notamment des apis) se feront par les datasources dfinies dans le contexte Spring de lapi en question, et non par la datasource JNDI de Tomcat. (la valeur dataSourceJNDI servant aux webapps dployes dans Tomcat). A terme, si les batchs sont dploys avec Quartz au sein dun war, ils pourront galement utiliser les datasources JNDI.

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

api-annuaire: elle regroupe tous les traitements daccs, rgles de gestion et droits concernant les donnes de la base annuaire. Elle met disposition un certain nombre de mthodes publiques pour 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 de la base dadministration. Les donnes sont principalement mises jour par la console dadmin, mais consultes par tous les projets.

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

api-recherche: elle permet dencapsuler les traitements dindexation et de recherche avec Solr. Les mthodes publiques disposition permettent de modifier les indexations de contenu propres chaque 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. Elle dpend des quatre apis prcdentes. Lorsquune fonctionnalit ncessite lappel diffrentes apis, elle permet de centraliser et ordonnancer les traitements entre les diffrentes apis, afin que cela soit transparent pour le module appelant. Les mthodes publiques disposition sont principalement de la 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 les traitements entre les diffrentes apis, mais regroupe cette fois-ci principalement les mthodes de mises jour. Elle nest donc pas disponible pour les modules, mais seulement pour les autres projets du socle (console dadmin, batchs).

api-web-droits: cette api est un peu particulire car elle nest pas constitue que dune partie back. Elle contient galement toute une partie front (interface JSP + contrleur Struts) quivalente celle des modules webapps ENT. La partie back peut tre utilise de la mme manire que les autres apis, mais lintgration totale avec le front se fait en suivant plusieurs recommandations prcises dans la spcification technique de lapi elle-mme.Cette api permet donc de centraliser toute la gestion des droits propres aux entits des modules (contenus spcifiques des webapps). Elle centralise la fois les rgles de gestion mtier et longlet dinterface commun tous les modules, permettant daffecter des droits aux personnes et groupes sur les contenus. Les actions Struts de lapi peuvent ainsi tre appeles par les webapps qui intgrent la configuration ncessaire.Le projet api-web-droits-portlet redfinit certaines classes et configurations de lapi-web-droits dans le 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 up journalier des fichiers de logs. Elle est utilise dans les lo4j.xml de chaque projet du socle et des modules web.

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

Packaging et dploiementLes apis sont toutes packages sous forme de jar que les modules peuvent ajouter en dpendance. Elles sont alors intgres au war de lapplication et dployes avec chaque webapp.

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

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

org.lilie.socleapi-portail Ajout de limport du contexte Spring de lapi dans le web.xml (ou dans une SpringFactory pour un batch)

contextConfigLocationclasspath:spring/applicationContext.xmlclasspath:spring/applicationContext_api-portail.xmlclasspath:spring/applicationContext_fmk-core-web.xml

Ajout du business api utiliser en attribut du business du module (ne pas oublier le setter pour linjection Spring, le getter nest pas ncessaire). Il faut utiliser le type interface et non limplmentation 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

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 externaliser des sources) est centralise par la classe ConfigAppli du fmk-core-ent, qui est dcrite dans la spcification technique du core. Pour les apis, lappel de la mthode ConfigAppli.getProprieteStr() doit prendre en paramtre le nom de lapi dont on veut rcuprer un paramtre de configuration. Le bean ConfigAppli peut galement tre inject par Spring dans le business du module de la mme manire que les business des apis.

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

Configuration interne des apisNommageAfin de garder une homognt entre les diffrentes apis et un bon fonctionnement lorsque plusieurs sont 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_.properties Mapping DTO/POJO avec dozer: src/main/resources/dozer/dozerMappings_.xml Chargement des map Ibatis: src/main/resources/SqlMapConfig_.xml Les fichiers de contextes Spring sont dcoups par couche et contiennent encore une fois le nom de lapi en suffixe: src/main/resources/spring/applicationContext_.xmlDe mme, quand tous les contextes Spring sont chargs en mme temps, il ne faut pas quil y ait de conflits dans les noms des beans. Le nom de lapi est donc prsent dans chacun (ou au moins dans ceux pouvant prter confusion car similaires dans chaque api): par exemple, annuaireAdapter, annuaireSqlMap ou personnePortailBusiness.

Configuration des datasourcesLa configuration de laccs aux donnes pour les apis fonctionne de la mme manire que pour les bases de donnes de chaque module ENT. Deux types de datasources diffrents sont grs systmatiquement: JNDI dfinie dans Tomcat Nom du bean spring: dataSourceJNDI Le nom JNDI utilis est valu dans le config.properties de lapipar la proprit DATABASE_JNDI. Datasource simple dfinie dans le contexte Spring: org.postgresql.ds.PGPoolingDataSource Nom du bean spring: dataSource 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_CONNECTIONSLes deux beans spring sont dclars en lazy-init afin que seul celui qui est rellement utilis au lancement soit effectivement charg.Le bean sqlMap permet de dfinir la datasource et le fichier de mapping Ibatis utiliser. Le choix de la datasource entre JNDI ou non est variabilis, afin que le module puisse dcider de manire globale pour toutes les datasources quil utilise. Cest le paramtre DATABASE_DEFINITION_TYPE qui est mettre dans le config.properties du module (et non de lapi), comme prcis dans le paragraphe prcdent.

Chargement des fichiers de configurationLe chargement du fichier config.properties se fait de manire centralise par un bean Spring customis pour lENT. Cela permet de regrouper tous les paramtres de toutes les apis ncessaires au module et dy accder de manire centralise. Chaque api prcise donc ce bean spcifique les informations qui lui sont propres:Dans le applicationContext_.xml, on dfinit le bean suivant:

configAppli: instance dun objet du core associ au CustomPropertyHolder. Cest le point dentre ensuite pour accder aux proprits dans le code fichierConfigVarEnvirStr: le nom de la variable denvironnement contenant le chemin du fichier de config. fichierConfigInterneStr : sil ny a pas de variable denvironnement (en environnement de dev), cette proprit dfinit le nom du fichier en interne dans le jar de lapi. Dans le packaging cible des releases, 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 une 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 lapi dans le code

Configuration pour les tests dune apiPour tester une api avec de simples main() Java, il faut configurer le lancement de cette classe de la mme manire quun module utilisant lapi (comme un batch utilisant lapi), afin que les donnes entrantes ncessaires lapi soient prsentes: un fichier config.properties de module contenant DATABASE_DEFINITION_TYPE un log4j.xml un fichier de contexte springde type module: applicationContext.xml, contenant un bean de chargement de fichier de configuration customis pour un module (lgrement diffrent de celui des apis):

Le prfixe et le nom de lapi ne sont pas ncessaires pour les modules, car par dfaut sans prfixe on considre toujours celui du module englobant. Dans la classe, avant de commencer le test, il faut charger le contexte Spring avec le contexte du 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");

Frameworks coreLe dossier fmk contient plusieurs projets plutt orients socles techniques. Ce sont des frameworks 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 projetsIl 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 une interface plus ou moins gnrique servant de cadre pour les applications GWT. Linterface est 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 (configuration des services RPC) fmk-ria-puremvc:framework permettant de mettre en place le concept MVC pour les applications ria de lENT. Ce projet contient les traitements et classes de rfrence dabstraction du framework externe PureMVC (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. Il sert de socle technique de dpart afin que tous les projets partent sur les mmes bases techniques: gestion des exceptions, des logs, des fichiers de configuration, classes de rfrence dabstraction des frameworks du back (Ibatis, Dozer), cache mtier

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

Un certain nombre dutilitaires sont galement disponibles afin de faciliter le dveloppement et dhomognser lutilisation des outils externes: upload de fichiers, changes de donnes entre modules (REST), rcupration des informations de connexion, cryptage des donnes, envoi demailTous 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 fmk-core-ent mais pour la partie front. Il regroupe donc : des parties de socle technique pour le front: classes de rfrence dencapsulation de Struts, gestion des pages derreur, gestion des donnes en session par le principe des conversations, centralisation des css et images des webapps, centralisation des tlds pour les librairies de tags et sitemesh

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

des utilitaires divers pour faciliter le dveloppement de la vue et du contrleur: rcupration des informations de connexion dans la request, partie contrleur et vue de lupload/download 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 le chapitre prcdent (notamment avec Spring). Le nommage des fichiers et la configuration interne est galement similaire celle des apis. Ces projets suivent les mmes rgles de dveloppement en 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 fmk-core-web pour les portlets. Il a comme dpendance fmk-core-web, et redfinit seulement les classes et configurations adapter pour les portlets, en raison surtout de la version de Struts qui diffre. Les portlets font donc rfrence celui-ci plutt qu fmk-core-web (aussi bien dans le pom.xml que dans les fichiers de configuration dimports divers).

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

PortailDeux 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 librairie disponible. Il permet de dfinir tous les traitements java spcifiques, comme linteraction avec CAS (filter, servlets de login/logout), les traitements daffichage du bandeau, linteraction avec XitiLa gestion des fichiers de configuration log4j.xml et config.properties du projet est la mme que pour les modulesENT (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.

SolrCertains modules, pas tous, indexent des donnes dans un moteur de recherche afin de pouvoir tre 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 diffrents contenus, aux besoins de lENT. En plus de quelques modifications/ajouts du code source, ce projet sert 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.

JabberLe dossier openfire contient plusieurs projets relatifs limplmentation du serveur Jabber pour les ENT. Jabber est le protocole standard pour les communications de type messagerie instantane. Nous utilisons le serveur Openfire comme implmentation de la partie serveur du protocole.Cependant, afin de bien sintgrer notre socle et plus particulirement lannuaire, des adaptations du serveur ont t ncessaires: openfire-custom: customisation des sources du serveur pour pointer sur lannuaire ENT par lintermdiaire des apis ENT. Les comptes de chat dcoulent alors directement des utilisateurs de 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 tant prt, dautres pourraient ventuellement facilement tre ajouts dans lavenir: le contenu, le packaging et le dploiement dun plugin suivent des rgles dfinies par Openfire. Maven nous permet de grer cela au moment du build. plugin-search-custom: adaptation du plugin de recherche des comptes pour pointer sur lannuaire par lintermdiaire des apis ENT. plugin-entpacketfilter: permet de filtrer tous les paquets envoys entre les clients et serveurs Jabber en fonction des droits des utilisateurs dfinis par lapi-annuaire. Linterface du client chat ENT empche dj les communications non autorises, mais ce plugin est une scurit dans le cas dutilisation dautres clients de chat par les utilisateurs.

Toujours en suivant le principe de cohrence entre tous les projets ENT, le chargement des fichiers de 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.

Web ServicesPlusieurs services externes proposent des web services pour accder leurs donnes. La gnration des services Java partir des WSDL fournis a t centralise dans le dossier ws. Cela permet de regrouper les projets ayant besoin des mmes dpendances relatives aux web services:1. ws-prt: web services du portail Liferay. Permet de mettre jour le portail lors des modifications de donnes dans lannuaire.1. 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:

${basedir}/src/main/resources/wsdl

org.codehaus.mojoaxistools-maven-plugin${dir.wsdl}jirasoapservice-v2.wsdlorg.lilie.socle.wsjiraclienttruetruefalseprocess-resourceswsdl2java

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

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

Ajout dun nouveau moduleLors de lajout dun nouveau module, il faut:

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

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

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

Fonctionnement gnralLa console est compose de trois projets dans le dossier ria/ria-admin. Cest une webapp client riche dveloppe en GWT et PureMVC. Elle est dploye de la mme manire que les webapps des diffrents modules. Elle peut accder aux apis du socle au besoin (sans forcment passer par lapi-portail). Le code de 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.

Projet modle pour cration dune webappPrincipeLoutil Maven permet de crer des projets template servant de base de dpart pour la cration dun nouveau projet. Ceux-ci sappellent des archetype. lls permettent de prdfinir larborescence du projet, 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 de recrer un projet de zro chaque fois. Les dpendances et configurations de base dun module sont automatiquement cres laide de larchetype. Pour linstant, il nexiste quun modle pour les modules en client lger (Struts 2).

Utilisation pour cration dun moduleLarchetype est un artifact Maven dploy comme toutes les autres librairies, avec son groupId et sa version:org.lilie.services.archetypetem-web-archetype

En ligne de commande, se placer dans le workspace l o lon veut crer le projet Utiliser la commande: mvn archetype:generateLe catalogue utilis peut tre prcis (voir la documentation en ligne du maven-archetype-plugin pour les dtails), sinon il est demand en prompt. On choisit larchetype parmi ceux proposs par la commande, puis on saisit les informations suivantes demandes: groupId: org.lilie.services artifactId: web- version en cours package: org.lilie.services.web Le projet est alors cr. Toutes les configurations sont dj pr-remplies. Les noms de packages, 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 dans applicationContext.xml. Il faut changer les noms des variables denvironnement du config et du log4j pour les adapater avec le nom du module. Pour importer le projet dans Eclipse, ne pas oublier de supprimer dabord le dossier .settings sil existe dans le projet nouvellement cr.

Modification de larchetypeLe 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)

Tableau de correspondance des fonctionnalitsVoici un tableau faisant correspondre les fonctionnalits dcrites dans le premier chapitre au dcoupage technique des projets.

FONCTIONNALITEPROJETS CONCERNES

Scurit

authentificationcas

SSOcas

Droits daccs portailprt-custom

Outils de scurisation des urls httpapi-web-droits, api-annuaire

Outil de cryptagefmk-core-ent

Annuaire

Alimentationbat-alimentation, bat-importfederateur

Synchronisation portailbat-initportail

Encapsulation appels portailapi-liferay (par api-portail)

Accs aux donnes de lannuaireapi-annuaire (par api-portail)

RG et droits sur lannuaireapi-annuaire

Donnes de connexionapi-annuaire

Administration

Visualisation/export annuaireria-admin

Cration de groupes supplmentairesria-admin

Gestion de comptes invits et administrateursria-admin

Activation/dsactivation des modulesria-admin

Paramtrage et droits d'accs aux modules selon les profilsria-admin

Remonte d'incidentsria-admin

Services d'accs ces donnes de paramtrage utilisables par les modulesapi-admin (api-portail)

Socles techniques

abstraction frameworks et classes de rfrence: persistance Ibatis, mtierfmk-core-ent

Abstraction frameworks et classes de rfrence: contrleur/vue (Struts2)fmk-core-web

Abstraction frameworks et classes de rfrence: contrleur/vue (GWT, PureMVC)fmk-ria-ihm, fmk-ria-puremvc

gestion des exceptionsfmk-core-ent

gestion des fichiers de configurationfmk-core-ent

gestion du principe de conversations pour les donnes en sessionfmk-core-web

cache mtierfmk-core-ent

gestion des logsfmk-core-ent

centralisation des feuilles de style ENTfmk-core-web

template de gnration dun projet moduletem-web

Utilitaires

Rcupration informations utilisateur connectfmk-core-web, fmk-core-ent

Moteur de rechercheapi-recherche (par api-portail), solr-custom

Gestion des droits sur les contenus des modulesapi-web-droits

Gestion des changes de donnes entre modulesfmk-core-ent

Gestion des fichiers uploads sur le serveur applicatiffmk-core-ent, fmk-core-web

Utilitaire de cryptage MD5 et AESfmk-core-ent

Envoi demailsfmk-core-ent

Api dinterfaage avec Jiraapi-jira

Customisation dun serveur Jabber par rapport lannuaire ENTopenfire

Interactions et flux entre les projets Point de dpart: fmk-core-ent est le projet central commun tous les projets. Il sert de framework de base pour tous les autres qui ont une dpendance sur lui. Il na donc aucune dpendance sur les autres projets ENT. Le projet fmk-core-web dpend de fmk-core-ent et ltend pour complter la partie web. Les autres projets du socle ne dpendent pas de ce projet qui est fait pour les modules. Accs aux apis: Les fonctionnalits des apis ne sont pas accdes en direct par les modules mais par lintermdiaire de lapi-portail qui centralise le tout et sert de faade pour proposer seulement ce qui est utile. Les projets du socle (console dadmin, batchs, cas) peuvent par contre accder directement aux apis sous-jacentes sans passer par la faade. Les apis ont par contre des dpendances entre elles: lapi-portail pointe donc sur les quatres apis proposant des fonctionnalits aux modules: api-recherche, api-annuaire, api-admin, api-liferay lapi-portail-gestion a les mmes dpendances que lapi-portail. Elle est utilise par les projets du socle (console dadmin, batchs) pour partager des traitements communs dappel aux apis sous-jacentes. lapi-web-droits, qui est une api galement de front, est un niveau au dessus, comme les modules, car elle dpend de ce que propose lapi-portail dans son ensemble les autres apis ne communiquent pas entre elles, elles grent chacune leurs fonctionnalits spcifiques. Les projets customisation de serveurs (openfire, prt-custom, solr-custom) sont au dessus des apis dont ils se servent pour intgrer notamment les donnes annuaire. Interactions avec les modules: Les projets ws ne sont pas accds directement par les modules. Ils sont encapsuls par les apis (api-liferay, api-jira). Les projets du socle naccdent pas aux modules. Aucun flux nest prvu dans ce sens l par larchitecture mise en place. Ce sont les modules qui utilisent le socle. De mme pour le cas particulier de la webapp de la console dadmin: lapi-admin permet aux modules daccder aux donnes de la console, mais la console nappelle pas les diffrents modules qui grent tous seuls leurs donnes spcifiques. Les paramtrages dactivation et droits par profil sont bien des donnes internes la console, consultables par les modules. Les modules sont au plus haut niveau et dpendent des diffrents projets du socle, quils embarquent dans leur war pour le dploiement. Les modules sont indpendants les uns des autres. Pour des besoins ponctuels dchanges de donnes entre ces modules distants, des flux de type HTTP sont prvus: les traitements mtiers restent du ct du module contenant les donnes concernes, qui met disposition des services REST pour les autres modules.

SPECTECH-socle-applicatif.docPage 5 de 26