Ce guide d’implémentation décrit l’implémentation choisie pour la partie présentation de l’application web du système ePims.

Figure 1 Architecture globale de l’application

Comme indiqué sur ce schéma ( se référer aux spécifications pour plus d’informations) :

• Les JSP/JSF sont utilisés pour la partie présentation.
• Au niveau de la logique applicative on utilise le framework Spring qui est un conteneur léger et qui permet, d’une part, d’isoler les différentes technologies utilisées et ainsi de faciliter la substitution d’une implémentation par une autre. Et, d’autre part, Spring prend en charge la partie transactionnelle de O/RM.
• Hibernate a été choisi pour la partie O/R Mapping. Ce framework a, entre autres, l’avantage de s’interconnecter facilement avec Spring.

Du côté de la couche présentation, on trouve :

• Les backing beans, définis dans le package view, sont utilisés par JSF pour présenter les données. Ces beans correspondent, en principe, aux objets du package BO, ils définissent des accesseurs aux différentes propriétés ainsi que des méthodes de type action. De plus, ces objets doivent avoir accès à l’objet ServiceLocator afin de manipuler les données du modèle.

Le projet eP-Web est développé sous MyEclipse, voir le guide de développement pour plus de détails sur l’environnement de développement nécessaire.

Il existe deux fichiers de taches Ant : build.xml et build-ivy.xml. Pour tout ce qui concerne ivy (resolve pour récupérer les librairies nécessaire …) il faut utiliser build-ivy.xml.

Sinon, dans build.xml, il existe des cibles spécifique à la distribution en mode production et des cibles spécifiques au développement. On retrouve donc, entre autre, les cibles

• configure.dist : Configure l'application pour le déploiement en mode production (copie des fichiers de configutations, mise en place de librairies…).
• configure.dev : Même configuration que précédement mais utilise les fichiers de configuration pour exécuter le mode développement.
• configure.test : Même configuration que précédement mais pour le mode test (utilisation du serveur de test : image du serveur de prod)
• dist : appel configure.dist et crée le .war pour la prod.
• dist.test : appel de configure.test et crée le .war pour le déploiement sur le serveur de test..

Attention : Les différentes cibles définies ici sont dédiées à un environnement utilisant un IDE. En effet, il n'y a pas la compilation ou de définition de classpath !

Le fichier eP-Core.properties (./resources/main) contient les propriétés utilisées par eP-Core et qui peuvent nécessiter d’être redéfinies. L’utilisation d’un fichier permet de modifier ces propriétés sans avoir à recompiler l’application. D'autre part, chaque projet qui utilise eP-Core peut spécifier un fichier de propriétés user dans lequel il aura redéfini tout ou partie des propriétés. Lorsque le programme utilisateur de eP-Core a redéfini des propriétés il doit le spécifier à eP-Core. Pour cela il doit :

• Définir une propriété système, ResourceManager.USER_RESOURCE_PROPERTY, qui a pour valeur le nom du fichier properties où sont redéfinis les propriétés
• Demander au ResourceManager de lire ce fichier : ResourceManager.getInstance().loadUserRB() ;

  UNDEF_DIR_NAME=_UNCLASS_   1.
  PIMS_ROOT=  /local/path/to/pims_root/   2.
  PIMS_REPOSITORY_1=  a   3.
  PIMS_REPOSITORY_2=  b   4.
  PIMS_REPOSITORY_3=  c   5.
  PIMS_SHARE=  b/share   6.
  PIMS_ARCHIVE=  transfert/archive   7.
  PIMS_SYSTEM = adm   8.
  PIMS_ARCHIVE_FILE =  path/relative/to/pims_system/studyArchived.txt   9.

1. Nom des répertoires, sur le SAN, contenant les projets/études n’appartenant pas à un programme/projet.
2. Répertoire racine où les données de Pims peuvent être trouvées
3. Répertoires, depuis PIMS_ROOT, dans lesquels les données relatives aux études sont stockées.
4. Répertoires, depuis PIMS_ROOT, dans lesquels les données relatives aux études sont stockées.
5. Répertoires, depuis PIMS_ROOT, dans lesquels les données relatives aux études sont stockées.
6. Répertoire contenant les données dites partagées, n’appartenant pas spécifiquement à une étude. On retrouve ici, par exemple, les acquisitions de contrôles réalisées sur les instruments.
7. Répertoire, depuis PIMS_ROOT, dans lequel sont transférés les données qui sont à archiver (à copier sur bandes)
8. Répertoire, depuis PIMS_ROOT, dans lequel les données “administratives” et systèmes sont sauvegardées (logs files…)
9. Fichier copié dans les répertoires des études lorsque celles-ci sont archivées afin d’en avertir l’utilisateur. Ce fichier est donné avec le projet. Il doit contenir un tag « #DATE#. » qui sera remplacé par la date effective à laquelle l’étude a été archivée. Le chemin spécifié est relatif à celui spécifié pour PIMS_SYSTEM

L'accès aux services fournis par eP-Core se fait via la classe ServiceLocator. Cette classe contient, pour chaque service, une méthode getter (sous la forme getXXX(): XXX nom du service ) retournant une instance du service en question. Exemple de méthodes : getStudyService() retourne une instance d'un objet donnant accès à tous les services concernant les études.

Plusieurs librairies sont utilisées par eP-Web. Certaines sont des librairies développées au sein du laboratoire, d’autres sont des librairies open source. Les librairies utilisées peuvent réclamer la présence de librairies tierces et deux librairies peuvent éventuellement nécessiter des versions différentes d’une même librairie.

Afin de gérer les différentes librairies utilisées, ainsi que les différentes versions de celles-ci, le gestionnaire de dépendance de librairies Java IVY est utilisé.

Les librairies sous le serveur JSP Tomcat sont organisées dans plusieurs répertoires. Sous chacun d’eux on retrouve un sous répertoire lib contenant les .jar et un sous répertoire classes contenant les classes compilées Java.

L’organisation et l’accessibilité des libraires est la suivante :

• Les ressources sous TOMCAT/server ne sont visibles que par TOMCAT.
• Les ressources sous TOMCAT/common sont accessibles à TOMCAT et aux différentes applications WEB.
• Les ressources sous TOMCAT/shared sont accessibles à toutes les applications web mais pas au serveur TOMCAT.
• Les ressources spécifiques à un projet sont sous le répertoire WEB-INF du projet en question. (WEB-INF/lib pour les jars et WEB-INF/classes pour les classes)

Par conséquent, lors de la recherche d’une ressource, l’ordre est le suivant :

• /WEB-INF/classes de l’application web
• /WEB-INF/lib/*.jar de l’application web
• TOMCAT/common/classes
• TOMCAT /common/endorsed/*.jar
• TOMCAT /common/lib/*.jar
• TOMCAT /shared/classes
• TOMCAT /shared/lib/*.jar

Le projet se compose en trois grandes parties : la parties Interfaces , la partie Logique applicative, et la partie contrôle. Voici le contenu de chacune d'elles:

Cette partie concerne toutes les pages JSP qui donnent accès aux différentes fonctions. Il existe deux types de pages: pages accessibles par tous les utilisateurs , et pages accessibles uniquement par les utilisateurs ayant le statut administrateur. Ces dernières sont différenciées des pages accessibles pas tous les utilisateurs par le fait qu'elles soient dans un répertoire à part (epims/pat), de telle sort que lorsqu'un utilisateur non administrateur se connecte, les pages “admin”, c'est à dire celles qui se trouvent dans le répertoire pat, ne sont pas accéssibles.

Cette partie est constituée en trois types de classes :

1. les Backing Beans,définis dans le package view, sont utilisés par JSF pour présenter les données;
2. les classes utiles, définis dans le package view, qui sont les suivantes : les classes Convertor, les Component, les classes d'export, les Validator pour la vérification des données avant de les insérer dans la base de données;
3. les fichiers de modélisation pour les rapports d'export de JasperReport , définis dans le package report,

Cette partie concerne tous les fichiers de configuration qui permettent : la configuration des Backing Bean (faces-managed-bean.xml), des navigations des pages JSP (faces-navigation.xml), configurations Spring (springAppContext.xml, springDataSource.xml) ainsi que des components utilisés dans l'application.

Nous allons lister ici quelques règles de développement que nous utilisons (elles ne sont peut etre pas optimales !) afin, d'une part d'aider à la lecture du code et d'autre part de permettre une certaine homogénisation du code développé par plusieurs personnnes…. Dans le code JAVA

• Convention Java classique : camelCase pour les noms de classes/variables…
• L'accès a d'autres beans via spring ce fait en utilisant les noms des beans définis dans BeanNames
• ParameterNames : définition des noms des paramètres qui transitent entre les pages JSF et les classes JAVA. Voir paragraphe suivant.
• PimsResources : défintion des messages utilisés dans le code
• ValuesResources : definition de constante utilisé dans le code (non partagé avec les pages JSF comme ParameterNames).
• Certaines méthodes des managed bean sont des actions des pages JSF et doivent donc retourner des String utilisées pour la navigation. Toutes ces retours sont déclarés en en-tête des bean comme constante NAV_XXXX
• GenericBean : deux managed beans generique EntityGenericBean et SpectrometerGenericBean définissent des propriétés …. générique : la liste de tous les acteurs, la liste des valeurs autorisées pour xxx, une getter methode pour chaque valeur de xxx
  • exemple :
    • getResponsibles : Liste des acteurs, pouvant être utiliséà plusieurs endroits
    • getSampleNamePatterns() : Liste des patterns autorisés pour les sampleName : Pas utilisé à bcp d'endroit mais propriétés constantes….
    • getAcquisitionProcessType : permet de faire des tests dans les pages…

Dans les pages JSF

• les noms des id sont composés avec des _ : <h:form id=“sample_reception_form”…
• Les subview pouvant être utilisés dans plusieurs pages sont sous ePims/subviews

Les backing beans sont utilisés pour la partie présentation. Ce sont eux qui contiennent les informations à l’afficher et les actions déclenchées par l’utilisateur. Il est parfois nécessaire de passer un paramètre de la page JSP au backing bean, pour cela on utilise la requête HTTP. Afin d’éviter les erreurs dans la dénomination des propriétés, on utilise une classe contenant la déclaration des noms des propriétés utilisées par les différents beans/pages. Il est également nécessaire de spécifier pour chacun de ces noms, une méthode get, utilisée dans les pages JSP. Par exemple:

 Class Names {
    public static final String PROGRAM_ID = « program_id » ;
    public String get ProgramId(){
       return PROGRAM_ID;
    }
 } 

Dans les beans, l’accès à la valeur se fait

1. soit en utilisant la variable :

   actionMethod(){
    FacesUtil.getRequestParameter(ParameterNames.PROGRAM_ID) ;
    …
   }

2. soit en spécifiant le lien entre le paramètre et une propriété du bean au niveau du fichier de configuration de JSF faces-managed-bean.xml :

     <managed-property>
          <property-name>id</property-name>
          <value>#{param.program_id}</value>
    </managed-property>

Dans les JSP:

  <f:param id=”progId” name=”#{ParamConstant.programId}” value=”2”/> 

Il est bien entendu nécessaire d’avoir spécifié le bean ParamConstant de type ParameterNames dans le fichier faces-managed-bean.xml.