Dossier de Spécifications Techniques Détaillées API indexation

Transcription

Dossier de Spécifications Techniques Détaillées
API indexation/recherche
Spécification technique
Dossier de Spécifications Techniques
Détaillées
Auteur
Version
: Logica et Région Île-de-France
: 0.2
Droit d’auteur
Ce document est disponible sous contrat Creative Commons Paternité Pas d'Utilisation Commerciale - Partage des Conditions Initiales à
l'Identique 2.0 France : http://creativecommons.org/licenses/by-ncsa/2.0/fr/
SPECTECH-api-recherche-indexation.doc
Page 1 de 20
Historique des évolutions
Vers.
Date
Auteurs
Description
0.1
01/03/2011
Laurent BILLIOTTE
Initialisation du document
0.2
25/07/2011
Marion MAURIN
Relecture
Page 2 de 20
Sommaire
Historique des évolutions
2
Sommaire
3
1. Objectif
5
2. Choix des outils techniques
6
3. Configuration de la partie socle
7
3.1.
Configuration du serveur SolR
7
3.2.
Schéma
7
3.2.1.
Particularité des champs gen_*
9
3.2.2.
Champ gen_id
9
3.2.3.
Champ gen_type
9
3.2.4.
Champs gen_droits_*
9
3.2.5.
Champs gen_auteur_*
9
3.2.6.
Champ gen_date
10
3.2.7.
Champ gen_visibilite
10
3.2.8.
Champ description
10
3.2.9.
Champ porteur_droits_id
10
3.2.10.
Champ porteur_projet_id
10
3.2.11.
Champs doc_*
10
3.2.12.
Champs blog_*
11
3.2.13.
Champs forum_*
11
3.2.14.
Champs actu_*
11
3.2.15.
Champ gen_actu_date_expiration
11
3.2.16.
Champs cahier_*
11
3.2.17.
Champs messagerie_*
11
Page 3 de 20
4. Rappel sur la gestion des droits dans l’ENT
12
5. API d’utilisation pour les modules
14
5.1.
Constantes
14
5.2.
Indexation
15
5.2.1.
DTO
15
5.2.2.
Méthodes d’indexation d’un nouvel élément
15
5.2.3.
Méthodes de réindexation du contenu d’un élément existant
15
5.2.4.
Méthodes de réindexation des droits d’accès à un élément existant
16
5.2.5.
Méthodes de désindexation (suppression)
16
5.3.
Recherche
17
5.3.1.
DTO
17
5.3.2.
Méthode de recherche
18
6. Modification du socle pour un nouveau type d’élément
19
6.1.
Modification du schéma SolR
19
6.2.
Définition des constantes
19
6.3.
Création du DTO d’indexation
19
6.4.
Modification du DTO de recherche
19
6.5.
Modification du DAO de recherche
19
6.6.
Modification des Business et DAO d’indexation
20
Page 4 de 20
1. Objectif
Comme vu dans la documentation sur l’ensemble du socle applicatif, la solution Lilie propose des
outils d’indexation et de recherche centralisée pour les données des différents services. Les
recherches internes à chaque module sont effectuées directement en SQL dans les bases de
données, mais un module spécifique web-recherche propose une recherche globale à tous les
services. Celle-ci fonctionne par l’intermédiaire d’un moteur de recherche (du style de Google) sur des
données structurées d’une manière différente du découpage interne de chaque module. On peut ainsi
y indexer à la fois des données brutes de bases de données et des documents de bureautique (.doc
par exemple).
Outre la centralisation des données pour une recherche globale, ceci permet de rechercher de
manière plutôt textuelle et générique dans les contenus des modules, en utilisant des fonctionnalités
comme la synonymie ou la lemmatisation sur les termes recherchés.
Pour obtenir ces fonctionnalités, les modules doivent utiliser l’api-recherche du socle de l’ENT, afin
d’indexer leurs données.
Ce document décrit techniquement cette API, aussi bien en termes d’utilisation pour un module qu’en
termes de maintenance de l’api elle-même.
Page 5 de 20
2. Choix des outils techniques
L’API d’indexation et de recherche s’appuie sur le moteur d’indexation et de recherche standard
Lucene/SolR (http://lucene.apache.org/solr/), une application stand-alone de la fondation Apache.
Les
applications
Lilie
communiquent
avec
SolR
grâce
à
la
bibliothèque
SolRJ
(http://wiki.apache.org/solr/Solrj), fournie avec SolR. Cette librairie est embarquée dans l’api-recherche.
L’indexation de documents riches (PDF, documents Word etc…) s’appuie sur la bibliothèque Tika
(http://tika.apache.org/) de la fondation Apache. Cette librairie est embarquée par l’api-recherche.
Page 6 de 20
3. Configuration de la partie socle
3.1.
Configuration du serveur SolR
Le fichier de configuration principal de SolR est le fichier solrconfig.xml, situé dans le répertoire conf de
l’application SolR.
La version de ce fichier de configuration utilisé pour Lilie est présente dans le projet solr-custom du
socle.
Ce fichier permet de définir entres autres les paramètres de mémoire et les différents gestionnaires de
requêtes utilisés par SolR.
3.2.
Schéma
SolR indexe les données qu’il reçoit selon un schéma de données défini dans le fichier schema.xml.
La version de ce fichier utilisé pour Lilie est présente dans le projet solr-custom du socle.
Ce fichier permet entres autres de
-
définir les différents types de données indexées (texte, booléen, integer, date etc…) et comment
les traiter lors d’une indexation et/ou d’une recherche.
-
définir les différents champs indexés pour les différentes applications de Lilie et comment indexer
les données de ces champs.
-
définir une clef unique pour chaque objet indexé
-
définir l’opérateur par défaut à utiliser entre plusieurs termes lors d’une recherche
Les champs définis pour Lilie (version 1.4.9) sont les suivants :
<fields>







<field name="gen_id" type="string" indexed="true" stored="true" required="true" />
<field name="gen_type" type="string" indexed="true" stored="true" required="true"
/>
<field name="gen_droits_etablissements" type="text" indexed="true" stored="true" />
<field name="gen_droits_groupes" type="text" indexed="true" stored="true" />
<field name="gen_droits_users" type="text" indexed="true" stored="true" />
Page 7 de 20
<field name="gen_auteur_nom" type="text" indexed="true" stored="true"
required="true" />
<field name="gen_auteur_prenom" type="text" indexed="true" stored="true"
required="true" />
<field name="gen_date" type="date" indexed="true" stored="true" required="true" />

<field name="gen_visibilite" type="boolean" indexed="true" stored="false"
default="1" />

<field name="description" type="text" indexed="true" stored="true" required="true"
/>

<field name="porteur_droits_id" type="string" indexed="true" stored="true"
required="true" />
<field name="porteur_projet_id" type="string" indexed="true" stored="true"
required="true" />

<field name="doc_titre" type="text" indexed="true" stored="true" />
<field name="doc_motsCles" type="text" indexed="true" stored="true" />
<field name="doc_nom" type="text" indexed="true" stored="true" />
<field name="doc_corps" type="text" indexed="true" stored="false" />
<field name="doc_niveau" type="string" indexed="true" stored="true" />
<field name="doc_type" type="string" indexed="true" stored="true" />

<field name="blog_titre" type="text" indexed="true" stored="true" />
<field name="blog_titresArticles" type="text" indexed="true" stored="true" />
<field name="blog_corpsArticles" type="text" indexed="true" stored="true" />

<field name="forum_titre" type="text" indexed="true" stored="true" />
<field name="forum_message" type="text" indexed="true" stored="true" />

<field name="actu_titre" type="text" indexed="true" stored="true" />
<field name="actu_article" type="text" indexed="true" stored="true" />

<field name="gen_actu_date_expiration" type="date" indexed="true" stored="true"
default="2999-12-12T23:59:59Z"/>

<field name="cahier_nom" type="text" indexed="true" stored="true" />
<field name="cahier_matiere" type="text" indexed="true" stored="true" />
<field name="cahier_groupe" type="text" indexed="true" stored="true" />
<field name="cahier_activite_titre" type="text" indexed="true" stored="true" />
<field name="cahier_activite_objectif" type="text" indexed="true" stored="true" />
<field name="cahier_activite_type" type="text" indexed="true" stored="true" />
<field name="cahier_activite_contexte" type="text" indexed="true" stored="true" />
<field name="cahier_ressource_contenu" type="text" indexed="true" stored="false" />
<field name="cahier_ressource_nom" type="text" indexed="true" stored="true" />
<field name="cahier_ressource_url" type="text" indexed="true" stored="true" />

<field name="messagerie_sujet" type="text" indexed="true" stored="true" />
<field name="messagerie_contenu" type="text" indexed="true" stored="true" />
<field name="messagerie_etat" type="text" indexed="true" stored="true" />
<field name="messagerie_dest_TO" type="text" indexed="true" stored="true" />
<field name="messagerie_dest_CC" type="text" indexed="true" stored="true" />
</fields>
Le champ « gen_id » correspond à la clef unique du document :
<uniqueKey>gen_id</uniqueKey>
Page 8 de 20
L’opérateur par défaut est le « ou » :
<solrQueryParser defaultOperator="OR"/>
3.2.1. Particularité des champs gen_*
Les champs dont le nom est préfixé par « gen_ » sont traités particulièrement par l’API d’indexation et de
recherche.
En effet, lors de la création de la requête SolR de recherche par l’API, tous les termes associés à ces
champs sont précédés d’un AND dans la requête et sont donc considérés comme des restrictions fortes.
Par exemple, en recherchant les actualités contenant le terme JEE dont le prénom de l’auteur est
« Louis », la requête constituée sera de la forme :
(actu_article:JEE
OR
actu_titre:JEE
gen_auteur_prenom:Louis AND gen_type:ACTU …
OR
description:JEE)
AND
3.2.2. Champ gen_id
Ce champ correspond à l’identifiant unique de l’objet indexé.
Il est constitué d’un préfixe correspondant au type de l’élément suivi de l’identifiant de l’élément tel qu’il est
connu dans l’application appelant l’API d’indexation.
Par exemple, l’actualité dont l’identifiant est « 123 » dans l’application des actualités est indexée avec
l’identifiant « AC_123 ».
Il est obligatoire et de type « string », donc indexé tel quel.
3.2.3. Champ gen_type
Ce champ correspond au type de l’objet indexé (actualité, message de forum, activité du cahier de
texte…).
3.2.4. Champs gen_droits_*
Ces champs correspondent aux droits portés par l’objet indexé et sont utilisés lors de la recherche en les
confrontant aux droits de la personne effectuant la recherche (Voir Rappel sur la gestion des droits).
Ces champs permettent de stocker les listes d’identifiants des utilisateurs, des groupes et des
établissements, séparés par des espaces, ayant accès à l’objet.
Ils sont obligatoires et de type « text » pour permettre l’indexation de chaque identifiant comme un mot.
3.2.5. Champs gen_auteur_*
Ces champs correspondent au nom et au prénom de l’auteur de l’objet indexé.
Ils sont obligatoires et de type « text », donc traités comme des mots.
Page 9 de 20
3.2.6. Champ gen_date
Ce champ correspond à la date à laquelle l’objet a été indexé.
Il est obligatoire et de type « date ».
3.2.7. Champ gen_visibilite
Ce champ permet d’indiquer que l’objet indexé n’est pas publié ou est caché et qu’il ne doit donc pas être
retourné lors d’une recherche.
Ce champ est utilisé par exemple lors de la modération des messages du forum, lorsque le modérateur
cache un message qu’il ne souhaite plus voir apparaître. Le message est alors réindexé en positionnant
ce champ à 0 (non visible).
Ce champ est de type « boolean » et par défaut a la valeur 1 (visible).
3.2.8. Champ description
Ce champ contient la description de l’objet indexé. Il est utilisé dans l’écran de recherche pour afficher la
description ou un aperçu de l’objet indexé dans les résultats de recherche.
Il est obligatoire et de type « text ».
3.2.9. Champ porteur_droits_id
Ce champ permet de définir une relation entre deux objets (Voir Rappel sur la gestion des droits). Il
permet d’indiquer quel est l’objet parent de l’objet courant, cet objet parent étant l’objet sur lequel les
droits sont affectés. Cet identifiant permet de réindexer les droits des objets fils d’un élément lorsque les
droits de ce dernier sont modifiés. Il permet également de supprimer tous les éléments fils lorsqu’un
élément parent est supprimé.
Par exemple, les messages des blogs portent dans ce champ l’identifiant du blog de manière à réindexer
les messages avec les droits adéquats lorsque les droits du blog sont modifiés, ou supprimer tous les
messages associés à un blog lorsque ce dernier est supprimé.
Si l’objet n’a pas de parent, alors on stocke dans ce champ l’identifiant de l’objet lui-même.
3.2.10.
Champ porteur_projet_id
Ce champ contient le code du porteur de projet lié à cet objet.
3.2.11.
Champs doc_*
Ces champs correspondent aux différents champs indexés pour les documents de l’espace de travail.
Page 10 de 20
3.2.12.
Champs blog_*
Ces champs correspondent aux différents champs indexés pour les blogs.
3.2.13.
Champs forum_*
Ces champs correspondent aux différents champs indexés pour les forums.
3.2.14.
Champs actu_*
Ces champs correspondent aux différents champs indexés pour les actualités.
3.2.15.
Champ gen_actu_date_expiration
Ce champ est un champ particulier des champs indexés pour les actualités.
Son nom est préfixé par « gen_ » pour définir une restriction forte sur cette propriété (précédée d’un AND
et non d’un OR par défaut).
Ce champ n’est valorisé que pour les éléments de type « actualité », avec la date d’expiration de
l’actualité (date à laquelle cette actualité n’est plus publiée et donc ne doit plus être retournée par la
recherche).
Pour les autres types d’éléments, cette date est valorisée automatiquement avec la date du 31/12/2999.
3.2.16.
Champs cahier_*
Ces champs correspondent aux différents champs indexés pour les cahiers des textes et leurs
ressources et activités.
3.2.17.
Champs messagerie_*
Ces champs correspondent aux différents champs indexés pour la messagerie.
Page 11 de 20
4. Rappel sur la gestion des droits dans l’ENT
Chaque utilisateur connecté à Lilie est caractérisé, au niveau de la gestion des droits, par différentes informations :
-
le code porteur de l’utilisateur
-
le profil de l’utilisateur : utilisateur « normal », utilisateur « administrateur local », utilisateur « super
administrateur » etc…
-
l’identifiant de l’utilisateur
-
les groupes auxquels est associé l’utilisateur dans le cas d’un utilisateur « normal » (groupes scolarités et
groupe créés via la console d’administration)
-
les établissements auxquels est associé l’utilisateur dans le cas d’un utilisateur « administrateur local » (les
établissements pour lesquels l’utilisateur est déclaré « administrateur local »).
A chaque entité du module (actualités, blogs, cahier de textes etc…) sont attribuées, au niveau de la gestion des
droits, les informations suivantes :
-
le code porteur de l’entité
-
la liste des utilisateurs ayant directement accès à l’entité
-
la liste des groupes ayant accès à l’entité
-
la liste des établissements concernés par cette entité (c'est-à-dire la liste des établissements des
utilisateurs et des groupes ayant accès à cette entité)
L’accès aux entités par un utilisateur est obtenu en confrontant les informations de droits portées par l’utilisateur
aux informations de droits portées par l’entité. Un utilisateur a accès à une entité si :
-
il est un utilisateur « normal » et son code porteur correspond à celui de l’entité et [son identifiant apparait
dans la liste des identifiants d’utilisateurs ayant accès à l’entité ou il appartient à un groupe ayant accès à
l’entité].
-
Il est utilisateur « administrateur local » et son code porteur correspond à celui de l’entité et il est
administrateur local d’un établissement concerné par l’entité
-
Il est utilisateur « super administrateur » et son code porteur correspond à celui de l’entité.
Les résultats d’une recherche par l’API d’indexation et de recherche doivent répondre à ces mêmes règles d’accès
aux entités. C’est pourquoi les données concernant les droits d’accès aux entités sont indexées avec chacune
d’elles dans les champs gen_droits_users, gen_droits_groupes, gen_droits_etablissements et porteur_projet_id.
Lors d’une recherche, l’API ajoute automatiquement à la requête SolR de recherche les restrictions à effectuer sur
ces champs en fonctions des données de l’utilisateur qui effectue la recherche (données contenues dans le DTO
Page 12 de 20
CritereRechercheDto passé à la méthode de recherche). Seules les données répondant aux règles cidessus sont donc retournées.
Cas particulier des « entités parents porteuses de droits » :
Pour certains types d’entités, les droits sont portés par une entité « parent ». C’est par exemple le cas du
blog : le blog est l’entité qui porte les droits, les messages du blog possèdent les droits définis sur le blog
auquel ils appartiennent.
Pour retourner les entités « filles » correctes vis-à-vis de la gestion des droits lors d’une recherche, les
entités « filles » doivent être indexées avec les droits de l’entité « parent ». On indexera donc, par
exemple, un message du blog en lui attribuant les droits portés par le blog auquel il appartient.
De ce fait, lors de la modification des droits d’une entité « parent », il est nécessaire de réindexer
l’ensemble des entités « filles » associées. Pour ce faire, le champ « porteur_droits_id » est défini dans le
schéma SolR. Ce champ contient l’identifiant de l’entité « parent » pour chaque entité « fille » (NB : dans
le cas où l’entité n’a pas de « parent », ce champ doit contenir l’identifiant de l’entité elle-même). Ce
champ permet donc de retrouver directement l’ensemble des entités « filles » d’un élément pour pouvoir
les réindexer avec leurs nouveaux droits le cas échéant.
Page 13 de 20
5. API d’utilisation pour les modules
L’API d’indexation et de recherche est disponible dans le projet api-recherche du socle. Elle doit être
utilisée par tous les modules comme interface avec le serveur SolR.
L’API définit un certains nombre de DTO et de méthodes pouvant être regroupés en deux catégories
principales :
-
DTO et méthodes d’indexation
-
DTO et méthodes de recherche
Elle définit également des constantes utiles pour la manipulation de ces DTO et méthodes.
5.1.
Constantes
Les constantes définies par l’API sont déclarées dans la classe ConstantesApiRecherche.
Les principales constantes sont :
-
celles dont le nom est de la forme PREFIX_<type_d_element> qui définissent pour chaque type
d’élément le préfixe à utiliser pour la constitution de l’identifiant d’un élément de ce type dans
SolR (champ « gen_id »).
Par exemple, PREFIX_ACTU vaut « AC_ », ce qui signifie que toutes les actualités indexées
dans SolR seront identifiées par un identifiant commençant par « AC_ »
-
celles dont le nom est de la forme FILTRE_<type_d_element> qui définissent les différents types
d’éléments gérés dans SolR.
Cette constante est utilisée pour valoriser le champ « gen_type » de chaque élément indexé. Ceci
permet, lors d’une recherche sur un type d’élément particulier, de positionner le paramètre de
filtre de la requête SolR (fq, filter query) sur le champ « gen_type » pour optimiser les temps de la
recherche.
-
celles dont le nom est de la forme LOCATION_* qui définissent les différentes options de
recherche pour chaque type d’élément, comme par exemple la recherche uniquement sur le titre
d’une actualité, ou uniquement sur le contenu d’une actualité.
-
la constante STYLECSSSURLIGNAGE qui définit le nom du style CSS que SolR doit utiliser pour
appliquer le surlignage des termes dans les résultats d’une recherche.
-
la constante GROUPE_DROIT_PUBLIC qui définit la valeur à utiliser comme identifiant de
groupe pour définir un élément comme publique (accessible à tous)
-
les constantes dont le nom est de la forme CHAMPS_* qui définissent pour chaque type
d’élément la liste des champs attendus en retour d’une recherche
Page 14 de 20
5.2.
Indexation
5.2.1. DTO
A chaque type d’élément pouvant être indexé correspond un DTO Java.
On trouve donc, par exemple, les DTO ActualiteDto, BlogDto, ForumDto etc…
Certaines informations étant communes à chaque élément, ces informations sont regroupées dans le
DTO DonneesCommunesDto que chaque DTO étend.
Chacun des DTO définit également une map « liensProprieteIndex » établissant la correspondance
entre les propriétés du DTO et les champs SolR correspondants, ainsi que deux méthodes :
-
getNomIndex qui permet d’obtenir le nom d’un champ de SolR correspondant à une propriété du
DTO
-
getNomProprieteDto qui permet d’obtenir le nom d’une propriété du DTO correspondant à un
champ de SolR.
5.2.2. Méthodes d’indexation d’un nouvel élément
Ces méthodes permettent d’indexer un nouvel élément dans le moteur SolR en lui fournissant l’ensemble
des données à indexer pour cet élément, y compris les données concernant les droits. Ces données sont
portées par un DTO correspondant à l’élément et il existe autant de méthodes que de type d’éléments
pouvant être indexés.
Ces méthodes correspondent à toutes les méthodes
indexe<type_d_element> du business IndexeBusiness.
dont
le
nom
est
de
la
forme
Par exemple la méthode d’indexation d’une actualité :
public boolean indexeActu(ActualiteDto actuDtoAIndexer)
throws ServiceTechniqueException, ServiceFonctionnelleException;
Toutes ces méthodes ont leur équivalent qui traite une liste d’élément au lieu d’un élément seul. Il s’agit
des méthodes dont le nom est de la forme indexe<type_d_element>List du business IndexeBusiness.
Par exemple la méthode d’indexation d’une liste d’actualités :
public boolean indexeActuList(List < ActualiteDto > actuDtoListAIndexer)
Ces méthodes retournent toutes un booléen indiquant si l’opération s’est correctement déroulée.
5.2.3. Méthodes de réindexation du contenu d’un élément existant
Ces méthodes permettent de réindexer le contenu d’un élément ayant déjà été indexé et dont le contenu,
mais pas les droits, doit être modifié. Les droits seront conservés à l’identique de ce qui était déjà indexé.
Toutes les autres données doivent être fournies, tout particulièrement l’identifiant correspondant au
champ « gen_id » de SolR pour identifier l’élément à modifier.
Page 15 de 20
Ces méthodes correspondent à toutes les méthodes dont
reindexeContenu<type_d_element> du business IndexeBusiness.
le
nom
est
de
la
forme
Par exemple la méthode qui réindexe le contenu d’une actualité :
public boolean reindexeContenuActu(ActualiteDto actuDtoAIndexer)
Ces méthodes retournent toutes un booléen indiquant si l’opération s’est correctement déroulée.
NB : si aucun élément n’existe dans SolR avec le même identifiant, cette méthode retourne false et
n’indexe rien.
5.2.4. Méthodes de réindexation des droits d’accès à un élément existant
Ces méthodes, du business IndexeBusiness, permettent de réindexer les champs correspondant aux
droits d’accès d’un élément (gen_droits_users, gen_droits_groupes et gen_droits_etablissements) en
conservant le reste des données à l’identique.
Il existe pour ce faire 2 méthodes différentes.

La première méthode permet de réindexer les droits d’un élément unique à partir de l’identifiant
de cet élément :
public boolean reindexeDroitsElementParId(String idDocumentAReindexer,
List < Long > listeEtablissementsId,
List < Long > listeGroupesId,
List < Long > listeUtilisateursId)
Cette méthode prend donc en paramètre l’identifiant de l’élément à réindexer ainsi que la liste des
identifiants des utilisateurs, groupes et établissements à associer à cette entité. Ces listes doivent être
exhaustives (elles annulent et remplacent les listes existantes).
Cette méthode retourne un booléen indiquant si l’opération s’est correctement déroulée.
NB : si aucun élément n’existe dans SolR avec le même identifiant, cette méthode retourne false et
n’indexe rien.

La deuxième méthode permet de réindexer les droits de tous les éléments fils d’un autre
élément :
public boolean reindexeDroitsParIdPorteurDroits(String dElementPorteurDroits,
List < Long > listeEtablissementsId,
List < Long > listeGroupesId,
List < Long > listeUtilisateursId)
throws ServiceTechniqueException, ServiceFonctionnelleException {
Cette méthode prend donc en paramètre l’identifiant de l’élément parent (l’identifiant de l’élément porteur
des droits) et lance une recherche dans SolR pour obtenir l’ensemble des éléments dont le champ
« porteur_droits_id » vaut cet identifiant. Chaque élément fils ainsi obtenu est ensuite réindexé avec les
nouvelles listes d’identifiants d’utilisateurs, groupes et établissements passés en paramètre à la méthode.
Ces listes doivent être exhaustives (elles annulent et remplacent les listes existantes).
5.2.5. Méthodes de désindexation (suppression)
Page 16 de 20
Ces méthodes permettent de supprimer des index SolR un ou plusieurs éléments.
Il existe pour ce faire 3 méthodes différentes.

La première méthode permet de supprimer un élément unique à partir de son identifiant :
public boolean supprimeParId(String identifiant)
throws ServiceTechniqueException, ServiceFonctionnelleException
Cette méthode prend donc en paramètre l’identifiant de l’élément à supprimer et supprime des index SolR
toutes les données concernant l’élément correspondant.

La deuxième méthode permet de supprimer un élément et tous ses éléments fils à partir de son
identifiant :
public boolean supprimeParIdPorteurDroits(String identifiantPorteurDroits)
Cette méthode prend donc en paramètre l’identifiant de l’élément parent à supprimer (l’identifiant de
l’élément porteur des droits) et lance une recherche dans SolR pour obtenir l’ensemble des éléments dont
le champ « porteur_droits_id » vaut cet identifiant. Chaque élément fils ainsi obtenu est ensuite supprimé
des index SolR.

La troisième méthode permet de supprimer l’ensemble des éléments d’un même type (par
exemple toutes les actualités) :
public boolean supprimeParType(String typeElementASupprimerStr)
Cette méthode prend donc en paramètre le type des éléments à supprimer et supprime des index SolR
tous les éléments de ce type.
5.3.
Recherche
5.3.1. DTO
Deux DTO sont définis pour la partie recherche de l’API : CritereRechercheDto et RechercheDto.
CritereRechercheDto représente l’ensemble des critères de recherche possibles pour une recherche
d’éléments. Ces critères sont :
-
les termes/mots à rechercher
-
le nom de l’auteur
-
le prénom de l’auteur
-
la date minimale de publication (les documents retournés doivent être publiés après cette date)
-
la date maximale de publication (les documents retournés doivent être publiés avant cette date)
Pour la gestion des droits d’accès aux éléments indexés, CritereRechercheDto contient également les
propriétés suivantes :
-
l’identifiant de l’utilisateur effectuant la recherche
Page 17 de 20
-
les identifiants des groupes de l’utilisateur effectuant la recherche
-
les identifiants des établissements de l’utilisateur effectuant la recherche (à renseigner dans le
cas où l’utilisateur est un administrateur local)
-
le code du porteur de projet
RechercheDto est un DTO représentant les résultats de la recherche. La recherche pouvant retourner
une liste d’éléments de différents types (des actualités, des blogs, des forums etc…), ce DTO contient
donc toutes les propriétés possibles retournées pour chaque type d’éléments.
5.3.2. Méthode de recherche
La méthode de recherche est définie dans le business RechercheBusiness :
public List < Object > recherche(CritereRechercheDto critereRechercheDto,
String locationRecherche,
boolean rechercherTousTermes,
boolean surlignage,
int nbResultat,
String styleCssSurlignage)
Elle prend en paramètre :
-
une instance de CritereRechercheDto représentant les critères de la recherche
-
une chaîne de caractères indiquant sur quels champs SolR effectuer la recherche et devant
correspondre à une des valeurs des constantes de la forme LOCATION_* de
ConstantesApiRecherche.
-
un booléen indiquant si les éléments retournés doivent contenir tous les termes de la recherche
ou si la présence d’un seul suffit
-
un booléen indiquant si l’on souhaite que SolR surligne dans les résultats les termes qui ont
conduit à ce qu’un élément soit retourné
-
le nombre de résultat maximum attendu
-
le nom du style CSS à appliquer pour le surlignage des termes dans les résultats (en relation
avec le booléen surlignage)
Elle retourne une liste d’objet (instances de RechercheDto) contenant pour chaque élément retourné les
propriétés (correspondantes au type de l’élément) renseignées avec les valeurs de l’élément.
Page 18 de 20
6. Modification du socle pour un nouveau type d’élément
Pour modifier l’api-recherche en vue de traiter un nouveau type d’éléments en indexation et en recherche,
voici les différentes étapes à suivre.
6.1.
Modification du schéma SolR
Il faut modifier le fichier schema.xml de SolR pour définir les nouveaux champs correspondant aux
propriétés à indexer pour le nouveau type d’éléments.
6.2.
Définition des constantes
Il faut ajouter dans les constantes de la classe ConstantesApiRecherche les constantes suivantes :
-
la constante PREFIX_<type_d_element> pour le nouveau type avec une valeur distincte des
valeurs déjà existantes pour les autres préfixes
-
la constante FILTRE_<type_d_element> pour le nouveau type avec une valeur distincte des
valeurs déjà existantes pour les autres filtres
-
les constantes de la forme LOCATION_* pour définir les diverses recherches possibles sur le
nouveau type
-
la constante CHAMPS_SPECIFIQUES_<type_d_element> pour définir les différents champs
spécifiques au nouveau type
-
mettre à jour la constante CHAMPS_SPECIFIQUES_TOUT pour ajouter les champs spécifiques
au nouveau type.
6.3.
Création du DTO d’indexation
Il faut créer le nouveau DTO utilisé lors de l’indexation représentant le nouveau type d’éléments, étendant
le DTO DonneesCommunesDto, à l’image des DTO déjà existants (en particulier la mise à jour de la map
« propriété du DTO/Champs SolR » déclarée dans DonneesCommunesDto).
6.4.
Modification du DTO de recherche
Il faut modifier le DTO RechercheDto pour traiter les nouveaux champs du nouveau type d’éléments et
mettre à jour la map « propriété du DTO/Champs SolR ».
Il faut également modifier ce DTO pour ajouter les méthodes de préparation à la recherche en fonction
des différentes possibilités de recherche du nouvel élément (lié à chaque constante de la forme
LOCATION_* définies dans le fichier de constantes), à l’image des méthodes déjà existantes.
6.5.
Modification du DAO de recherche
Il faut modifier le DAO de recherche RechercheDaoImpl pour modifier la méthode
prepareRechercheSuivantLocation pour prendre en compte les différentes possibilités de recherche du
nouvel élément (lié à chaque constante de la forme LOCATION_* définies dans le fichier de constantes),
à l’image du traitement déjà existant.
Page 19 de 20
6.6.
Modification des Business et DAO d’indexation
Il faut ajouter les différentes méthodes d’indexation et de réindexation du nouveau type d’éléments à
l’image de celles déjà existantes.
Il s’agit des méthodes de la forme indexe<type_d_element>, indexe<type_d_element>List et
reindexeContenu<type_d_element>.
Page 20 de 20

Dossier de Spécifications Techniques Détaillées API indexation

Transcription

Documents pareils

Montage photo simple avec Photofiltre

Indexation avec Solr - Bases de données documentaires et distribuées

27/06/2016 Plage du Prado

Votre tenue - Kipsta Club

Caissons de basses : Sub Focal Dimension

Memory Game en JavaScript

, be ri i n .e Re g u i a t i o n s,.o rg ^.^^^

Forum: Dépannage

EPREUVE D`HISTOIRE DES ARTS SUJET : GEN D`HIROSHIMA