Differences

This shows you the differences between two versions of the page.

--- wiki:epims4_0:developer:epbackdb [2008/10/02 10:21]
127.0.0.1 édition externe
+++ wiki:epims4_0:developer:epbackdb [2009/01/21 08:24] (current)
132.168.73.247
@@ Line 1: / Line 1: @@
-===== Renseignement de la BD =====
+===== Communication avec 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.
-Le renseignement de la base à partir des informations lues sur l’instrument est d’autant plus évident que les instruments ne sont pas obligatoirement accessible depuis le serveur ePims. De plus, les liens entre les analyses et les éventuelles informations de paramétrage ou les liens entre les différents types d’analyses ne sont identifiables que tant que les analyses sont sur les instruments. Une fois les analyses supprimées, il devient moins évident de retrouver les fichiers de paramétrages utilisés et le risque que ces fichiers soient supprimés est non nul.
+===== Introduction =====
-{{ epb_bd_schema.png }}
+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.
-**Figure 4:  Extrait du schéma de la BD de ePIMS**
+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 status 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 :
+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.
-Si tout est OK, après la copie des données les modifications dans la base sont :
+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.
+==== Identification des services nécessaires ====
+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 :
+  - 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
+  - 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
+==== Implémentation des services nécessaires ====
+Le code interne d'eP-Back n'accède que à l'interfaces IEPSystemDataProvider.
-    * **acquisition_result** représente les fichiers résultats d’une acquisition. Un enregistrement est créé avec les informations lues dans Analysis.
-    * **acquisition**, cette table représente l’analyse elle-même. Elle fait donc le lien entre l’échantillon analysé (via les tables protocol_application et treatments_application), le résultat de l’analyse (l’objet acquisition_result créé par eP-Back) et l’instrument sur lequel a été fait l’analyse (référence une des instances de Spectrometer). On spécifie également dans cette table, la nature de l’acquisition. A savoir, l’acquisition est-elle réalisée pour un contrôle qualité ou dans le cadre de l’activité recherche.  Dans le cas d’acquisitions spéciales, c'est-à-dire autre que celles réalisées pour la recherche, il n’y a pas d’objet sample associé. D’autres informations comme le protocole d’acquisition utilisé pourront également être, par la suite, renseignées par eP-Back. Le champ name, la date de l’acquisition et la description sont lues dans Analysis.
-    * **sample** représente l’échantillon qui a subi l’analyse. L'enregistrement correspondant existe déjà dans la BD.
-    * **mass_planning** (non représenté ci-dessus), l'enregistrement correspondant à la demande d'analyse. Celui-ci est supprimé de la table.
-Afin de permettre de transférer des acquisitions recherche dont l'échantillon correspondant n'a pas été créé dans la base, il est possible de spécifié comme nom de l'échantillon : "old" (Analysis.UNKNOWN_SAMPLE_CODE) .  Dans ce cas, aucune vérification n'est faite sur l'échantillon lors de la détermination du status de l'analyse et lors du transfert des données on créé un nouvel enregistrement de sample :
-    * **sample** Création d'un enregistrement ‘par defaut’ de cette table afin de faire le lien entre l'étude et l'acquisition. Le champ study est renseigné à partir des informations lues dans l’objet Analyse Le champ name suit la nomenclature suivante <nomenclatureEtude>_xxx (xxx étant un indice). Enfin, le status est positionné à Analysed. Les autres champs ne sont pas renseignés.
+{{ .:ep-col_back.png }}
 \\

ePims

User Tools

Site Tools

Differences

Page Tools