2 Scenarios d'architecture de SI de Laboratoire INTEROPERABILITE

1. 2 Scenarios d'architecture de SI de Laboratoire INTEROPERABILITE 1/ Le cœur SI Labo est simplement constitué du Site Web Internet (sur gestionnaire de contenu CMS) 2/ Le cœur SI Labo est double: - Logiciel Intranet de gestion de laboratoire - Site Web Internet (sur gestionnaire de contenu CMS) Quelles sont les possibilités / contraintes d’échanges entre les SI ? - au sein du SI labo (interne) • avec les SI externes Etudes de cas

2. Légende WS Web Services R Requête vers … S Synchronisation Envoi data Scénario 1 Cœur SI Labo = Site Web (CMS) seul + … applications connexes Services des personnels Direction de composante NABUCO XLAB LABINTEL SI local => membres SI institutionnels => personnel, activité, budget, publications BD Harpège SIFAC GRAAL (AMUE) SILAB (CNRS) DIALOG (CNRS) HAL Annuaire LDAP WS WS R S R R Site Internet (DB / CMS) = Coeur SI Labo Utiliser les WS depuis le CMS Pour gérer le type de données voulu (par ex. les publications), on pourra : - soit utiliser le cadre du CMS, en créant un nouveau type de données internes (mais est-ce possible ?), - soit, de manière plus réaliste, travailler hors la structure de la DB du CMS en créant des tables indépendantes, calquées sur celles du SI externe, avec les méthodes d'accès nécessaires (CRU). On synchronisera régulièrement ces tables de DB avec le SI externe (HAL par ex.), de façon que le CMS réponde aux requêtes clients directement à partir de sa DB. Pourrait-on obtenir ainsi une interopérabilité CMS-indépendante - au niveau ‘modèle’ de l'architecture MVC ? Oui, si … les méthodes d'accès ne passent par l’API du CMS. Applications Internes connexes Gestion activité scientifique Badges d'entrée Gestion usagers du réseau Réservations Organisation événements Gestion des stocks Gestions des prêts DB du CMS [ + tables annexes ? ] Le CMS devra intégrer des fonctions d'échanges (à développer !) avec à la fois l'annuaire LDAP, HAL, et … GRAAL ?, pour être à même de présenter la liste du personnel, des productions et des projets.

3. Légende WS Web Services R Requête vers … S Synchronisation Envoi data Scénario 2 Cœur SI Labo = Intranet + Site Web (CMS) … et applications connexes NABUCO XLAB LABINTEL SI institutionnels => personnel, activité, budget, publications SI local => membres SIFAC GRAAL (AMUE) SILAB (CNRS) DIALOG (CNRS) HAL Annuaire LDAP WS WS S R R R Applications Internes connexes Gestion activité scientifique Badges d'entrée Gestion usagers du réseau Réservations Organisation événements Gestion de stocks Gestions des prêts BD des personnelsHarpège Intranet = Coeur SI Labo (AIGLe, LEST) Différents cas de figure d’échanges possibles g : Le SI intranet génère des données pour le CMS : a/ Le SI intranet NOURRIT la DB du CMS/Web * (-)dépendant des évolutions du CMS (upgrades) b/ ou génère des pages html statiques (par ex., il génère la liste des membres pour l'annuaire Web ) ** Le SI intranet répond aux requêtes du CMS : i : le CMS Web --- interroge ----> le SI intra (ex.: LEST, AIGLe) Le CMS cherche les réponses aux requêtes de ses clients en interrogeant le SI intra (rien dans la DB du CMS) (+) Peut évoluer vers les WS du SI … externe (+) SIMPLE s : le CMS Web --- synchronise ----> le SI intra (ex.: LEST, AIGLe) Synchro régulière de la DB du CMS avec le SI intra (+) IDEM (-) Plus complexe (DB et synchro) g i s Site Internet (DB / CMS) DB spécifique avec seulement des données PUBLIQUES Rapport d'activité Des pages Web peuvent être générées par le SI Labo, par ex. l'annuaire par LEST. ** ExtraLEST * Fait dans AIGLe pour SPIP et FastBoil

4. Saisie y x x « alimente » y 1Non géré 2Copier-coller manuel Saisie 4 Web Services D'une situation couramment rencontrée pour la gestion des publications ... Copier-coller manuel EndNote CMS (site internet) Système de Gestion de Labo (b) 3Programme « moulinette » (a) H A L ... à une architecture utilisant les Web services de HAL pour alimenter le SI interne Comment faire la transition vers les WS pour ensuite alimenter (ou moissonner) HAL ? (a). d’abord nourrir HAL par un import complet de la collection : • saisir directement toutes les publications dans HAL (saisie assistée ?...) • ou se procurer un programme « moulinette » à jour pour faire l’import massif dans HAL (b). puis intégrer dans le CMS du labo les fonctions d’appel aux Web services de HAL=> pour la saisie utiliser : - soit l’interface de HAL (a), puis nourrir le CMS depuis HAL, - soit l’interface du CMS (b), puis nourrir HAL depuis le CMS. … ou bien passer à un système de gestion de laboratoire (SGL) qui permette l’import d’une bibliothèque EndNote (comme avec le logiciel AIGLe), puis transférer toutes les références et documents dans HAL via ses WS. Ce SGL devrait alimenter le site internet du laboratoire. La saisie se ferait dans le SGL (ou / et dans HAL … ?).

5. SI Local SI Local Annuaire LDAP SI Labo Site internet Temps Affiche la liste du personnel du labo (sauf les stagiaires) Gère la liste de tout le personnel du labo (stagiaires compris) L’annuaire de l’unité ou de la tutelle principale (Université …) Le SI qui gère les badges du site Un « workflow » entre SI ? Parmi les SI qu'on est amené à utiliser, on devrait choisir l'un d'eux comme source de données qui pourrait diffuser ses données vers les autres SI, avec une sorte de workflow entre eux. Cependant on ne pourra pas forcément respecter cet ordre d’entrée des données, à savoir commencer par le SI source. Par ex. pour les fiches d’entrée de personnel, on pourrait prendre l'annuaire LDAP comme source, car celui-ci est souvent incontournable, et il serait logique de commencer par le renseigner. Mais à moins de contrôler l'annuaire, le délai d’inscription dans celui-ci peut être retardé par des procédures administratives et s’avérer trop long. En conséquence on devra remplir d'abord les formulaires d'entrée locaux (urgents à renseigner). D'où une redondance de saisie inévitable dans ce cas. Exemple de timing pour la saisie des nouveaux entrants :