ePims

Le rôle de eP-Back est donc, d’une part, de renseigner les différents champs de ePIMS lors de la copie des analyses et, d’autre part, de relire ces informations pour permettre à l’utilisateur de nettoyer les PC des instruments des analyses déjà sauvegardées.

Cette communication entre eP-Back et la BD (donc eP-Core) se fait via les !WebService (cf module eP-!WebService). La définition des objets et des services est faite dans le module eP-CoL (voir doc spécifique pour plus d'information)

Le transfert des données et donc le renseignement de la base de données ne peuvent être faits que si le statut de l'analyse est valide (voir chapitre précédent). D'autres vérifications sont néanmoins faites au moment de la demande de transfert des données :

• l'instrument d'acquisition est référencé dans la base,
• le répertoire destination est accessible.

Pour le renseignement des informations dans le système ePims : La solution choisie est de définir une interface, IEPSystemDataProvider, permettant l'accès aux données du systeme ePims. La (seule) implémentation de cette interface, WSSystemDataProvider, utilisant les WebService pour la réalisation des services. Voir le schéma ci-dessous.

Les accès actuels via les services eP-Core sont :

• A partir d'un nom d'échantillon obtenir son étude d'appartenance
• getAnalysisStatus (A compléter ! )
• A partir du nom d'un étude ou d'un type d'acquisition, obtenir le chemin sur le PIMS_ROOT
• Récupérer les objets Spectrometers / Actor depuis les noms ⇒ mais c'est pour les utiliser pour la création d'une acquisition !
• Création d'acquisitions
• Suppression des demandes de passage en masse

La première étape est de modifier BackPimsUtil pour que tous les accès à eP-Core se fasse dans cette classe et non via les services obtenue par BackPimsUtil. Ceci permettra de définir quels sont les “services” nécessaire à eP-Back. Ces services doivent être rendu par l'implémentation de IEPSystemDataProvider qui utilisera eP-!WebServices mais ne devront pas nécessairement être défini dans les WebServices

Suite à cette première étape, il en découle les besoins suivants :

1. En lecture :
   • Obtenir le chemin absolue vers le répertoire d'une étude
     • A mieux définir : comment obtenir le chemin pour les différents types de données (spectres / raw / …)
   • Obtenir le chemin absolue vers le répertoire relatif aux données partagées, en fonction de
     • la date d'acquisition
     • l'instrument sur lequel elle a été réalisée
   • Obtenir les informations sur un échantillon à partir de son nom
     • si il existe !
     • la nomenclature de l'étude de rattachement
   • Obtenir les information sur un instrument, à partie de son nom
     • si il existe
     • son model
   • Obtenir les informations relatives à une acquisition, à partir de son nom
     • instrument sur lequel elle a été réalisée
     • son type (recherche, controle…)
     • l'échantillon (ou les échantillons) qui a été analysé ainsi que l'étude de rattachement
   • Obtenir les informations sur une étude, en fonction de sa nomenclature (case insensitive ou non !)
     • si elle existe
     • si elle est en cours ou close
2. En écriture :
   • Création d'une acquisition et acquisitionResult associé. Les informations devant transiter sont :
     • nom de l'acquisition
     • nom de l'échantillon analysé
     • nom de l'instrument
     • nom de l'opérateur
     • nom du fichier
     • taille du fichier
     • durée de l'acquisition

Cette méthode devra dorénavent prendre en charge les services suivants :

• Changement du status de l'échantillon associé à l'acquisition
  • changement de status ou d'étape … en fonction des règles spécifiés au niveau ePims/eP-Web
• Suppression de la demande de passage en masse pour l'échantillon

Le code interne d'eP-Back n'accède que à l'interfaces IEPSystemDataProvider.

(Continuez vers la suite de la documentation ⇒ epBackNote)