  Télécharger InstallerPrésentationConfigurationIndexationRechercheOAIJavadocRéférence API-XSP Migration Configuration 
Sitemap
API-XSPAPI-URLSchemasPerformances
| La configuration d'une application SDX-2 issue d'une application SDX-1Ce document ne constitue pas la documentation complète concernant la configuration d'une application SDX-2. Nous allons seulement indiquer comment les informations de configuration de SDX-1 doivent être modifiées pour la version 2. En d'autres mots, il s'agit d'un guide qui permet de transformer le fichier de configuration d'une application SDX-1 (db_info.xml) en fichier de configuration d'une application SDX-2 (application.xconf). Avant de lire ce guide, il est important de lire et comprendre la section de la documentation qui introduit l'architecture de SDX-2. En particulier, il est important de comprendre les notions d' applications , de bases de documents et d' entrepôts de documents . De plus, il pourra être utile de se référer à la documentation complète de la configuration d'une application SDX-2 pour ajouter des paramètres inexistants en SDX-1 et donc non discutés ici. En version 1, la configuration d'une application SDX est contenue dans un document XML qui se situait nécessairement dans un fichier db_info.xml situé dans un dossier nommé conf qui se situe dans le dossier de l'application. Par exemple, pour une application SDX avec identifiant test, la configuration est dans le fichier webapps/sdx/test/conf/db_info.xml. En version 2, la situation est presque la même. En effet, la configuration est toujours contenue dans un document XML ; ce document XML est toujours situé dans le dossier conf d'une application, mais il s'appelle maintenant application.xconf. Nous devons également souligner que le nom du dossier dans lequel réside une application sous SDX n'a plus besoin de coïncider avec son identifiant, ce qui laisse une certaine souplesse dans le déploiement des applications. Le fichier de configuration d'une application SDX-1 commence de cette manière : <sdx:dbInfo code="sdxdoc" xmlns:sdx="http://www.culture.gouv.fr/ns/sdx/sdx"> En SDX-2, cet élément supérieur devient plutôt quelque chose comme :
<sdx:application
id="fr.gouv.culture.sdx.sdxworld"
xml:lang="fr"
xmlns:sdx="http://www.culture.gouv.fr/ns/sdx/sdx">
On doit noter ici que l'élément supérieur est maintenant <sdx:application/>, que l'attribut code a disparu, que l'espace de noms SDX est le même, et que deux nouvelles informations font leur entrée :
La suite du fichier de configuration SDX-1 est un élément <sdx:configuration/> qui contient des informations sur les langues (<sdx:languages/>), les locales (<sdx:locales/>), la configuration de l'outil de recherche (<sdx:lucene/>), les catalogues d'entités externes (<sdx:catalogs/>), la transformation d'indexation (<sdx:extraction/>), la transformation préliminaire (<sdx:transformation/>) ainsi que certains paramètres (<sdx:parameters/>). L'élément <sdx:configuration/> lui-même n'est plus nécessaire. Nous avons déjà vu comment indiquer la langue par défaut d'une application, les autres méthodes de spécification de langues seront indiquées lorsqu'elles s'appliquent. Les éléments <sdx:languages/> et <sdx:locales/> ne sont donc plus nécessaires et peuvent être ignorés. La configuration de l'outil de recherche ne se fait plus globalement comme dans SDX-1, c'est pourquoi l'élément <sdx:lucene/> n'est plus utile non plus. Son contenu sera réutilisé ailleurs dans la configuration. Les catalogues d'entités externes sont toujours utiles en SDX-2, et leur configuration est presque la même. Le seul changement, c'est l'attribut file qui est renommé src, par souci de cohérence. Son contenu est une URL relative à l'endroit où se situe le fichier de configuration. On peut insérer l'élément <sdx:catalogs/> et ses sous-éléments directement sous <sdx:application/>. Les éléments <sdx:extraction/> et <sdx:transformation/> sont importants car ils indiquent les transformations XSLT à utiliser pour indexer et peut-être transformer préalablement les documents XML dans SDX. En version 2, ces informations sont précisées selon un mécanisme nettement plus puissant appelé pipeline. Ces deux éléments peuvent donc être supprimés. Enfin, les paramètres... TODO. Dans la configuration d'une application SDX-1, il était possible de décrire une application en insérant un élément <sdx:informations/> et ses sous-éléments. En SDX-2, ces éléments n'existent plus. Toutefois, si vous voulez ajouter toute autre information au document XML de configuration (application.xconf), vous pouvez le faire, en autant que vous respectiez ces deux consignes :
Cette manière de procéder est nettement plus souple. Nous voulons toutefois signaler qu'il est possible que des informations standards de description des applications SDX soient proposées, par exemple en utilisant des métadonnées Dublin Core. La dernière partie de la configuration d'une application SDX-1 concerne les champs de recherche, définis dans un élément <sdx:fieldList/>. En SDX-2, cette liste de champs sera aussi présente, mais dans le contexte d'une base de documents (voir l'architecture). Une application SDX-1 est conçue, par définition, avec une seule base de documents et un seul entrepôt, car ces concepts ne sont pas vraiment présents en SDX-1. A tout le moins, le développeur ne peut pas effectuer de choix ou de configuration particulière. Nous allons donc supposer que la migration s'effectue vers une application SDX-2 à une seul base et un seul entrepôt de documents. Les documents XML indexés par SDX-1 sont stockés dans une base de données relationnelle, par exemple MySQL. Cette option peut aussi être choisie en SDX-2, mais elle n'est pas la seule disponible. On peut également choisir un entrepôt système de fichiers ou un entrepôt URL. Cet aspect de la configuration étant inexistant en SDX-1, nous vous invitons à consulter la documentation sur la configuration des entrepôts pour savoir comment effectuer cette partie de la migration. Soulignons toutefois que les documents XML ne pourront pas rester dans votre base relationnelle SDX-1, sauf si vous utilisez un entrepôt URL et que vous mettez en place un outil pour servir ces documents depuis des URL. Cette approche ne permet pas, toutefois, l'ajout de documents par SDX. Vous pouvez donc effectuer votre choix de type et de configuration d'entrepôt sans tenir compte du fait que vous migrez depuis SDX-2. La configuration de la base de documents sera relativement simple lors d'une migration, car les principales informations sont déjà présentes dans la configuration de l'application en version 1. La documentation de référence concernant la configuration des bases de documents pourra vous être utile si vous voulez aller plus loin. Vous devrez d'abord déterminer un identifiant pour votre base de documents, et normalement votre base (unique) devrait être la base par défaut. Le début de la configuration sera donc semblable à ceci : <sdx:documentBase id="mon_id" type="lucene" default="true"> Ensuite, vous pouvez recopier intégralement l'élément <sdx:fieldList/> (et ses sous-éléments) de votre configuration SDX-1 dans votre configuration en version 2. En effet, la définition des champs est totalement compatible. SDX-2 vous offre toutefois plus de souplesse quant à la langue des contenus indexés. En version 1, une seule langue par application était possible. En version 2, chaque champ peut avoir sa propre langue, et donc ses propres outils linguistiques. Bien entendu, dans le contexte d'une migration, tous les champs ont la même langue, alors il est conseillé de la définir au niveau de l'élément <sdx:fieldList/>, en y ajoutant un attribut xml:lang avec le code de langue approprié. Par exemple : <sdx:fieldList xml:lang="fr-CA"/> Spécifier la langue des champs implique également le choix d'un analyseur de texte pour l'indexation. En SDX-1, c'est l'élément <sdx:lucene> qui le précisait, la valeur par défaut étant un analyseur de mots pour le français. En SDX-2, le choix de l'analyseur de mots est une conséquence de la spécification de la langue, sauf indication contraire. Si vous voulez spécifier votre propre classe pour un analyseur, vous devez utiliser l'attribut analyzerClass et y mettre le nom complet de la classe Java qui doit nécessairement étendre la classe fr.gouv.culture.sdx.search.lucene.analysis.Analyzer. Vous pouvez aussi spécifier un fichier de configuration pour l'analyseur à l'aide de l'attribut analyzerConf. Ce fichier de configuration peut être spécifié même si vous ne précisez pas de classe particulière. La configuration d'une base de documents SDX-2 doit aussi inclure un élément <sdx:index> qui indique de quelle manière l'indexation se fera. Cet élément contient un élément <sdx:pipeline> qui est la définition d'une séquence de transformations XML. Lors d'une migration, cette configuration sera presque toujours faite ainsi :
<sdx:index>
<sdx:pipeline>
<sdx:transformation id="step1" type="xslt" src="indexation.xsl"/>
</sdx:pipeline>
</sdx:index>
Dans cette configuration, vous devez indiquer dans l'attribut src le chemin vers votre feuille de style d'indexation. TODO : comment ajouter une transformation préalable? |
| Auteur : Martin Sévigny ( AJLSM ) - 2002/10/31 | |
