Differences

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

--- wiki:epims4_0:developer:epcorefilestransfer [2009/01/21 11:01]
132.168.73.247 créée
+++ wiki:epims4_0:developer:epcorefilestransfer [2009/01/21 11:33] (current)
132.168.73.247
@@ Line 8: / Line 8: @@
-===== Modèle de la BD =====
+===== Modèle de la BD/ Mappings =====
 Modification de la table attached_file défini dans la BD. Lorsque l'on veut associer cette table à un objet de la BD, il fallait créer une autre table (study_attached_file / sample_attached_file) qui gérait le lien.
@@ Line 25: / Line 25: @@
 Si les informations conservées au niveau des tables attached_file et, surtout, de file_link ne sont pas très lisible, le mapping hibernate utilisé en fonction de ces règles permet d'obtenir la hiérarchie de classes suivante:
+{{ .:xfer_model.png }}
+**Objets Java issu du mapping du nouveau modèle de la BD**
+===== Enregistrement des informations =====
+==== Objectif ====
+Le transfert des fichiers dans ePims doit au final avoir pour effet :
+    * de copier chaque fichier sur le repository ePims à un endroit spécifique selon son type et selon l'entité à laquelle il se rapporte.
+    * L'enregistrement du fichier dans la BD ePims
+==== Mode de fonctionnement ====
+Sur le PIMS_ROOT une drop_zone est définie et est accessible en lecture / écriture via FTP. La première phase de l'enregistrement consiste donc à transférer les fichiers (via FTP donc) dans cette zone. Pour éviter tout conflit de transfert, les fichiers ne sont pas transférés directement dans la drop_zone mais dans un sous répertoire qui est généré à la demande (par exemple en utilisant le date courante).
+Dans un second temps, en fonction des informations recueillies par le système, les fichiers sont déplacés de la drop_zone vers l'emplacement définitif et la BD est renseignée.
+Les informations recueillies par le système sont les mêmes que celles qui seront sauvegardées dans la BD, à savoir l'entité à laquelle le fichier est rattachée et un ensemble de tag. Les deux options suivantes seront conjointement utilisées afin de permettre une flexibilité à l'utilisation de ce service et de permettre une reprise sur erreur :
+    * dépot d'un fichier de description (voir eP-CoL) dans la drop_zone avec les nouveaux fichiers - :!: Non Implémenté encore -
+    * envoi d'un message vers ePims qui déclare que de nouveaux fichiers sont disponibles dans la drop_zone. Le message contient toutes les informations nécessaires (celles présentes dans le fichier de description).
+==== Coté serveur ====
+Lors de la réception du message par le serveur, celui-ci renomme le répertoire temporaire de la drop_zone (appelons-le xxxyyy) en xxxyyy_lock. De cette manière, il n'y a plus de transfert possible dans ce répertoire tant qu'il est locké par le serveur. En fin de traitement, si tous les fichiers ont été ventilés, le répertoire temporaire est supprimé. Sinon, on restore le nom d'origine du répertoire et on laisse dedans les fichiers qui n'ont pas été ventilés (- :!: Non Implémenté encore : ainsi que le fichier de description modifié . Des informations supplémentaires, tel que quels sont les fichiers non traités et pourquoi, sont rajoutées au fichier de description. -)
+==== Structure du PIMS_ROOT ====
+Voir la documentation [[..:admin:epimsstructure | d'admin]]
+==== Implémentation ====
+La définition des objets transitant via les messages (ici TransferMessage) sont dans eP-CoL !
+Dans eP-Core on définit la classe ''cea.edyp.epims.messages.JMSTransferListener'' qui implémente MessageListener et qui écoute sur le Topic JMS ''TransferTopic''.
+{{ .:xfer_sequencel.png }}
+**Diagramme de séquence lors de la réception d'un message**
+Règles de dispatch
+- :!: Non Implémenté encore - Des tags sont prédéfinis au niveau d'eP-Admin
+Seuls les tags existants sont autorisés. Les règles de dispatch sont basés sur le tag, l'entité associée et éventuellement les caractéristiques du fichier.
+    * Pour chaque fichier à transférer, au moins un tag doit être défini et une entité désignée.
+    * Les règles de dispatch s'applique sur le 1er tag. L'ordre de définition des tags est donc important.
+    * Les règles de dispatch s'applique sur la 1ere entité associé. L'ordre de définition des entités est donc important. En effet, un fichier peut être associé à plusieurs entités (échantillons le plus souvent). A l'utilisateur d'être un minimum cohérent.
+Le dispatch se fait en plusieurs étapes :
+    * Identification du répertoire <entity> correspondant à l'entité associé. Donc uniquement dépendant de (la 1ere) l'entité associée au fichier.
+    * Création si nécessaire du répertoire <entity>/data/<TAG_NAME>. Pour certaines entités, aucun sous répertoire n'est créé. C'est le service de dispatch et plus précisément le service retournant le path pour un objet <entité lié - fichier - tag> qui décide de la règle. (IFileManager)
+    * Copie du fichier dans ce répertoire
+    * Enregistrement des informations dans la BD

ePims

User Tools

Site Tools

Differences

Page Tools