ࡱ > bjbjVV < < x
26 26 zC zC zC zC zC 4 C C C h D F $ C R G N O O P R Y r[ $ X zC 5] R " R 5] 5] zC zC O P s s s 5]
zC O zC P s 5] s s 0 O 0 @dh C k j q 0 { m . ' ' zC t> j\ ~\ s \ \ j\ j\ j\ 7p j\ j\ j\ 5] 5] 5] 5] j\ j\ j\ j\ j\ j\ j\ j\ j\ 26 @B :
Spcification technique
Dossier de Spcifications Techniques Dtailles
API indexation/recherche
Auteur : DOCPROPERTY Author \* MERGEFORMAT Logica et Rgion le-de-France SKIPIF \* MERGEFORMAT
Version : 0.2
Droit dauteur
Ce document est disponible sous contrat Creative Commons Paternit - Pas d'Utilisation Commerciale - Partage des Conditions Initiales l'Identique 2.0 France: HYPERLINK "http://creativecommons.org/licenses/by-nc-sa/2.0/fr/" http://creativecommons.org/licenses/by-nc-sa/2.0/fr/
Historique des volutions
Vers.DateAuteursDescription0.101/03/2011Laurent BILLIOTTEInitialisation du document0.225/07/2011Marion MAURINRelecture
Sommaire TOC \o "1-3" \h \z \u
HYPERLINK \l "_Toc299386337" Historique des volutions PAGEREF _Toc299386337 \h 2
HYPERLINK \l "_Toc299386338" Sommaire PAGEREF _Toc299386338 \h 3
HYPERLINK \l "_Toc299386339" 1. Objectif PAGEREF _Toc299386339 \h 5
HYPERLINK \l "_Toc299386340" 2. Choix des outils techniques PAGEREF _Toc299386340 \h 6
HYPERLINK \l "_Toc299386341" 3. Configuration de la partie socle PAGEREF _Toc299386341 \h 7
HYPERLINK \l "_Toc299386342" 3.1. Configuration du serveur SolR PAGEREF _Toc299386342 \h 7
HYPERLINK \l "_Toc299386343" 3.2. Schma PAGEREF _Toc299386343 \h 7
HYPERLINK \l "_Toc299386344" 3.2.1. Particularit des champs gen_* PAGEREF _Toc299386344 \h 9
HYPERLINK \l "_Toc299386345" 3.2.2. Champ gen_id PAGEREF _Toc299386345 \h 9
HYPERLINK \l "_Toc299386346" 3.2.3. Champ gen_type PAGEREF _Toc299386346 \h 9
HYPERLINK \l "_Toc299386347" 3.2.4. Champs gen_droits_* PAGEREF _Toc299386347 \h 9
HYPERLINK \l "_Toc299386348" 3.2.5. Champs gen_auteur_* PAGEREF _Toc299386348 \h 9
HYPERLINK \l "_Toc299386349" 3.2.6. Champ gen_date PAGEREF _Toc299386349 \h 10
HYPERLINK \l "_Toc299386350" 3.2.7. Champ gen_visibilite PAGEREF _Toc299386350 \h 10
HYPERLINK \l "_Toc299386351" 3.2.8. Champ description PAGEREF _Toc299386351 \h 10
HYPERLINK \l "_Toc299386352" 3.2.9. Champ porteur_droits_id PAGEREF _Toc299386352 \h 10
HYPERLINK \l "_Toc299386353" 3.2.10. Champ porteur_projet_id PAGEREF _Toc299386353 \h 10
HYPERLINK \l "_Toc299386354" 3.2.11. Champs doc_* PAGEREF _Toc299386354 \h 10
HYPERLINK \l "_Toc299386355" 3.2.12. Champs blog_* PAGEREF _Toc299386355 \h 11
HYPERLINK \l "_Toc299386356" 3.2.13. Champs forum_* PAGEREF _Toc299386356 \h 11
HYPERLINK \l "_Toc299386357" 3.2.14. Champs actu_* PAGEREF _Toc299386357 \h 11
HYPERLINK \l "_Toc299386358" 3.2.15. Champ gen_actu_date_expiration PAGEREF _Toc299386358 \h 11
HYPERLINK \l "_Toc299386359" 3.2.16. Champs cahier_* PAGEREF _Toc299386359 \h 11
HYPERLINK \l "_Toc299386360" 3.2.17. Champs messagerie_* PAGEREF _Toc299386360 \h 11
HYPERLINK \l "_Toc299386361" 4. Rappel sur la gestion des droits dans lENT PAGEREF _Toc299386361 \h 12
HYPERLINK \l "_Toc299386362" 5. API dutilisation pour les modules PAGEREF _Toc299386362 \h 14
HYPERLINK \l "_Toc299386363" 5.1. Constantes PAGEREF _Toc299386363 \h 14
HYPERLINK \l "_Toc299386364" 5.2. Indexation PAGEREF _Toc299386364 \h 15
HYPERLINK \l "_Toc299386365" 5.2.1. DTO PAGEREF _Toc299386365 \h 15
HYPERLINK \l "_Toc299386366" 5.2.2. Mthodes dindexation dun nouvel lment PAGEREF _Toc299386366 \h 15
HYPERLINK \l "_Toc299386367" 5.2.3. Mthodes de rindexation du contenu dun lment existant PAGEREF _Toc299386367 \h 15
HYPERLINK \l "_Toc299386368" 5.2.4. Mthodes de rindexation des droits daccs un lment existant PAGEREF _Toc299386368 \h 16
HYPERLINK \l "_Toc299386369" 5.2.5. Mthodes de dsindexation (suppression) PAGEREF _Toc299386369 \h 16
HYPERLINK \l "_Toc299386370" 5.3. Recherche PAGEREF _Toc299386370 \h 17
HYPERLINK \l "_Toc299386371" 5.3.1. DTO PAGEREF _Toc299386371 \h 17
HYPERLINK \l "_Toc299386372" 5.3.2. Mthode de recherche PAGEREF _Toc299386372 \h 18
HYPERLINK \l "_Toc299386373" 6. Modification du socle pour un nouveau type dlment PAGEREF _Toc299386373 \h 19
HYPERLINK \l "_Toc299386374" 6.1. Modification du schma SolR PAGEREF _Toc299386374 \h 19
HYPERLINK \l "_Toc299386375" 6.2. Dfinition des constantes PAGEREF _Toc299386375 \h 19
HYPERLINK \l "_Toc299386376" 6.3. Cration du DTO dindexation PAGEREF _Toc299386376 \h 19
HYPERLINK \l "_Toc299386377" 6.4. Modification du DTO de recherche PAGEREF _Toc299386377 \h 19
HYPERLINK \l "_Toc299386378" 6.5. Modification du DAO de recherche PAGEREF _Toc299386378 \h 19
HYPERLINK \l "_Toc299386379" 6.6. Modification des Business et DAO dindexation PAGEREF _Toc299386379 \h 20
Objectif
Comme vu dans la documentation sur lensemble du socle applicatif, la solution Lilie propose des outils dindexation et de recherche centralise pour les donnes des diffrents services. Les recherches internes chaque module sont effectues directement en SQL dans les bases de donnes, mais un module spcifique web-recherche propose une recherche globale tous les services. Celle-ci fonctionne par lintermdiaire dun moteur de recherche (du style de Google) sur des donnes structures dune manire diffrente du dcoupage interne de chaque module. On peut ainsi y indexer la fois des donnes brutes de bases de donnes et des documents de bureautique (.doc par exemple).
Outre la centralisation des donnes pour une recherche globale, ceci permet de rechercher de manire plutt textuelle et gnrique dans les contenus des modules, en utilisant des fonctionnalits comme la synonymie ou la lemmatisation sur les termes recherchs.
Pour obtenir ces fonctionnalits, les modules doivent utiliser lapi-recherche du socle de lENT, afin dindexer leurs donnes.
Ce document dcrit techniquement cette API, aussi bien en termes dutilisation pour un module quen termes de maintenance de lapi elle-mme.
Choix des outils techniques
LAPI dindexation et de recherche sappuie sur le moteur dindexation et de recherche standard Lucene/SolR ( HYPERLINK "http://lucene.apache.org/solr/" http://lucene.apache.org/solr/), une application stand-alone de la fondation Apache.
Les applications Lilie communiquent avec SolR grce la bibliothque SolRJ ( HYPERLINK "http://wiki.apache.org/solr/Solrj" http://wiki.apache.org/solr/Solrj), fournie avec SolR. Cette librairie est embarque dans lapi-recherche.
Lindexation de documents riches (PDF, documents Word etc) sappuie sur la bibliothque Tika ( HYPERLINK "http://tika.apache.org/" http://tika.apache.org/) de la fondation Apache. Cette librairie est embarque par lapi-recherche.
Configuration de la partie socle
Configuration du serveur SolR
Le fichier de configuration principal de SolR est le fichier solrconfig.xml, situ dans le rpertoire conf de lapplication SolR.
La version de ce fichier de configuration utilis pour Lilie est prsente dans le projet solr-custom du socle.
Ce fichier permet de dfinir entres autres les paramtres de mmoire et les diffrents gestionnaires de requtes utiliss par SolR.
Schma
SolR indexe les donnes quil reoit selon un schma de donnes dfini dans le fichier schema.xml.
La version de ce fichier utilis pour Lilie est prsente dans le projet solr-custom du socle.
Ce fichier permet entres autres de
dfinir les diffrents types de donnes indexes (texte, boolen, integer, date etc) et comment les traiter lors dune indexation et/ou dune recherche.
dfinir les diffrents champs indexs pour les diffrentes applications de Lilie et comment indexer les donnes de ces champs.
dfinir une clef unique pour chaque objet index
dfinir loprateur par dfaut utiliser entre plusieurs termes lors dune recherche
Les champs dfinis pour Lilie (version 1.4.9) sont les suivants:
Le champ gen_id correspond la clef unique du document:
gen_id
Loprateur par dfaut est le ou:
Particularit des champs gen_*
Les champs dont le nom est prfix par gen_ sont traits particulirement par lAPI dindexation et de recherche.
En effet, lors de la cration de la requte SolR de recherche par lAPI, tous les termes associs ces champs sont prcds dun AND dans la requte et sont donc considrs comme des restrictions fortes.
Par exemple, en recherchant les actualits contenant le terme JEE dont le prnom de lauteur est Louis, la requte constitue sera de la forme:
(actu_article:JEE OR actu_titre:JEE OR description:JEE) AND gen_auteur_prenom:Louis AND gen_type:ACTU
Champ gen_id
Ce champ correspond lidentifiant unique de lobjet index.
Il est constitu dun prfixe correspondant au type de llment suivi de lidentifiant de llment tel quil est connu dans lapplication appelant lAPI dindexation.
Par exemple, lactualit dont lidentifiant est 123 dans lapplication des actualits est indexe avec lidentifiant AC_123.
Il est obligatoire et de type string, donc index tel quel.
Champ gen_type
Ce champ correspond au type de lobjet index (actualit, message de forum, activit du cahier de texte).
Il est obligatoire et de type string, donc index tel quel.
Champs gen_droits_*
Ces champs correspondent aux droits ports par lobjet index et sont utiliss lors de la recherche en les confrontant aux droits de la personne effectuant la recherche (Voir HYPERLINK \l "_Rappel_sur_la" Rappel sur la gestion des droits).
Ces champs permettent de stocker les listes didentifiants des utilisateurs, des groupes et des tablissements, spars par des espaces, ayant accs lobjet.
Ils sont obligatoires et de type text pour permettre lindexation de chaque identifiant comme un mot.
Champs gen_auteur_*
Ces champs correspondent au nom et au prnom de lauteur de lobjet index.
Ils sont obligatoires et de type text, donc traits comme des mots.
Champ gen_date
Ce champ correspond la date laquelle lobjet a t index.
Il est obligatoire et de type date.
Champ gen_visibilite
Ce champ permet dindiquer que lobjet index nest pas publi ou est cach et quil ne doit donc pas tre retourn lors dune recherche.
Ce champ est utilis par exemple lors de la modration des messages du forum, lorsque le modrateur cache un message quil ne souhaite plus voir apparatre. Le message est alors rindex en positionnant ce champ 0 (non visible).
Ce champ est de type boolean et par dfaut a la valeur 1 (visible).
Champ description
Ce champ contient la description de lobjet index. Il est utilis dans lcran de recherche pour afficher la description ou un aperu de lobjet index dans les rsultats de recherche.
Il est obligatoire et de type text.
Champ porteur_droits_id
Ce champ permet de dfinir une relation entre deux objets (Voir HYPERLINK \l "_Rappel_sur_la" Rappel sur la gestion des droits). Il permet dindiquer quel est lobjet parent de lobjet courant, cet objet parent tant lobjet sur lequel les droits sont affects. Cet identifiant permet de rindexer les droits des objets fils dun lment lorsque les droits de ce dernier sont modifis. Il permet galement de supprimer tous les lments fils lorsquun lment parent est supprim.
Par exemple, les messages des blogs portent dans ce champ lidentifiant du blog de manire rindexer les messages avec les droits adquats lorsque les droits du blog sont modifis, ou supprimer tous les messages associs un blog lorsque ce dernier est supprim.
Si lobjet na pas de parent, alors on stocke dans ce champ lidentifiant de lobjet lui-mme.
Il est obligatoire et de type string, donc index tel quel.
Champ porteur_projet_id
Ce champ contient le code du porteur de projet li cet objet.
Il est obligatoire et de type string, donc index tel quel.
Champs doc_*
Ces champs correspondent aux diffrents champs indexs pour les documents de lespace de travail.
Champs blog_*
Ces champs correspondent aux diffrents champs indexs pour les blogs.
Champs forum_*
Ces champs correspondent aux diffrents champs indexs pour les forums.
Champs actu_*
Ces champs correspondent aux diffrents champs indexs pour les actualits.
Champ gen_actu_date_expiration
Ce champ est un champ particulier des champs indexs pour les actualits.
Son nom est prfix par gen_ pour dfinir une restriction forte sur cette proprit (prcde dun AND et non dun OR par dfaut).
Ce champ nest valoris que pour les lments de type actualit頻, avec la date dexpiration de lactualit (date laquelle cette actualit nest plus publie et donc ne doit plus tre retourne par la recherche).
Pour les autres types dlments, cette date est valorise automatiquement avec la date du 31/12/2999.
Champs cahier_*
Ces champs correspondent aux diffrents champs indexs pour les cahiers des textes et leurs ressources et activits.
Champs messagerie_*
Ces champs correspondent aux diffrents champs indexs pour la messagerie.
Rappel sur la gestion des droits dans lENT
Chaque utilisateur connect Lilie est caractris, au niveau de la gestion des droits, par diffrentes informations:
le code porteur de lutilisateur
le profil de lutilisateur: utilisateur normal, utilisateur administrateur local, utilisateur super administrateur etc
lidentifiant de lutilisateur
les groupes auxquels est associ lutilisateur dans le cas dun utilisateur normal (groupes scolarits et groupe crs via la console dadministration)
les tablissements auxquels est associ lutilisateur dans le cas dun utilisateur administrateur local (les tablissements pour lesquels lutilisateur est dclar administrateur local).
A chaque entit du module (actualits, blogs, cahier de textes etc) sont attribues, au niveau de la gestion des droits, les informations suivantes:
le code porteur de lentit
la liste des utilisateurs ayant directement accs lentit
la liste des groupes ayant accs lentit
la liste des tablissements concerns par cette entit (c'est--dire la liste des tablissements des utilisateurs et des groupes ayant accs cette entit)
Laccs aux entits par un utilisateur est obtenu en confrontant les informations de droits portes par lutilisateur aux informations de droits portes par lentit. Un utilisateur a accs une entit si:
il est un utilisateur normal et son code porteur correspond celui de lentit et [son identifiant apparait dans la liste des identifiants dutilisateurs ayant accs lentit ou il appartient un groupe ayant accs lentit].
Il est utilisateur administrateur local et son code porteur correspond celui de lentit et il est administrateur local dun tablissement concern par lentit
Il est utilisateur super administrateur et son code porteur correspond celui de lentit.
Les rsultats dune recherche par lAPI dindexation et de recherche doivent rpondre ces mmes rgles daccs aux entits. Cest pourquoi les donnes concernant les droits daccs aux entits sont indexes avec chacune delles dans les champs gen_droits_users, gen_droits_groupes, gen_droits_etablissements et porteur_projet_id.
Lors dune recherche, lAPI ajoute automatiquement la requte SolR de recherche les restrictions effectuer sur ces champs en fonctions des donnes de lutilisateur qui effectue la recherche (donnes contenues dans le DTO CritereRechercheDto pass la mthode de recherche). Seules les donnes rpondant aux rgles ci-dessus sont donc retournes.
Cas particulier des entits parents porteuses de droits:
Pour certains types dentits, les droits sont ports par une entit parent. Cest par exemple le cas du blog: le blog est lentit qui porte les droits, les messages du blog possdent les droits dfinis sur le blog auquel ils appartiennent.
Pour retourner les entits filles correctes vis--vis de la gestion des droits lors dune recherche, les entits filles doivent tre indexes avec les droits de lentit parent. On indexera donc, par exemple, un message du blog en lui attribuant les droits ports par le blog auquel il appartient.
De ce fait, lors de la modification des droits dune entit parent, il est ncessaire de rindexer lensemble des entits filles associes. Pour ce faire, le champ porteur_droits_id est dfini dans le schma SolR. Ce champ contient lidentifiant de lentit parent pour chaque entit fille (NB: dans le cas o lentit na pas deparent, ce champ doit contenir lidentifiant de lentit elle-mme). Ce champ permet donc de retrouver directement lensemble des entits filles dun lment pour pouvoir les rindexer avec leurs nouveaux droits le cas chant.
API dutilisation pour les modules
LAPI dindexation et de recherche est disponible dans le projet api-recherche du socle. Elle doit tre utilise par tous les modules comme interface avec le serveur SolR.
LAPI dfinit un certains nombre de DTO et de mthodes pouvant tre regroups en deux catgories principales:
DTO et mthodes dindexation
DTO et mthodes de recherche
Elle dfinit galement des constantes utiles pour la manipulation de ces DTO et mthodes.
Constantes
Les constantes dfinies par lAPI sont dclares dans la classe ConstantesApiRecherche.
Les principales constantes sont:
celles dont le nom est de la forme PREFIX_ qui dfinissent pour chaque type dlment le prfixe utiliser pour la constitution de lidentifiant dun lment de ce type dans SolR (champ gen_id).
Par exemple, PREFIX_ACTU vaut AC_, ce qui signifie que toutes les actualits indexes dans SolR seront identifies par un identifiant commenant par AC_
celles dont le nom est de la forme FILTRE_ qui dfinissent les diffrents types dlments grs dans SolR.
Cette constante est utilise pour valoriser le champ gen_type de chaque lment index. Ceci permet, lors dune recherche sur un type dlment particulier, de positionner le paramtre de filtre de la requte 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 dfinissent les diffrentes options de recherche pour chaque type dlment, comme par exemple la recherche uniquement sur le titre dune actualit, ou uniquement sur le contenu dune actualit.
la constante STYLECSSSURLIGNAGE qui dfinit le nom du style CSS que SolR doit utiliser pour appliquer le surlignage des termes dans les rsultats dune recherche.
la constante GROUPE_DROIT_PUBLIC qui dfinit la valeur utiliser comme identifiant de groupe pour dfinir un lment comme publique (accessible tous)
les constantes dont le nom est de la forme CHAMPS_* qui dfinissent pour chaque type dlment la liste des champs attendus en retour dune recherche
Indexation
DTO
A chaque type dlment pouvant tre index correspond un DTO Java.
On trouve donc, par exemple, les DTO ActualiteDto, BlogDto, ForumDto etc
Certaines informations tant communes chaque lment, ces informations sont regroupes dans le DTO DonneesCommunesDto que chaque DTO tend.
Chacun des DTO dfinit galement une map liensProprieteIndex tablissant la correspondance entre les proprits du DTO et les champs SolR correspondants, ainsi que deux mthodes:
getNomIndex qui permet dobtenir le nom dun champ de SolR correspondant une proprit du DTO
getNomProprieteDto qui permet dobtenir le nom dune proprit du DTO correspondant un champ de SolR.
Mthodes dindexation dun nouvel lment
Ces mthodes permettent dindexer un nouvel lment dans le moteur SolR en lui fournissant lensemble des donnes indexer pour cet lment, y compris les donnes concernant les droits. Ces donnes sont portes par un DTO correspondant llment et il existe autant de mthodes que de type dlments pouvant tre indexs.
Ces mthodes correspondent toutes les mthodes dont le nom est de la forme indexe du business IndexeBusiness.
Par exemple la mthode dindexation dune actualit:
public boolean indexeActu(ActualiteDto actuDtoAIndexer)
throws ServiceTechniqueException, ServiceFonctionnelleException;
Toutes ces mthodes ont leur quivalent qui traite une liste dlment au lieu dun lment seul. Il sagit des mthodes dont le nom est de la forme indexeList du business IndexeBusiness.
Par exemple la mthode dindexation dune liste dactualits:
public boolean indexeActuList(List < ActualiteDto > actuDtoListAIndexer)
throws ServiceTechniqueException, ServiceFonctionnelleException;
Ces mthodes retournent toutes un boolen indiquant si lopration sest correctement droule.
Mthodes de rindexation du contenu dun lment existant
Ces mthodes permettent de rindexer le contenu dun lment ayant dj t index et dont le contenu, mais pas les droits, doit tre modifi. Les droits seront conservs lidentique de ce qui tait dj index. Toutes les autres donnes doivent tre fournies, tout particulirement lidentifiant correspondant au champ gen_id de SolR pour identifier llment modifier.
Ces mthodes correspondent toutes les mthodes dont le nom est de la forme reindexeContenu du business IndexeBusiness.
Par exemple la mthode qui rindexe le contenu dune actualit:
public boolean reindexeContenuActu(ActualiteDto actuDtoAIndexer)
throws ServiceTechniqueException, ServiceFonctionnelleException;
Ces mthodes retournent toutes un boolen indiquant si lopration sest correctement droule.
NB: si aucun lment nexiste dans SolR avec le mme identifiant, cette mthode retourne false et nindexe rien.
Mthodes de rindexation des droits daccs un lment existant
Ces mthodes, du business IndexeBusiness, permettent de rindexer les champs correspondant aux droits daccs dun lment (gen_droits_users, gen_droits_groupes et gen_droits_etablissements) en conservant le reste des donnes lidentique.
Il existe pour ce faire 2 mthodes diffrentes.
La premire mthode permet de rindexer les droits dun lment unique partir de lidentifiant de cet lment :
public boolean reindexeDroitsElementParId(String idDocumentAReindexer,
List < Long > listeEtablissementsId,
List < Long > listeGroupesId,
List < Long > listeUtilisateursId)
throws ServiceTechniqueException, ServiceFonctionnelleException;
Cette mthode prend donc en paramtre lidentifiant de llment rindexer 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 mthode retourne un boolen indiquant si lopration sest correctement droule.
NB: si aucun lment nexiste dans SolR avec le mme identifiant, cette mthode retourne false et nindexe rien.
La deuxime mthode permet de rindexer les droits de tous les lments fils dun autre lment:
public boolean reindexeDroitsParIdPorteurDroits(String dElementPorteurDroits,
List < Long > listeEtablissementsId,
List < Long > listeGroupesId,
List < Long > listeUtilisateursId)
throws ServiceTechniqueException, ServiceFonctionnelleException {
Cette mthode prend donc en paramtre lidentifiant de llment parent (lidentifiant de llment porteur des droits) et lance une recherche dans SolR pour obtenir lensemble des lments dont le champ porteur_droits_id vaut cet identifiant. Chaque lment fils ainsi obtenu est ensuite rindex avec les nouvelles listes didentifiants dutilisateurs, groupes et tablissements passs en paramtre la mthode. Ces listes doivent tre exhaustives (elles annulent et remplacent les listes existantes).
Cette mthode retourne un boolen indiquant si lopration sest correctement droule.
Mthodes de dsindexation (suppression)
Ces mthodes permettent de supprimer des index SolR un ou plusieurs lments.
Il existe pour ce faire 3 mthodes diffrentes.
La premire mthode permet de supprimer un lment unique partir de son identifiant:
public boolean supprimeParId(String identifiant)
throws ServiceTechniqueException, ServiceFonctionnelleException
Cette mthode prend donc en paramtre lidentifiant de llment supprimer et supprime des index SolR toutes les donnes concernant llment correspondant.
Cette mthode retourne un boolen indiquant si lopration sest correctement droule.
La deuxime mthode permet de supprimer un lment et tous ses lments fils partir de son identifiant:
public boolean supprimeParIdPorteurDroits(String identifiantPorteurDroits)
throws ServiceTechniqueException, ServiceFonctionnelleException
Cette mthode prend donc en paramtre lidentifiant de llment parent supprimer (lidentifiant de llment porteur des droits) et lance une recherche dans SolR pour obtenir lensemble des lments dont le champ porteur_droits_id vaut cet identifiant. Chaque lment fils ainsi obtenu est ensuite supprim des index SolR.
Cette mthode retourne un boolen indiquant si lopration sest correctement droule.
La troisime mthode permet de supprimer lensemble des lments dun mme type(par exemple toutes les actualits) :
public boolean supprimeParType(String typeElementASupprimerStr)
throws ServiceTechniqueException, ServiceFonctionnelleException
Cette mthode prend donc en paramtre le type des lments supprimer et supprime des index SolR tous les lments de ce type.
Cette mthode retourne un boolen indiquant si lopration sest correctement droule.
Recherche
DTO
Deux DTO sont dfinis pour la partie recherche de lAPI: CritereRechercheDto et RechercheDto.
CritereRechercheDto reprsente lensemble des critres de recherche possibles pour une recherche dlments. Ces critres sont:
les termes/mots rechercher
le nom de lauteur
le prnom de lauteur
la date minimale de publication (les documents retourns doivent tre publis aprs cette date)
la date maximale de publication (les documents retourns doivent tre publis avant cette date)
Pour la gestion des droits daccs aux lments indexs, CritereRechercheDto contient galement les proprits suivantes:
lidentifiant de lutilisateur effectuant la recherche
les identifiants des groupes de lutilisateur effectuant la recherche
les identifiants des tablissements de lutilisateur effectuant la recherche ( renseigner dans le cas o lutilisateur est un administrateur local)
le code du porteur de projet
RechercheDto est un DTO reprsentant les rsultats de la recherche. La recherche pouvant retourner une liste dlments de diffrents types (des actualits, des blogs, des forums etc), ce DTO contient donc toutes les proprits possibles retournes pour chaque type dlments.
Mthode de recherche
La mthode de recherche est dfinie dans le business RechercheBusiness:
public List < Object > recherche(CritereRechercheDto critereRechercheDto,
String locationRecherche,
boolean rechercherTousTermes,
boolean surlignage,
int nbResultat,
String styleCssSurlignage)
throws ServiceTechniqueException, ServiceFonctionnelleException
Elle prend en paramtre:
une instance de CritereRechercheDto reprsentant les critres de la recherche
une chane de caractres indiquant sur quels champs SolR effectuer la recherche et devant correspondre une des valeurs des constantes de la forme LOCATION_* de ConstantesApiRecherche.
un boolen indiquant si les lments retourns doivent contenir tous les termes de la recherche ou si la prsence dun seul suffit
un boolen indiquant si lon souhaite que SolR surligne dans les rsultats les termes qui ont conduit ce quun lment soit retourn
le nombre de rsultat maximum attendu
le nom du style CSS appliquer pour le surlignage des termes dans les rsultats (en relation avec le boolen surlignage)
Elle retourne une liste dobjet (instances de RechercheDto) contenant pour chaque lment retourn les proprits (correspondantes au type de llment) renseignes avec les valeurs de llment.
Modification du socle pour un nouveau type dlment
Pour modifier lapi-recherche en vue de traiter un nouveau type dlments en indexation et en recherche, voici les diffrentes tapes suivre.
Modification du schma SolR
Il faut modifier le fichier schema.xml de SolR pour dfinir les nouveaux champs correspondant aux proprits indexer pour le nouveau type dlments.
Dfinition des constantes
Il faut ajouter dans les constantes de la classe ConstantesApiRecherche les constantes suivantes:
la constante PREFIX_ pour le nouveau type avec une valeur distincte des valeurs dj existantes pour les autres prfixes
la constante FILTRE_ pour le nouveau type avec une valeur distincte des valeurs dj existantes pour les autres filtres
les constantes de la forme LOCATION_* pour dfinir les diverses recherches possibles sur le nouveau type
la constante CHAMPS_SPECIFIQUES_ pour dfinir les diffrents champs spcifiques au nouveau type
mettre jour la constante CHAMPS_SPECIFIQUES_TOUT pour ajouter les champs spcifiques au nouveau type.
Cration du DTO dindexation
Il faut crer le nouveau DTO utilis lors de lindexation reprsentant le nouveau type dlments, tendant le DTO DonneesCommunesDto, limage des DTO dj existants (en particulier la mise jour de la map proprit du DTO/Champs SolR dclare dans DonneesCommunesDto).
Modification du DTO de recherche
Il faut modifier le DTO RechercheDto pour traiter les nouveaux champs du nouveau type dlments et mettre jour la map proprit du DTO/Champs SolR.
Il faut galement modifier ce DTO pour ajouter les mthodes de prparation la recherche en fonction des diffrentes possibilits de recherche du nouvel lment (li chaque constante de la forme LOCATION_* dfinies dans le fichier de constantes), limage des mthodes dj existantes.
Modification du DAO de recherche
Il faut modifier le DAO de recherche RechercheDaoImpl pour modifier la mthode prepareRechercheSuivantLocation pour prendre en compte les diffrentes possibilits de recherche du nouvel lment (li chaque constante de la forme LOCATION_* dfinies dans le fichier de constantes), limage du traitement dj existant.
Modification des Business et DAO dindexation
Il faut ajouter les diffrentes mthodes dindexation et de rindexation du nouveau type dlments limage de celles dj existantes.
Il sagit des mthodes de la forme indexe, indexeList et reindexeContenu.
Dossier de Spcifications Techniques Dtailles
API indexation/recherche
FILENAME SPECTECH -API indexation-recherche.docPage PAGE \* MERGEFORMAT 1 de NUMPAGES \* MERGEFORMAT 20
Dossier de Spcifications Techniques Dtailles
API indexation/recherche
FILENAME SPECTECH -API indexation-recherche.docPage PAGE \* MERGEFORMAT 6 de NUMPAGES \* MERGEFORMAT 10
FILENAME SPECTECH -API indexation-recherche.docPage PAGE \* MERGEFORMAT 5 de NUMPAGES \* MERGEFORMAT 7
Dossier de Spcifications Techniques Dtailles
API indexation/recherche
FILENAME SPECTECH -API indexation-recherche.docPage PAGE \* MERGEFORMAT 20 de NUMPAGES \* MERGEFORMAT 20
P h i j k m o p w { | ԛ||mme]e hr nHtH ht nHtH j hzV hr UnHtHh nHtH j h UnHtHhzV hr nHtH hzV hr 5nHtHh hr hG 5CJ0 \^J aJ0 nH tH &hr hr 5CJ0 \^J aJ0 nH tH hzV hr hzV hr 5CJ aJ hr 5CJ aJ hnr 5B* CJ OJ QJ ph P i j k l m n o p
gdr gdr g gdr
$d&dN P gdr gdr $a$gdr $@&