Les specifs complète (lors de l'initialisation de la fonctionnalité !) sont visibles sur le Bloc Note de RedMine

Permettre d'uploader des fichiers (autres que les raws) et de sauvegarder un minimum d'information dans la BD. Les fichiers uploadés devront être attachés à une entité (Etude, Echantillon, Programme, …)

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.

L'idée est de conserver cette table attached_file mais de n'avoir qu'une autre table qui gère le lien entre attached_file et l'objet d'appartenance du fichier. Cette seconde table (file_link) a donc un champ(clé étrangère) non nulle vers attached_file et d'autre champs permettant de retrouver l'objet lié: - le champs attached_file n'est pas UNIQUE. Par conséquent, un fichier peut être rattaché à plusieurs entités et donc, par exemple, un scan de gel peut être rattaché à plusieurs échantillons. De plus, cette règle permet d'intégrer les acquisition_result dans ce schéma. En effet, la table acquisition_result est supprimé et les raw files sont référencés via les tables attached_file et file_link qui référence l'acquisition associée. - le champs associated_entity : nom de la table de l'objet associé au fichier - le champs id_FK utilisé pour référencer l'élément de la table associated_entity si sa clé primaire est de type int (cas de study, project, …) - le champs name_FK utilisé pour référencer l'élément de la table associated_entity si sa clé primaire est de type varchar (cas de sample,…)

Les fichiers associés peuvent être de tout type (rapport client, résultat d'identification, mail…), afin d'identifier le contenu des fichiers, un ou plusieurs tags peuvent être référencés. Un attribut index est également ajouté à la table file_link (non représenté ici) afin d'ordonner les tags !

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:

Objets Java issu du mapping du nouveau modèle de la BD

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

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).

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. -)

Voir la documentation d'admin

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.

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