CIRAD  SIST

(1)

CIRAD

 SIST

Documentation technique des modules :

 ABONNEMENT

 CYRUS

 HUBBLE

 MYSQLFINDER

Février 2007

Ref. [Référence document]

(2)

CIRAD

Documentation Technique Sommaire

Historique des versions du document Version /

Date Auteur Commentaire Date de validation / Approbateur V0.0.1

06/01/2005 O.Douarche Création V0.0.2

08/06/2005 C.Chamberlin Complément

V1.0.0 O.Douarche Vérification 09/10/2005 V1.0.1 C.Chamberlin Complément 27/10/2005 V1.1 C.Chamberlin Vérification 09/11/2005

(3)

CIRAD

Documentation Technique Sommaire

Sommaire

1 PRÉAMBULE...4

1.1 OBJECTIFSDUDOCUMENT...4

1.2 TERMINOLOGIE... 4

2 NORMES DE DÉVELOPPEMENT PHP...5

2.1 MODULEDE RECHERCHE FÉDÉRÉES...5

2.2 MODIFICATION DUNOYAU SPIP-AGORA...5

3 ALIMENTATION DE LA BASE IRD...6

3.1 PRÉSENTATION... 6

3.2 FORMALISMEDESFICHIERS XML...6

3.3 MISEENŒUVREDEL’IMPORTATION...9

3.4 PLANIFICATIONDEL’IMPORT...9

4 MYSQLFINDER : INTERROGATEUR GENERIQUE MYSQL...10

4.2 PRINCIPE DEFONCTIONNEMENT...10

4.3 ORGANISATIONDESRÉPERTOIRES...12

4.4 PARAMÈTRESTECHNIQUES...13

5 ABONNEMENT : DIFFUSEUR D’INFORMATION...14

5.2 DÉFINITIONDES MODULES...14

6 CYRUS : LE MOISSONNEUR OAI...17

6.2 PRINCIPE DEFONCTIONNEMENT...17

7 HUBBLE : MOTEUR DE RECHERCHE FÉDÉRÉES...21

7.2 DÉFINITIONDES MODULES...21

7.3 ACCÈSCONTROLÉAUXBASESSENSIBLES...34

7.4 CALCULDELAPERTINENCE...34

7.5 SCHÉMAD’ARCHITECTURE...35

7.7 CONFIGURATIONETPARAMETRAGE...38

8 TESTS DE MONTEE EN CHARGE...39

(4)

CIRAD

Documentation technique Tests de montee en charge

1 P RÉAMBULE

1.1 O

BJECTIFS DU DOCUMENT

Ce document à pour objectif de décrire l’ensemble des aspects techniques du projet SIST- CIRAD :

- Le contenu des différentes couches applicatives

- L’architecture technique du moteur de recherche fédérée, - L’intégration du module dans SPIP-Agora,

- Le modèle de données

1.2 T

ERMINOLOGIE Sigle, terme,

abréviation

Désignation

LOT1 Version prototype du projet

LOT2 Version définitive du site web basé sur Spip-Agora

(5)

CIRAD

2 N ORMES DE DÉVELOPPEMENT PHP

2.1 M

ODULE DE

R

ECHERCHE

F

ÉDÉRÉES

Dans le cadre de l’écriture du module de recherche fédérées, le normes de développement à appliquées sont, dans la mesure du possible, celles décrites dans le document :

PPQA.7 – Normes de développement PHP

Les commentaires seront eux écrits à la norme phpDOC.

2.2 M

ODIFICATION DU NOYAU

SPIP-A

GORA

Dans le cadre d’une modification du noyau ou de toutes sources de SPIP-Agora, la règle à retenir en matière d’écriture est la suivante :

//************ Modification elebescond@clever-age.com **************************

LE NOUVEAU CODE AGORA /*L'ANCIEN CODE DE SPIP

*/

//*************************** Fin Modification *****************************************

En gardant en commentaire le code original de SPIP, la procédure d’UPDATE CVS depuis le repository de SPIP permettra de fusionner facilement les sources des 2 projets (Exigence S004, Exigence S008).

La convention de codage du projet AGORA est la même que celle utilisée dans le projet PEAR.

La principale caractéristique à suivre est d’utiliser une indentation de 4 espaces, sans tabulation.

(6)

CIRAD

3 ALIMENTATION DE LA BASE IRD

3.1 P

RÉSENTATION

Ce module à pour vocation d’alimenter la base annuaire de l’IRD (Institut de Recherche et de Développement) à partir de fichier XML déposé dans un répertoire spécifié.

3.2 F

ORMALISME DES FICHIERS

XML

Les fichiers XML devront avoir le formalisme suivant :

3.2.1 Entete

idSIST Le code d’identification de la base au niveau du SIST.

Ce code sera fourni à chaque responsable de base par l’administrateur de l’annuaire du SIST.

sigleInstitution Sigle de l’organisme ou de l’institution (optionnel) institution Nom complet de l’organisme ou de l’institution nomBase Nom de la base de données originale (optionnel) urlBase URL de la base de données originale

adresse Adresse de l’organisme ou de l’institution

ville Ville

codePostal Code Postal

pays Pays

responsable Nom du responsable technique à contacter email E-mail du responsable technique

dateMAJ Date de mise à jour de la base, au format normalisé ISO 8601 recommandé par le W3C pour les données en XML.

Exemple : 2005-02-25

3.2.2 Exemple

En-tête pour la base Fiores de l’IRD :

<institution>Institut de Recherche pour le Développement</institution>

<nomBase>Fiores</nomBase>

<urlBase>http://www.ird.fr/fiores/<urlBase>

<adresse>213 rue La Fayette</adresse>

<ville>Paris</ville>

<pays>France</pays>

<responsable>Anne Glanard</responsable>

<email>ag@paris.ird.fr<email>

(7)

CIRAD

</source>

3.2.3 Enregistrements

Regroupées sous des balises enregistrement, les informations devant figurer sont celles du tronc commun (les noms figurant dans la première colonne correspondent aux noms des balises en XML) :

titre Nom du chercheur, de l’équipe de recherche ou du programme de recherche.

La forme est choisie librement par chaque responsable de base, l’information devant tenir sur une ligne lors des affichages à l’écran.

descriptionCourte Complément de description sur une ou deux lignes, destiné à être affiché en dessous du titre.

On peut ainsi donner des intitulés développés

(programmes de recherche) ou indiquer des domaines d’expertises ou des thèmes de recherche (chercheurs).

url URL donnant accès à la fiche complète de cet enregistrement.

presentation Texte de présentation qui servira à la recherche plein texte.

Pour chaque base de données, le responsable devra définir le ou les champs qui seront recopiés dans ce texte pour permettre une recherche plein texte. Ce texte n’a pas vocation a être affiché, mais à être indexé.

Ce champ ne doit pas dépasser, en principe, 500 caractères. Dans certains cas, il peut être répété (texte dans une autre langue, par exemple).

type Type d’enregistrement, à choisir dans la liste suivante : chercheur / enseignant-chercheur / ingénieur / thésard / équipe

discipline Information sur la ou les disciplines concernées, en se basant sur la nomenclature fournie ci-dessous.

Ce champ n’est pas obligatoire mais il est vivement recommandé de le renseigner. Il est répété si plusieurs disciplines sont concernées.

lieuEtude Information sur les lieux d’étude, c’est-à-dire les zones géographiques concernées par le programme de recherche.

Ce champ n’est pas obligatoire mais il est vivement recommandé de le renseigner quand il a un sens. Il est répété si plusieurs lieux sont concernés.

motCle Si la base d’origine dispose d’un système de mots clés, on peut reporter ici les mots clés relatifs à l’enregistrement (en répétant la balise pour chaque mot clé).

Ce report est optionnel. Dans un premier temps, ces mots clés serviront simplement dans les recherches plein texte.

(8)

CIRAD

3.2.4 Exemple

Pour une unité de recherche :

<titre> Unité de recherche R179 de l’IRD </titre>

<descriptionCourte> Séquestration du carbone et bio-fonctionnement des sols : effets des modes de gestion des agro-écosystèmes tropicaux </descriptionCourte>

<url>http://www.ird.fr/sais/cgi/TrSaS?

nomPopulation=unites&procedure=POPULATION.AfficherObjets&action=ArPAGE&nomObjet=R17 9</url>

<type>équipe</type>

Valider des pratiques de gestion des agro-systèmes qui participent à la maîtrise des flux de carbone et d'azote, et qui permettent à la fois une production agricole optimale et un contrôle de l'émission des gaz à effet de serre.

</presentation>

<discipline>Biologie appliquée - écologie</discipline>

<lieuEtude>Madagascar</lieuEtude>

<lieuEtude>Sénégal</lieuEtude>

<lieuEtude>Burkina-Faso</lieuEtude>

<lieuEtude>Martinique</lieuEtude>

</enregistrement>

Pour un chercheur :

<titre> Waast Roland – IRD - UR105 - Savoirs et développement</titre>

<descriptionCourte> Expertise : Sociologie des sciences et des techniques

</descriptionCourte>

<url>http://www.ird.fr/fiores/notice.php?id=FF000060</url>

<type>chercheur</type>

1. Potentiel et productivité scientifiques. Evaluation d'institutions, de programmes, de projets scientifiques et techniques. 2. Politiques publiques d'enseignement supérieur et de recherche scientifique et technique. 3. Relations industrie/recherche. Innovation. Privatisation de la science. Résistance et oppositions au développement scientifique et technique. Applications spécifiques au développement : 1. Management scientifique. Dispositifs de sélection des chercheurs. Modèles de professionnalisation. Choix des thèmes de recherche. Contrôle académique et contrôle institutionnel. Brain-drain/brain-gain. 2. Institutions scientifiques dans les pays en développement : systèmes nationaux de recherche (évaluation). Dispositifs régionaux et centres internationaux. Reconversion d'institutions. Enseignement/recherche.

Dispositifs d'aide et d'encouragement aux recherches applicables. 3. Stratégies scientifiques et développement (évaluation). Choix de niches et créneaux. Financement de la recherche.

Transfert de connaissances. Politiques de coopération. Articulation privé/public. Techniques adaptées. Image publique des sciences et techniques. Oppositions et rejets.

</presentation>

<discipline>Sciences sociales</discipline>

<lieuEtude>Madagascar</lieuEtude>

<lieuEtude>Afrique du Nord</lieuEtude>

<motCle> Sciences sociales </motCle>

<motCle> Sociologie des sciences </motCle>

<motCle> Sciences et techniques </motCle>

<motCle> Recherche </motCle>

<motCle> Evaluation </motCle>

</enregistrement>

3.3 M

ISE EN ŒUVRE DE L

’

IMPORTATION L’importation s’opère via le fichier ImportIRD.php.

Se fichier prend en paramètre la variable :

- PATH  Chemin physique du répertoire de dépôt des fichiers XML.

Le traitement va tout d’abord générer un répertoire pour les logs dans PATH/Logs.

(9)

CIRAD

Ensuite, tous les fichiers XML présents dans le répertoire cible feront l’objet d’un traitement d’importation.

Un fichier d’import correspondant au formalisme : IRD-Import_YYYY-MM-DD_hh-mm-ss.log sera généré.

Exemple :

27/10/2005 16:10:16 - --- PROCESS IS STARTED !!! --- 27/10/2005 16:10:16 - 1 file(s) have(s) been found 27/10/2005 16:10:16 - Processing file started : IRD3.xml 27/10/2005 16:10:16 - - Analysing file process started 27/10/2005 16:10:16 - - Parsing XML file started 27/10/2005 16:10:20 - - Parsing XML file ended 27/10/2005 16:10:20 - - Analysing file process ended 27/10/2005 16:10:20 - - Importing Data process started

27/10/2005 16:10:20 - - 3112 record(s) in the XML structure

27/10/2005 16:10:21 - - Source ID : FR0003 already in database - UPDATE 27/10/2005 16:10:21 - - Updating done

27/10/2005 16:10:21 - - 3111 record(s) is(are) already stored in database for the source FR0003 27/10/2005 16:10:21 - - Deleting records for the source FR0003

27/10/2005 16:10:22 - - Deleting record complete for the source FR0003 27/10/2005 16:10:22 - - Inserting records process started

27/10/2005 16:10:29 - - Inserting records process completed with 3112 row inserted and 0 errors 27/10/2005 16:10:29 - - Importing Data process ended

27/10/2005 16:10:29 - Processing file ended : IRD3.xml

27/10/2005 16:10:57 - Import is finished with 1 file(s) imported 27/10/2005 16:10:57 - --- PROCESS IS FINISHED !!! ---

Les fichiers XML ne sont pas détruits après import.

3.4 P

LANIFICATION DE L

’

IMPORT

Pour une planification quotidienne, il suffit de créer un fichier dans le répertoire /etc/cron.daily, qui contient la commande suivante :

wget "http://[Server]/ImportIRD.php?PATH=[CheminXML]" -O "chemin vers fichier de log utilisateur "

--tries=1

(10)

CIRAD

4 M Y SQLF INDER : I NTERROGATEUR GENERIQUE

M Y SQL

4.1 P

RÉSENTATION

Le composant MySql Finder permet l’interrogation de n’importe quelle table Mysql située dans une base accessible via le port d’interrogation standard 3306.

Dans sa partie Front-office, le composant propose :

- Un formulaire d’interrogation simple permettant de requêter sur tous les champs ou un champ spécifique de la table cible

- Un formulaire d’interrogation avancé permettant de requêter individuellement sur chacun des champs, avec des opérateurs spécifiques

- Il existe également une URL d’interrogation spécifique qui correspond à une recherche simple et qui génère un flux RSS en sortie

Dans sa partie Back-office, le composant propose : - La liste des sources existantes

- La création d’une source de données en définissant la base, puis la table cible et les champs interrogeables

4.2 P

RINCIPE DE FONCTIONNEMENT

4.2.1 La création des sources

Le back-office propose la création des plusieurs sources interrogeables. Pour exister une source a besoin des paramètres suivants :

- L’adresse du serveur Mysql - Le nom du user de connexion - Son mot de passe.

A partir de ces informations le module permet de lister l’ensemble des bases disponibles sur ce serveur. Il suffit de choisir la base puis la table pour voir apparaître le liste complête des champs de celle-ci.

Pour chaque champ on peut définir plusieurs critères :

- Son libellé (a partir du moment où le libellé du champ est renseigné, celui-ci sera visible dans la fiche d’une occurrence de résultat)

- Son type : défini automatiquement par l’application

- Titre : défini si le champ doit être considéré comme le titre de l’enregistrement

- Résumé : défini si le champ doit être considéré comme contenant la description de l’enregistrement

- Autres : défini un champ comme étant interrogeable et qui n’est ni un titre ni un résumé.

La valeur de la colonne « Autres » représente l’ordre d’affichage du champ dans la fiche - Dépendances vers d’autres tables : défini si un champ doit être considéré comme une clef

étrangère. Dans ce cas là on précise alors la table étrangère cible et le champ à afficher.

- Export RSS : défini à quel item RSS le champ de la table correspond pour la génération du flux RSS.

(11)

CIRAD

4.2.2 L’interrogation des sources

L’interrogation des sources peut s’effectuer de plusieurs manières.

4.2.2.1 Interrogation simple

L’interrogation simple s’effectue sur tous les champs. Il s’agit donc d’une requête OR effectuée sur tous les champs interrogeables spécifiés. Une vérification est tout de même effectuée sur le type du critère de recherche pour éviter d’avoir des erreurs SQL (inutile de requêter une champ de type DATE avec la valeur « Sist » par exemple).

Lorsque l’utilisateur sélectionne un champ en particulier à requêter, la clause WHERE est construite spécifiquement sur ce champ. Si le type du critère ne correspond pas avec le type du champ, la clause WHERE n’est pas spécifiée dans la requête et cela devient une requête portant sur tous les enregistrements de la source.

Ce type de recherche peut prendre en compte plusieurs critères, séparés alors par un espace.

D’une manière générale une recherche LIKE est effectuée sur les champs de type texte, une recherche = est effectuée sur les champs numérique ou date.

4.2.2.2 Interrogation Avancée

Cette interrogation permet de spécifier pour chaque champ interrogeable de la source, un opérateur et un critère spécifique.

L’opérateur évolue en fonction du type du champ interrogeable.

Pour les champs de type texte on aura : - Commence par  LIKE ‘%[CRITERE]’

- Contient  LIKE ‘%[CRITERE]%’

Pour les champs de type numérique ou date on aura :

- Egal  =

- Inférieur  <

- Supérieur  >

- Supérieur ou égal  >=

- Inférieur ou égal  <=

Pour les champs de type clé étrangère on aura :

- A pour élément  égalité entre la clef étrangère de la table source et de la clef primaire de la table étrangère

Par défaut la requête effectue un AND entre les différents champs. Sauf si la case « Combiner tous les champs de la recherche » est cochée, à ce moment là, c’est l’opérateur OR qui est sollicité.

Cette recherche n’admet pas plusieurs mots pour un champ interrogeable en particulier. Si plusieurs mots sont renseignés (séparés par des espace) , c’est la chaîne entière qui sera traitée comme unique critère.

4.2.3 Restitution des résultats

(12)

CIRAD

Le résultat d’une recherche est paginé en fonction de la page courante, ainsi le flux des données transportées reste constant. Si une recherche retourne 7000 enregistrements, la pagination s’effectuant par 10 enregistrements, seul le flux des 10 enregistrements sera affiché. C’est l’opérateur LIMIT qui est utilisé ici.

Les résultats sont présentés sans ordre de tri particulier, le calcul de la pertinence est impossible et les opérateurs MATCH AGAINST ne peuvent pas être utilisés dans un contexte générique.

Chaque occurrence affiche :

- Le champ identifié comme étant le champ Titre - Le champ identifié comme étant le champ Résumé - Les champs Autres classés par ordre d’affichage

Dans la partie résultat, seuls les champs interrogeable sont affichés, dans la partie fiche, tous les champs ayant un libellé renseignés sont affichés.

4.2.4 Génération d’un flux RSS

Mysqlfinder peut également générer un fichier RSS de sortie en correspondance avec l’interrogation d’une source.

Pour cela il suffit d’appeler le fichier :

/modules/Mysqlfinder/Metier/MysqlfinderRSS.php Avec les paramètres suivants :

- MYSQLFINDER_SOURCE_ID L'identifiant de la source

- MYSQLFINDER_PRODFONDEUR  Le nombre résultat à fournir

- MYSQLFINDER_CRITERES  Les critères à rechercher (facultatif)

- MYSQLFINDER_FIELD_NAME  Le champ spécifique à recherche (facultatif) L’appel peut donc se faire de la manière suivante :

/modules/Mysqlfinder/Metier/MysqlfinderRSS.php?

MYSQLFINDER_SOURCE_ID=1&MYSQLFINDER_CRITERES=Sist&MYSQLFINDER_PRODFONDEUR=

100

Le flux RSS de sortie sera générer en fonction des items RSS qui ont été associés aux champs de la source.

4.3 O

RGANISATION DES RÉPERTOIRES

 Myslqfinder

 Mysqlfinder.php  Appel Front-office du module

 Mysqlfinder.sql  Script de création des tables du module

 MysqlfinderAdmin.php  Appel Back-office du module

 MysqlfinderParam.inc  Paramètre du module

 Include

 MysqlfinderOutils.php  Librairie d’outils

 MysqlfinderPopUpExport  Gestion de l’export CSV et PDF

 Include

 Mysqlfinder_FR.php  Fichier de langue française

 Mysqlfinder_ENphp Fichier de langue anglaise

 Metier

 ClassBaseMySql.php  Classe de gestion de la base Mysql

 ClassMysqlfinderCSV.php  Class de gestion de la création des fichiers CSV

(13)

CIRAD

 ClassMysqlfinderRTF.php  Class de gestion de la création des fichiers RTF

 MysqlfinderRSS.php  Point d’entrée pour la génération RSS

 Style

 Mysqlfinder.css  Fichier de styles du front office

 MysqlfinderAdmin.css  Fichier de styles du back office

 Temp  Répertoire temporaire pour les fichiers d’export

 Template  Répertoire de stockage des modèles HTML

 Images  Répertoire de stockage des images du composant

4.4 P

ARAMÈTRES TECHNIQUES

Les paramètres techniques sont disponibles dans le fichier MysqlfinderParam.inc.

Nombre de résultat à afficher par page :

$GLOBALS["MYSQLFINDER"]["NB_ELEMENT_PAR_PAGE"] = 10;

(14)

CIRAD

5 A BONNEMENT : D IFFUSEUR D ’ INFORMATION

(Exigence B2-004) (Exigence B2-005) (Exigence B2-006)

5.1 P

RÉSENTATION

L'utilisateur peut s'abonner à un service qui lui permet d'enregistrer une ou plusieurs équations de recherche dans Hubble et de recevoir périodiquement les résultats de ces recherches. Il peut également choisir parmi une liste de sites diffusant de l'information syndiquée. La diffusion de ces résultats sera sous la forme d’un mail ou d’un fichier de BACKEND (format XML) téléchargeable.

5.2 D

ÉFINITION DES MODULES

5.2.1 Gestion de l’abonnement

L’abonnement utilise 4 tables :

 ABONNEMENT : Paramètre de l’abonnement

 ABONNEMENT_HUBBLE : Requête et source de l’abonnement

 ABONNEMENT_SITE_SYNDIQUE : Site de l’abonnement

 ABONNEMENT_INC_HUBBLE : Gestion incrémentale pour les requêtes

 ABONNEMENT_INC_SITE : Gestion incrémentale pour les sites

La suppression d’un abonnement entraîne la suppression de l’ensemble des abonnements :

 Requête sur les sources HUBBLE

 Sites syndiqués

 Incrément pour les requêtes

 Incrément pour les sites

5.2.2 Le module d’interrogation

Le module d’interrogation se compose de 2 sous-modules : le requêteur Hubble, et les fichiers backend de site.

5.2.2.1 Le requeteur Hubble

En fonction des sources, et de la requête saisies dans l’abonnement, ce module effectuera le requatage auprès de Hubble. L’ensemble des réponses récupérées sera stocké dans fichier mis à disposition du module de diffusion.

5.2.2.2 Les fichiers backend de site

L’ensemble des fichiers backend des sites est téléchargé et mis à disposition du module de diffusion.

5.2.3 Le module de diffusion

En fonction du type de diffusion de l’abonnement, le module de diffusion gère le delta des données résultats de l’abonnement. Le delta est construit sur la base des URLs, c'est-à-dire que

(15)

CIRAD

l’on compare les URLs des réponses déjà reçu par l’abonné et celle des réponses trouvées, seront extraites et transmises celles qui sont considérées comme nouvelles (dont l’URL n’a pas été retrouvé).

L’abonnement de l’utilisateur permet de récupérer les fichiers Backend de réponses des sites auxquels il est abonné mais aussi des réponses aux requêtes Hubble.

Les nouvelles réponses seront transmises à l’abonné sous forme d’une fichier backend ou d’un email. De plus, les URLs de ces réponses seront stockées dans des tables prévues à cet effet afin d’effectuer l’opération de « delta ».

5.3 O

RGANISATION DES RÉPERTOIRES Les répertoires sont organisés de la manière suivante :

 Abonnement

 Abonnement.php  Appel Front-office du module

 Abonnement.sql

 AbonnementAdmin.php  Appel Back-office du module

 AbonnementParam.inc  Paramètre du module

 CRON

 LanceurDiffuseur.php

 LanceurImportBackend.php

 LanceurRequeteurHubble.php

 TEMP  Fichier généré automatiquement

 Include  Bibliothèque de fonctions

 PopUpListeSourcesProteges.php

 PopUpSource.php

 Langue  Traductions du module

 Abonnement _EN.inc

 Abonnement _FR.inc

 Metier 

 ClassAbonnementPresentation.php

 ClassDiffuseur.php

 ClassImportBackend.php

 ClassRequeteurHubble.php

 Template

 formAbonnement-part1.htm

 formAbonnement-part2-1.htm

 formAbonnement-part2-2.htm

 PopUpListeSourcesProteges.htm

 PopUpListeSourcesProtegesItem.htm

 PopUpSource.htm

5.3.1 Planifications (CRON)

5.3.1.1 Fichier de CRON

rm -f /var/www/html/CIRAD_BETA/modules/Abonnement/Cron/Temp/*

wget http://projet-mtp-2/CIRAD_BETA/modules/Abonnement/Cron/LanceurImportBackend.php -O /var/www/html/CIRAD_BETA/modules/Abonnement/Cron/Temp/backend.log

wget http://projet-mtp-2/CIRAD_BETA/modules/Abonnement/Cron/LanceurRequeteurHubble.php -O

(16)

CIRAD

wget http://projet-mtp-2/CIRAD_BETA/modules/Abonnement/Cron/LanceurDiffuseur.php -O /var/www/html/CIRAD_BETA/modules/Abonnement/Cron/Temp/diffuseur.log

5.3.1.2 Logs

Voici un exemple de fichier de requete.log :

[LOG] On est sur l'abonnement : 22- Requetes : Coucou- Sources : 12- Table des sources :12

[LOG] On est sur l'abonnement : 21- Requetes : Cheval- Sources : 23,100- [WARNING] Le source 100 a été supprimée.

Table des sources :23

Voici un exemple de fichier de backend.log :

[LOG]Téléchargement de l'url Backend

:/var/www/html/CIRAD_BETA/modules/Abonnement/Cron/Temp/SITE_8.XML

[LOG]Téléchargement de l'url Backend

:/var/www/html/CIRAD_BETA/modules/Abonnement/Cron/Temp/SITE_5.XML

Voici un exemple de fichier de diffuseur.log :

[WARNING] : Le fichier '/var/www/html/CIRAD_BETA/modules/Abonnement/Cron/Temp/SITE_100.XML' était attendu et n'a pas été trouvé.

[WARNING] : Le fichier '/var/www/html/CIRAD_BETA/modules/Abonnement/Cron/Temp/REQUETE_22.XML' ne contient pas d'item

[WARNING] : Le fichier '/var/www/html/CIRAD_BETA/modules/Abonnement/Cron/Temp/REQUETE_21.XML' était attendu et n'a pas été trouvé.

[LOG] : On est sur l'abonnement 22

5.4 P

L’ensemble des paramètres techniques est défini dans le fichier AbonnementParam.inc : Nombre maximal d’abonnement au requête

$_SESSION["ABONNEMENT"]["MAX_REQUETE"] = 5

$_SESSION["ABONNEMENT"]["TIME_LIMIT"] = 1000

(17)

CIRAD

6 C YRUS : L E MOISSONNEUR OAI

Le module de moissonnage des archives OAI s’intègre dans le framework SPIP-Agora.

6.1 P

RÉSENTATION

Le but de ce module est permettre sur sa partie front office :

- D’interroger diverses archives référencées dans la base locale depuis une recherche simple et avancée sur les méta données.

- De pouvoir proposer de nouvelles archives

- De lister les archives référencées et de connaître leur caractéristiques.

Dans sa partie back-office, il permet : - De gérer les archives proposées

- D’éditer et de modifiées les archives enregistrées.

- D’indexer une archive en particulier

- De lancer le moissonnage sur toutes les archives référencées.

(Exigence B2-003)

De plus, le module dispose d’une tache planifiée (CRON) qui moissonne l’ensemble des archives validées, et ceci de maniere automatique.

6.2 P

RINCIPE DE FONCTIONNEMENT

6.2.1 Gestion des archives

La gestion des archives se fait au sein à l’aide du back-office, il regroupe de les opérations de :

 Création d’un archive

 Modification

 Suppression

 Validation

6.2.1.1 Création/Modification d’une archive

Au niveau du front-office, la possibilité est offerte à un utilisateur de proposé une archive, il est aussi possible de proposer un archive au sein du back-office.

A l’enregistrement de celle-ci (front & back), l’URL de l’OAI de l’archive sera vérifier c'est-à-dire qu’elle sera interrogée afin de vérifier que le format des données transmises est au format OAI 2.0 (ou OAI 1.1). Si la contrainte n’est pas vérifiée l’enregistrement de l’archive ne sera pas effectuées.

6.2.1.2 Suppression

La suppression d’une archive entraine non seulement la suppression de celui-ci, mais aussi la suppression de l’ensemble de Notices associés à cette archive.

6.2.1.3 Validation

Après validation de l’archive par un administrateur, celle-ci sera pourra être moissonner directement par l’administrateur, mais elle sera automatiquement moissonnée par la tache planifer

(18)

CIRAD

6.2.2 Moissonnage

Le moissonneur commence par interroger le site de l’OAI via l’URL OAI fournis dans l’archive, celle-ci lui retourne (via un formalisme XML) la liste des archives. Le moissonneur extrait des données XML, la liste des URL des notices OAI.

Chaque notice OAI sera interrogée (via son URL) et retournera l’ensemble des données de l’archive dans un formalisme XML d’où elles seront extraites. Seules les notices nouvelles ou ayant été mise à jour seront insérés (ou mise à jour) dans la base des notices.

Enfin, l’archive sera actualisée en fonction des notices qu’elle possède.

6.2.3 Recherche

Afin de pouvoir exploiter les données des notices, au niveau du front-office, une interface de recherche (simple & avancée) de la base des notices.

6.2.3.1 Recherche simple

La recherche simple fait une recherche full-text sur l’ensemble des notices à l’aide des commandes SQL MATCH & AGAINST.

6.2.3.2 Recherche avancée

La recherche avancée fait une recherche full-text sur l’ensemble des critères saisies notices à l’aide des commandes SQL MATCH & AGAINST. Toutefois, l’option Combiner toutes les critères permet si elle est activée de faire une recherche OU entre les différents critères saisies, sinon cela sera une recherche ET entre les différents critères saisies.

6.2.3.3 Résultats

Les résultats seront présentés par ordre décroissant de pertinence (le cacul de la pertinence est fait de maniere native par les commandes SQL MATCH & AGAINST). Il est possible de trier les résultats par auteur, titre ou date.

6.2.4 Planification du moissonnage (CRON)

6.2.4.1 Fichier de CRON

wget "http://projet-mtp-2/CIRAD_BETA/modules/Cyrus/Cron/LanceurMoissonnage.php" -O

"/var/www/html/CIRAD_BETA/modules/Cyrus/Cron/moissonnage.log" --tries=1

6.2.4.2 Logs

Voici un exemple de fichier de log :

28/10/2005 04:03:10 MoissonneurOAI : Lancement

28/10/2005 04:03:10 1/7-Universite Lyon 2 - Cybertheses 28/10/2005 04:03:10 ..

28/10/2005 04:04:21 1/7-Universite Lyon 2 - Cybertheses 279 notice(s) nouvelle(s) ou actualisée(s) 28/10/2005 04:04:21 2/7-Revues.org - Fédération de revues scientifiques en sciences humaines et sociales

28/10/2005 04:04:21 ...

28/10/2005 05:32:34 2/7-Revues.org - Fédération de revues scientifiques en sciences humaines et sociales 498 notice(s) nouvelle(s) ou actualisée(s)

28/10/2005 05:32:34 3/7-INP Toulouse Theses 28/10/2005 05:32:34 ..

28/10/2005 05:33:06 3/7-INP Toulouse Theses 91 notice(s) nouvelle(s) ou actualisée(s) 28/10/2005 05:33:06 4/7-Portail francophone des Thèses Electronique

28/10/2005 05:33:06 ...

28/10/2005 05:40:20 4/7-Erreur d'indexation sur l'archive Portail francophone des Thèses Electronique : Erreur SQL Insert : 1048: Column 'CYRUS_METADATA_SOURCE' cannot be null

(19)

CIRAD

28/10/2005 05:40:20 5/7-Bibliothèque Paul-Emile Boulet 28/10/2005 05:40:20 ..

28/10/2005 05:40:32 5/7-Bibliothèque Paul-Emile Boulet 0 notice(s) nouvelle(s) ou actualisée(s) 28/10/2005 05:40:32 6/7-AJOL

28/10/2005 05:40:32 ....

28/10/2005 06:38:57 6/7-Erreur d'indexation sur l'archive AJOL : not well-formed (invalid token) 28/10/2005 06:38:57 7/7-essai de Thierry

28/10/2005 06:38:57 ..

28/10/2005 06:39:15 7/7-essai de Thierry 256 notice(s) nouvelle(s) ou actualisée(s)

6.3 O

RGANISATION DES RÉPERTOIRES

L’ensemble des fichiers communs au différents modules ont été regroupé dans le répertoire Commun du répertoire modules.

Les répertoires sont organisés de la manière suivante :

 Cyrus

 Cyrus.php  Appel Front-office du module

 Cyrus.sql

 CyrusAdmin.php  Appel Back-office du module

 CyrusParam.inc  Paramètre du module

 CRON  Tache planifiée

 LanceurMoissonnage.php

 Moissonnage.log

 Include  Bibliothèque de fonctions du moissonnage

 functions.inc.php

 xmlparser.inc.php

 Langue  Traductions du module

 Cyrus_EN.inc

 Cyrus_FR.inc

 Metier  Classe metier

 ClassArchive.php

 ClassConfiguration.php

 ClassMoissonneur.php

 ClassNotice.php

 ClassSearch.php

 ClassConfiguration.php

 Style  Feuille de style

 Cyrus.css

 CyrusAdmin.css

 Template  Modèle de présentation

 formAdminEditArchive.html

 formAdminEditConfiguration.html

 formAdminListeArchive.html

 formAdminListeArchiveItem.html

 formAdminListeArchiveSub.html

 formAdminViewArchive.html

 formEditArchive.html

 formListeArchive.html

 formListeArchiveItem.html

 formListeArchivePagination.html

 formListeNotice.html

 formListeNoticeItem.html

 formListeNoticePagination.html

 formMain.html

 formMenuArchive.html

 formSearch.html

 formSearchAdvanced.html

(20)

CIRAD

 formSearchResults.html

 formSearchSimple.html

 formSearchSimpleItem.html

 formViewArchive.html

 formViewNotice.html

 Image  Image du module

6.4 P

L’ensemble des paramètres techniques est défini dans le fichier CyrusParam.inc :

Nombre d’item visible sur les listes d’archives, des notices (résultats recherche)

$_SESSION["CYRUS"]["CONFIG"]["LISTEARCHIVE_NBITEMPAGE"] = 5;

$_SESSION["CYRUS"]["CONFIG"]["LISTENOTICE_NBITEMPAGE"] = 5;

Plage de saisie des dates de la recherche avancée

$_SESSION["CYRUS"]["CONFIG"]["SEARCHDATE_YEARBEGIN"] = 1995;

$_SESSION["CYRUS"]["CONFIG"]["SEARCHDATE_YEAREND"] = 2006;

Durée maximal d’execution du moissonnage d’une archive

$_SESSION["CYRUS"]["CONFIG"]["TIME_LIMIT"] = "600";

(21)

CIRAD

7 H UBBLE : M OTEUR DE RECHERCHE F ÉDÉRÉES

Le module de recherche fédérées à pour vocation de s’intégrer rapidement dans n’importe quel environnement et plus particulièrement il doit pouvoir s’intégrer dans le framework SPIP-Agora (Exigence I002)

7.1 P

RÉSENTATION

Le but de ce module de recherche fédérée est d’interroger n’importe quelles types de sources accessibles depuis la plateforme d’hébergement.

L’interrogation s’effectue à partir d’un formulaire de recherche qui permet de saisir les mots sur lesquels la recherche va porter ainsi que les sources que l’on souhaite solliciter.

Ces sources peuvent être de n’importe quel type : - des formulaires Web

- des URLs spécifiques

- des documents disposés dans des répertoires (recherche plein texte via MnoGoSearch) - des bases de données.

Les résultats d’une recherche sont uniquement présentés au format HTML. Toutefois, une liste déroulante permet de d’exporter l’ensemble de ces résultats sous divers formes (XML, PDF, RTF).

Afin de gagner en performance, l’affichage du rendu sera effectué lorsqu’un nombre de résultats défini par l’utilisateur sera atteint. Deplus, dans le cas ou celui-ci n’aurait pas été atteint, l’interface indiquera l’état de source, de même que le rafraichissement des données.

7.2 D

ÉFINITION DES MODULES

7.2.1 Le coordinateur

Cet objet est le cœur du système.

Son but est :

- La récupération des critères de recherche (mode local ou distant) - Le lancement de Séquenceur

- L’appel du Gestionnaire de mise en forme Il doit pouvoir fonctionner dans 2 modes :

- Le mode Recherche

o C’est le mode qui est sollicité lors d’une nouvelle recherche, le coordinateur sollicite les différents acteurs de la recherche (le Séquenceur et le Gestionnaire de mise en forme).

- Le mode Consultation des résultats

o Ce mode intervient lorsqu’un premier rendu de résultat à été présenté, l’utilisateur peut décider alors de paginer le tableau des résultats. Dans ce cas là il ne faut pas relancer la recherche mais exploiter les résultats obtenus lors du premier appel.

(Exigence I003)

(22)

CIRAD

7.2.1.1 Récupération des critères de recherche

Les critères de recherche sont récupérés par la méthode POST du protocole HTTP : - Liste de sources à interroger

- Le nombre de résultat par page à afficher

- Le type de rendu (seulement HTML pour cette version)

7.2.1.2 Lancement du séquenceur

Le Séquenceur est le module qui gére l’appel des connecteurs pour chaque source demandée.

Son but est de générer un fichier de résultats dans une norme particulière, qui est exploitable par le gestionnaire de mise en forme.

L’appel du Séquenceur s’effectue en tant que processus séparé via la couche d’abstraction de gestion des processus.

7.2.1.3 Appel du gestionnaire de mise en forme

Parallèlement au lancement du séquenceur, le coordinateur appelle dans la foulée le gestionnaire de mise en forme. Celui-ci à pour but de restituer les résultats de la recherche au format demandé.

7.2.2 Le Séquenceur

Ce module a pour but de gérer les différents connecteurs sollicités par les sources demandées lors de la recherche.

Ses fonctions sont les suivantes : - L’appel des connecteurs - Le suivi des connecteurs - La récupération des résultats

- Génère le fichier de résultats et le fichier de statut des connecteurs

7.2.2.1 Création des connecteurs

En fonction du nombre de sources demandées, le séquenceur parallélisera la création des connecteurs correspondants, en fonction du type de la source (uniquement des formulaire Web pour cette version).

7.2.2.2 Suivi des connecteurs

Une fois les connecteurs créés, le séquenceur doit les initialiser avec les critères de recherche, puis les lancer.

Ceux-ci effectuent leur tâche (sollicitation des sources, centralisation de résultats, etc…)

A tout moment, le séquenceur doit être en mesure de connaître l’état d’avancement des tâches attribuées aux connecteurs, il doit donc pouvoir suivre :

L’état du connecteur (En attente, En cours d’exécution, Terminé)

Si une erreur est remontée (Code et Libellé) via l’interface de gestion des erreurs du Back-Office

Le buffer de sortie du connecteur (la structure dans laquelle seront stockés les résultats)

(23)

CIRAD

Ces états sont manipulés à travers la couche d’abstraction de gestion des processus.

Une gestion de « timeout » est mise en place au niveau des connecteurs.

7.2.2.3 Récupération des résultats

Pour chaque connecteur, les résultats de la recherche sont retournés dans.

En l’occurrence, il s’agit d’un tableau représentant pour chaque occurrence de résultat, la valeur des items de la norme RSS :

Link description … source

0 http://www.source1.fr/res1.html Resultat 1 de la recherche Source1

…

N http://www.sourcen.fr/resn.html Resultat n de la recherche Sourcen

Ce tableau est disponible via la couche d’abstraction des processus dans le buffer de sortie associé à chaque processus.

7.2.2.4 Génération du fichier de résultat et de statut

La finalité du séquenceur est de produire un jeu de résultat à destination du gestionnaire de mise en forme. Ce jeu de résultat sera produit sous la forme de 2 fichiers :

o Le fichier des données issues de la recherche proprement dite o Le fichier de statut des connecteurs

Le choix de stocker les résultats dans un fichier permet de s’affranchir du problème de la persistance mais aussi pour le cas où l’utilisateur souhaite consulter la énième page du jeu de résultat, dans ce cas, les fichiers générés permettront d’éviter d’avoir à relancer la recherche.

Ces fichiers seront nommés de façon unique de manière à pouvoir les retrouver suite à la demande de visualisation d’une autre page du jeu de résultat par l’utilisateur.

Tout naturellement l’Id de session et le timestamp servent au nommage des fichiers : - le fichier de statut s’appellera, PROCDIAL[SESSION_ID][TIMESTAMP].dat

- le fichier de données s’appellera, DIAL[SESSION_ID][TIMESTAMP].dat

Ces fichiers seront stockés dans un répertoire spécifique qui sera nettoyé à chaque affichage du formulaire de recherche fédérée par un nouvel utilisateur du SIST. Tous les fichiers de plus de 30 mn seront effacés.

7.2.2.4.1 Le fichier de données

Ce fichier sera construit (partiellement) à l’aide de la sérialisation d’objet en PHP :

||FILE_BEGIN||

||TAB_BEGIN||ITEM_RSS1||ITEM_RSS2||ITEM_RSS3||…||ITEM_RSSn||TAB_END||

…

||TAB_BEGIN||ITEM_RSS1||ITEM_RSS2||ITEM_RSS3||…||ITEM_RSSn||TAB_END||

(24)

CIRAD

Où ||FILE_BEGIN|| constitue la balise de début du fichier et ||FILE_END|| la balise de fin.

Le reste est une succession de balises ||TAB_BEGIN|| et de balises ||TAB_END|| correspondant à chaque source demandée. Chacune des sources est encodée à l’aide de la « sérialisation d’objet ».

Entre les balises ||TAB_BEGIN|| et ||TAB_END|| on retrouve l’ensemble des valeurs trouvées pour les éléments disponibles dans la norme RSS 2.0. et suivant l’ordre indiqué dans la déclaration du tableau suivant :

$RSS_ITEM = Array(

"title",

"link",

"description",

"author",

"category",

"comments",

"enclosure",

"guid",

"pubDate",

"source") ;

7.2.2.4.2 Le fichier de statut

Ce fichier est primordial pour communiquer l’état d’avancement de la recherche. N’oublions pas que le gestionnaire de mise en forme déclenche l’affichage de la page dès que le nombre de résultat a été atteint (exprimé par l’utilisateur dans le formulaire de recherche). Pour autant, ce n’est pas parce qu’un premier rendu est généré que la recherche est forcément terminée, certains connecteurs peuvent toujours être en cours de progression et le séquenceur continue donc d’alimenter le fichier de données.

Le fichier de statut permet donc de connaître précisément le statut des connecteurs et donc de déterminée les sources qui ont terminé leur recherche et de communiquer ces informations à l’utilisateur via le gestionnaire de mise en forme.

Ce fichier sera construit à l’aide de la « sérialisation d’objet » utilisé sur l’ensemble des processus « ClassProcessFOpen »:

a:11:{i:0;O:12:"processfopen":8:

{s:16:"PAGE_PROCESS_PHP";s:35:"../Connecteur/LanceurConnecteur.php";s:9:"process Id";i:0;s:6:"handle";N;s:7:"content";s:0:"";s:14:"pageProcessPHP";s:82:"http://p rojet-mtp-

2/CIRAD_BETA/modules/Hubble/Metier/Lanceur/LanceurConnecteur.php";s:9:"timeBegin

";s:21:"0.84161900 1118218153";s:7:"timeEnd";s:21:"0.96809700 1118218155";s:6:"params";a:3:

{s:12:"NBRESULTPAGE";N;s:7:"CRITERE";s:6:"Cheval";s:3:"URL";s:1:"2";}}i:1;O:12:"

processfopen":8:

{s:16:"PAGE_PROCESS_PHP";s:35:"../Connecteur/LanceurConnecteur.php";s:9:"process Id";i:1;s:6:"handle";N;s:7:"content";s:0:"";s:14:"pageProcessPHP";s:82:"http://p rojet-mtp-

2/CIRAD_BETA/modules/Hubble/Metier/Lanceur/LanceurConnecteur.php";s:9:"timeBegin

";s:21:"0.84217700 1118218153";s:7:"timeEnd";s:21:"0.95016100 1118218155";s:6:"params";a:3:

{s:12:"NBRESULTPAGE";N;s:7:"CRITERE";s:6:"Cheval";s:3:"URL";s:2:"19";}}

(25)

CIRAD

7.2.3 Le connecteur (formulaire Web)

Ces modules se chargent d’interroger les sources demandées lors de la recherche suivant les critères définis, de récupérer les résultats et de les transmettre au séquenceur.

Les connecteurs peuvent être de plusieurs types (formulaire Web, Url spécifique de recherche, Base de donnée, MnoGoSearch, etc..), cependant pour le prototype nous ne traiterons que des connecteurs de type « Formulaire Web »

Leurs fonctions sont les suivantes :

- Appel des sources avec les critères de recherche

- Gestion de la pagination dans le cas des formulaires Web - La récupération des résultats

(Exigence I004)

Séparateur de mots-clefs

Dans le formulaire de définition de la source (back-office), il est possible d’y définir le séparateur de mots-clefs. Ce séparateur sera exploité par le connecteur afin de gérer au mieux les requêtes à multiples mots. Par défaut, le séparateur « ESPACE » est utilisé dans le cas où le séparateur de la source est vide. (Exigence H2-004)

7.2.3.1 Appel des sources (formulaire web)

A chaque type de source est associée une problématique différente. Pour les sources de type

« formulaire web » le but est donc d’émuler l’interrogation d’un formulaire placé sur une page web et de récupérer le flux HTML résultat.

Pour ce faire il suffit de repérer l’URL de traitement d’un formulaire de recherche sur le Web et d’analyser les paramètres qui y sont passés.

Par exemple, pour Google l’URL est la suivante : http://www.google.fr/search Les paramètres déterminants sont passés en méthode GET et sont les suivants : hl : qui détermine la langue (valeur : fr)

q : qui détermine le critère de recherche (valeur : le mot à rechercher)

Ainsi l’url suivante, affichera la première page de résultat sur le mot Hubble : http://www.google.fr/search?hl=fr&q=Hubble

7.2.3.2 Gestion de la pagination

Un problème est spécifique à des sources de données de type Web, cela vient du fait que, par défaut, seul un certain nombre de résultats est présenté par page (souvent 10 résultats par page).

Or on veut pouvoir récupérer, peut-être, les 100 premiers résultats d’une source Web, ce qui induit de mettre en place un processus de pagination.

Si une source ne produit que 10 résultats par page et que l’on souhaite récupérer les 100 premières occurrences de résultat pour une recherche, le connecteur Web va devoir paralléliser

(26)

CIRAD

Par exemple si l’on prend le cas du moteur de recherche Google on voit clairement comment sont formalisées les réponses :

Voici l’url de la première page de résultat :

http://www.google.fr/search?hl=fr&q=Hubble&btnG=Rechercher&meta=

Voici l’url de la 2^ème page de résultat :

http://www.google.fr/search?q=Hubble&hl=fr&lr=&start=10&sa=N Voici l’url de la 13^ème page de résultat :

http://www.google.fr/search?q=Hubble&hl=fr&lr=&start=120&sa=N

On voit donc que le paramètre déterminant est la variable start.

Celle-ci est calculée selon la formule : (NUM_PAGE-1)*NB_RESULTAT_PAR_PAGE

Autrement dit pour atteindre les résultats de la 20^ème page, il suffit de lancer l’URL : http://www.google.fr/search?q=Hubble&hl=fr&lr=& start=190 &sa=N

L’URL de Google sera donc stockée sous la forme générique suivante :

http://www.google.fr/search?q=##CRITERE##&hl=fr&lr=&start=##(NUM_PAGE- 1)*NB_RESULTAT_PAR_PAGE##&sa=N

A chaque appel d’une page l’URL sera donc recomposée en fonction des valeurs de : - CRITERE qui correspond aux mots recherchés

- NB_RESULTAT_PAR_PAGE qui correspond au nombre de résultat que la source ramène au maximum dans une page

- NUM_PAGE correspond au numéro de la page à appeler.

- SEPARATEUR DE MOT-CLEF dans le cas de l’utilisation d’une recherche multicritères

7.2.3.3 Récupération des résultats

Une fois le flux HTML récupéré, l’opération consiste à repérer dans celui-ci les occurrences des résultats.

On part du principe que les résultats affichés par les moteurs de recherche sur le web sont affichés dans un format répétitif selon un « masque » déterminé.

(27)

CIRAD

Pour chaque occurrence de résultat il faut maintenant identifier les éléments déterminants :

N’oublions pas que le but ultime consiste à demander au gestionnaire de mise en forme de produire un format XML à la norme RSS, le connecteur Web doit donc extraire les chaînes de caractères déterminantes puis les associées à un attribut d’un Item RSS :

1

2

3

4

5

6 7

8

1 2 3

4

(28)

CIRAD

Description Guid pubDate

Ainsi, pour chaque source de données nous allons définir un masque. Ce masque correspondra au formalisme de présentation des réponses pour cette source. Dans ce masque seront disposés judicieusement les mots-clefs qui vont déterminés l’emplacement de tel ou tel attribut d’item (titre, lien, description, etc..)

Exemple de masque pour google :

<p class=g ><a href= ##link## >##title##</a> ##*## <font size=- 1>##description##<nobr>

Le connecteur va donc rechercher toutes les occurrences du masque dans le flux HTML de résultat et pour chaque occurrence, celui-ci va extraire les chaînes de caractères correspondant à l’emplacement des mots-clefs.

Le but étant de produire une structure de données au séquenceur qui serait de la forme suivante :

Link description … source

0 http://www.source1.fr/res1.html Resultat 1 de la recherche Source1

…

N http://www.sourcen.fr/resn.html Resultat n de la recherche Sourcen

Inclusion de constantes de masques de résultats

Une gestion des constantes dans le masque de résultat est disponible, c'est-à-dire qu’elle permet d’insérer dans le masque une chaîne de caractères qui sera automatiquement incluse avant ou après un tag de masque (Exigence H2-005). Cette possibilité permet completer les chemins relatifs des liens d’une pages.

La syntaxe est la suivante : ##ValeurContante1@link@ValeurConstante2##

Attention, seul le tag ##*## ne peut contenir des constants

Dé doublonnage des résultats sur le lien

L’ensemble des résultats est dé doublonné entre plusieurs sources sur le LIEN.

(Exigence H2-007)

Forcer le calcul de la pertinence

L’administrateur peut activer le re-calcul de la pertinence pour une source (qu’elle en possède ou pas). Le re-calcul est fait selon des règles qui sont détaillé plus loin.

(Exigence H2-009)

7.2.4 Les sources de données

Les sources de données peuvent être de plusieurs sortes. Dans le cadre du prototype, elles seront majoritairement basées sur des formulaires Web. L’autre source de données à implémenter est basée sur le moteur de recherche MnoGoSearch.

2 3 4

(29)

CIRAD

Lors d’une recherche l’utilisateur spécifie les sources qu’il veut solliciter pour sa recherche.

Pour chaque source demandé, un connecteur correspondant au type de la source va être créé.

Le connecteur va donc faire l’intermédiaire entre la source de données, et le moteur de recherche fédérée.

Une source de données a donc pour objectif :

- d’être sollicitée en tenant compte des critères de recherche - de renvoyer un flux de résultats

7.2.4.1 Source de données de type formulaire Web Ces sources sont définies par plusieurs critères :

- Leur URL d’appel : il s’agit en général de l’URL de la page de traitement d’une recherche, celle-qui fournit le flux HTML contenant les résultats.

Cette URL est stockée de manière générique de la manière suivante :

 http://www.masource.com/mapage?

critere=##CRITERE##&pagination##FORMULE##

 Conformément à la définition des mots-clefs définis dans les paragraphes précédents

- Le nombre de résultats affichés par page, en effet certaines sources peuvent paramétrer le nombre de résultats maximum renvoyés par page.

- Le masque qui va permettre l’extraction des données

- La catégorie à laquelle la source appartient (dans le cadre du prototype, cette catégorisation des sources n’est pas prise en compte.

Ces sources sont donc sollicitées via le connecteur de type formulaire web. Celui-ci va donc gérer la pagination, l’extraction des données du flux HTML de résultat et va transmettre les informations au séquenceur.

7.2.4.2 Source de données basées sur MySQLFinder

Le connecteur MySQLFinder permet à Hubble d’effectuer une recherche directement en utilisant les requeteur générique MySQLFinder.(Exigence H2-012).

Pour ce faire, il est nécessaire de créer une catégorie MySQLFinder, et une source utilisant cette catégorie.

Création de la catégorie MySQLFinder

Il est nécessaire de créer une source afin de préciser l’utilisation du connecteur MYSQLFINDER ainsi que les paramètres indispensable à celui-ci. Ces paramètres sont :

 Profondeur

 Identifiant de l’objet

Création de la source MySQLFinder

Il est important que la source soit paramêtrée avec au moins les valeurs suivantes :

 Catégorie de la source : MYSQLFINDER.

 Identifiant de l’objet : Identifiant de la source MYSQLFINDER à interroger.

 Profondeur : Entier qui contient le nombre de résultats maximum que la source peut retourner.

7.2.4.3 Source de données basées sur un autre SIST

Le connecteur SIST permet à Hubble d’effectuer une recherche directement sur des SIST distants.(Exigence H2-012).

(30)

CIRAD

Pour ce faire, il est nécessaire de créer une catégorie SIST, et une source utilisant cette catégorie.

Tester du SIST distant

L’URL de connexion à un autre SIST s’écris de la manière suivante : http://serveurSIST/cheminAuSIST/modules/Hubble/recepteurSIST.php?

SOURCES=1,2&CRITERE=COUCOU

Dans l’exemple ci-dessus, la question « COUCOU » sera posée aux sources 12 et 1.

Création de la catégorie SIST

Il est nécessaire de créer une source afin de préciser l’utilisation du connecteur SIST ainsi que les paramètres indispensable à celui-ci. Ces paramètres sont :

 URL de la source

 Paramêtre de l’URL Création de la source SIST

Il est important que la source soit paramêtrée avec au moins les valeurs suivantes :

 Catégorie de la source : Site SIST

 Parametre de l’URL : SOURCES=#idSource#,#idSource#,#idSource#

 URL de la source : Url de la racine du site SIST

7.2.4.4 Source de données basées sur Mnogosearch

Mnogosearch permettra d’indexer tous les sites web référencés dans son fichier de configuration ainsi que l’ensemble des documents locaux présents dans l’espace de stockage du serveur (Exigence F014)

7.2.5 Le gestionnaire de mise en forme

Le gestionnaire de mise en forme intervient en bout de chaîne, ce module effectue le rendu des résultats de la recherche au format demandé (dans le cadre du projet, seul le format HTML est pris en compte)

Ces fonctions sont les suivantes :

- Analyser le fichier de données et de statut - Transformer les données au format RSS - Déclencher le rendu

(Exigence I005)

7.2.5.1 Analyse du fichier de donnée et de statut

Comme nous l’avons vu plus haut, le séquenceur récupère les informations renvoyées par les sources via les connecteurs. Celui-ci écrit les résultats dans un fichier selon un format spécifique.

Le but du gestionnaire de mise en forme et donc de lire le contenu du fichier, et selon l’action de l’utilisateur (lancement d’un recherche ou consultation d’une page spécifique du jeu de résultat), de générer les résultats au format RSS et de produire le résultat dans le format attendu.

(31)

CIRAD

7.2.5.2 Transformation au format RSS

La transformation RSS s’effectue en respectant la norme 2.0 et à partir du fichier de données réalisé par le séquenceur.

Ce format de sortie permet de respecter les normes standard de syndication et donc de permettre une grande ouverture du système vers l’extérieur.

7.2.5.2.1 Définition du Format RSS

RSS est un format de syndication de contenu Web.

Son nom est un acronyme pour Really Simple Syndication (syndication vraiment simple).

RSS est un dialecte de XML. Tous les fichiers RSS doivent être conformes à la spécification XML 1.0, publiée sur le site Web du World Wide Web Consortium (W3C).

Au niveau le plus élevé, un document RSS est un élément <rss>, avec un attribut obligatoire appelé version, qui spécifie la version de RSS à laquelle le document est conforme. S'il est conforme à cette spécification, l'attribut version doit être 2.0.

Subordonné à l'élément <rss> est un seul élément <channel>, qui contient des informations à propos du channel (métadonnées) et de ses contenus.

Nous stockons sous forme de balise ITEM l’ensemble des occurrences de résultats lues dans le fichier de données constitué par le séquenceur à partir du masque de chacune des sources. En effet c’est la structure du masque qui détermine le contenu de chaque attribut de la balise item pour chacune des occurrences de résultats.

Liste des éléments de la balise ITEM :

Elément Description Exemple

title Le titre de l'item. Venice Film Festival Tries to Quit Sinking

link L'URL de l'item. http://www.nytimes.com/2002/09/07/movies/07FEST .html

description Le synopsis de l'item. Some of the most heated chatter at the Venice Film Festival this week was about the way that the arrival of the stars at the Palazzo del Cinema was being staged.

author Adresse email de l'auteur de l'item.

oprah@oxygen.net category Inclut l'item dans une ou

plusieurs catégories.

Simpsons Characters comments URL d'une page de

commentaires relatifs à cet item.

http://www.myblog.org/cgi-local/mt/mt- comments.cgi?entry_id=290

enclosure Décrit un objet media qui est attaché à l'item.

guid Un texte qui identifie de manière unique cet item.

http://inessential.com/2002/09/01.php#a2 pubDate Indique quand l'item a été

publié.

Sun, 19 May 2002 15:21:36 GMT source Le channel RSS d'où provient

l'item.

Quotes of the Day