Télécharger
    Installer
    Présentation
    Configuration
    Indexation
      +Pipeline <-
       Original et usage
       Paramètres
       Format de sortie
       Champs SDX
       Documents attachés
       Fragmentation
       Thésaurus
    Recherche
    OAI
    Javadoc
    Référence API-XSP
    Migration
    Schemas
    Performances


SDX

Pipeline d'indexation

Les documents XML passent à travers une ou plusieurs transformations avant d'être indexés. Ces transformations sont regroupées sous le concept de pipeline. L'objectif de ce pipeline est de fournir à SDX l'information dont il a besoin pour gérer correctement l'indexation du document, de ses fragments et de ses documents attachés.

Le pipeline d'indexation doit être configuré (ou déclaré) afin de pouvoir être utilisé. Cette configuration peut se faire à deux endroits : dans le fichier de configuration de l'application (conf/application.xconf) ou dynamiquement, par exemple dans une page XSP ou via l'API Java. La configuration du pipeline dans le application.xconf et dans une page XSP fait appel à la même structure XML.

Structure XML pour configurer un pipeline

La configuration d'un pipeline dans un application.xconf ou dans une page XSP se fait à l'aide d'une structure XML. Cette structure est formellement définie par un schéma qui définit un élément sdx:pipeline qui peut contenir une ou plusieurs transformations exprimées par un élément sdx:transformation. Le schéma constitue la référence ultime, mais nous allons ici donner un exemple complet pour bien illustrer le concept.

Exemple 1. Déclaration d'un pipeline d'indexation

  <sdx:pipeline>
    <sdx:transformation id="step1" keep="true" type="XSLT" src="index.xsl"/>
    <sdx:transformation id="step2" type="com.ajlsm.sdx.pipeline.Trans" log="true" help="1"/>
  </sdx:pipeline>

Dans cet exemple, la première transformation est de type XSLT et la XSLT se situe dans le fichier index.xsl (dont l'emplacement exact est déterminé par l'URL de base du fichier qui contient la déclaration, par exemple le fichier application.xconf). L'attribut id, obligatoire, contient l'identifiant de cette étape. L'attribut keep indique que le résultat de cette transformation doit être conservé par SDX et réutilisé lors de l'affichage du document (voir la partie sur les documents originaux et les documents d'usage) ; il est bien entendu optionnel.

La seconde transformation est déterminée par la classe com.ajlsm.sdx.pipeline.Trans, dont la seule contrainte est qu'elle implémente l'interface fr.gouv.culture.sdx.pipeline.Transformation et, évidemment, qu'elle soit accessible à Java (donc dans le CLASSPATH) lorsque SDX tourne. Nous avons volontairement ajouté les attributs log et help ici pour illustrer le fait que le développeur est invité à utiliser ce mécanisme pour passer des informations à la classe, car celle-ci, lors de sa configuration, recevra l'ensemble de l'élément XML sdx:transformation qui le déclare (y compris les attributs non pris en charge par SDX) mais également les sous-éléments.

Cas particulier de la configuration dans une XSP

Lorsque la configuration d'un pipeline s'effectue dans une page dynamique XSP, on peut tirer parti de cet aspect pour gérer de véritables pipelines dynamiques, en particulier en passant des valeurs dynamiques pour différents paramètres. Les mécanismes habituels de l'API SDX sont utilisés pour passer ces paramètres. Voyons un exemple le plus complet possible :

Exemple 2. Déclaration dynamique d'un pipeline d'indexation

  <xsp:logic>
    String myFormat = "xml";
  </xsp:logic>
  <sdx:pipeline>
    <sdx:parameter name="type" valueParam="t"/>
    <sdx:parameter name="format" valueString="myFormat"/>
    <sdx:parameter name="pref" valueSession="myPref"/>
    <sdx:parameter name="categorie" value="Architecture"/>
    <sdx:transformation id="step1" type="XSLT" srcParam="s"/>
  </sdx:pipeline>

Dans cet exemple, quatre paramètres dynamiques sont passés au pipeline ; la source de la transformation XSLT est également passée de manière dynamique. Ce qu'il faut noter dans cet exemple :

  1. L'élément sdx:pipeline peut avoir des sous-éléments sdx:parameter ; ces derniers doivent obligatoirement se trouver avant les sous-éléments sdx:transformation (voir le schéma de l'API SDX pour une définition plus précise) ;

  2. Le comportement des éléments sdx:parameter est exactement le même que dans d'autres circonstances, c'est-à-dire qu'on peut définir les paramètres en utilisant un paramètre d'URL (valueParam), une variable Java préalablement déclarée et initialisée (valueString), une information stockée en objet de session (valueSession) ou une chaîne de caractère codée en dur (value) ;

  3. L'attribut src de l'élément sdx:transformation fait l'objet d'un traitement particulier afin de permettre de spécifier la source d'une transformation XSLT à l'aide des mécanismes habituels des paramètres dans l'API SDX. Dans l'exemple, on suppose que la source est passée par le paramètre d'URL s, mais il aurait également pu être codé en dur, provenir d'une variable Java ou d'un objet de session.

Ce mécanisme de configuration dynamique des pipelines est très puissant. Ainsi, au moment même de l'indexation, vous avez le choix entre :

  1. Utiliser le pipeline par défaut déclaré dans le fichier application.xconf, en n'utilisant pas d'élément sdx:pipeline ;

  2. Passer des paramètres dynamiques, pour contextualiser légèrement votre pipeline d'indexation ;

  3. Choisir dynamiquement la source d'une transformation XSLT lorsque le contexte exige des changements importants et où une même XSLT ne peut pas tenir compte de tous les changements possibles.

En terminant, il est bon de rappeler que les pipelines dynamiques peuvent être utilisés à l'intérieur des éléments qui déclenchent l'indexation de documents dans SDX, soit les éléments sdx:uploadDocument ou sdx:uploadDocuments.



Auteur : Martin Sévigny ( AJLSM ) - 2003-06-03