Doc produitsMenu

Définition d'un fichier de correspondances Sitecore pour l'ancien connecteur

Les métadonnées de Sitecore peuvent être organisées de diverses façons. Selon la façon dont les métadonnées sont organisées, il est peut-être difficile pour le connecteur Sitecore de récupérer tous les champs qui composent un élément Sitecore.

Exemple : Un seul élément de Sitecore peut être composé de plusieurs champs ainsi que de plusieurs références à d'autres éléments de Sitecore. Ces éléments référencés peuvent également avoir plusieurs champs et références, etc.

Cette rubrique explique comment vous pouvez écrire un fichier de correspondances XML qui peut être utilisé afin d'associer des champs de métadonnées à des champs CES (Coveo Enterprise Search). Vous pouvez également utiliser ce fichier afin de modifier la façon dont les valeurs de champs Sitecore référencés sont résolus.

Exemple : Vous pouvez changer l'URL cliquable d'éléments indexés à l'aide d'un fichier de correspondances si l'option de source Index si mise en page absente est activée (voir Index si mise en page absente (Index if no Layout)).

Le code suivant présente une structure XML de base d'un fichier de correspondances.

<?xml version="1.0" encoding="utf-8" ?>
<Sitecore>
  <CommonMappings>
    <Fields>
      <FieldName>mapping value</FieldName>
    </Fields>
  </CommonMappings>
  <Mapping template="{00000000-0000-0000-0000-000000000000}">
    <Fields>
      <FieldName>mapping value</FieldName>
    </Fields>
  </Mapping>
  <Mapping item="{00000000-0000-0000-0000-000000000000}">
    <Fields>
      <FieldName>mapping value</FieldName>
    </Fields>
  </Mapping>
  <Ignore template="{00000000-0000-0000-0000-000000000000}">
  <Ignore item="{00000000-0000-0000-0000-000000000000}">

<CommonMappings>

Définit les correspondances de champ qui s'appliquent à tous les éléments de Sitecore.

<Mapping>

Définit des correspondances de champs qui s'appliquent à tous les éléments de Sitecore qui utilisent les modèles spécifiés dans l'attribut de modèle. L'association de champs peut également s'appliquer directement sur des éléments en spécifiant l'attribut d'élément. Les modèles et les éléments sont identifiés par leur identificateur de Sitecore (GUID) et séparés par une barre verticale (|). Si les deux attributs sont définis, seul l'attribut de modèle est pris en compte. Une meilleure approche consiste à définir des associations sur des modèles plutôt que sur des éléments.

<Ignore>

Spécifie les modèles et les éléments qui devraient être ignorés par le connecteur. Les modèles et les éléments sont identifiés par leur identificateur de Sitecore (GUID). Chaque entrée n'accepte qu'un modèle ou élément. Si les deux attributs sont définis, seul l'attribut de modèle est pris en compte.

<FieldName>

Définit le champ ciblé par l'association. Le nom de l'entrée correspond au nom du système ou champ personnalisé Coveo qui est défini dans le groupe de champs utilisé par la source.

mapping value

Cette valeur est l'association elle-même. Elle est composée de balises de texte libre et de métadonnées. Le connecteur prend en charge différentes syntaxes de balise de métadonnées.

  • %[<metadata>]

  • %{<metadata>:<mapping value>}

  • @[<fully_qualified_class_name>].

Les syntaxes de balise de métadonnées sont illustrées dans les exemples suivants.

Exemple : L'association suivante dit au connecteur de définir le champ Title d'un document avec la valeur des métadonnées _CESSCDisplayName. Ceci s'applique à tous les documents de Sitecore. Il est possible de naviguer dans la hiérarchie de l'élément à l'aide des champs de métadonnées référencés.
<?xml version="1.0" encoding="utf-8" ?>
<Sitecore>
  <CommonMappings>
    <Fields>
      <Title>%[_CESSCDisplayName]</Title>
      <Body>%[Description]</Body>
    </Fields>
  </CommonMappings>
</Sitecore>  
Exemple : Un élément de Sitecore est basé sur le modèle Book. Ce modèle définit un champ Contributor, qui est une référence à un élément Person dans un autre endroit de l'arbre de contenu. L'élément Person contient plusieurs champs, dont les champs Firstname et Lastname.

Voici les différentes possibilités :

  • Le fichier de correspondances est laissé tel quel. Les métadonnées Contributor sont donc ignorées. Ceci est le comportement de connecteur par défaut.

  • Le paramètre de source Indexer les métadonnées des document est sélectionné. Donc, les métadonnées Contributor sont indexées et renferment une référence à l'élément Person (GUID).

  • Le fichier de correspondances est mis à jour de façon à ce que les champs Firstname et Lastname soient concaténés afin de former le nom complet du contributeur, qui est alors placé dans le champ personnalisé Contributor.

    <?xml version="1.0" encoding="utf-8" ?>
    <Sitecore>
      <Mapping template="{AF0AD32B-8188-45E0-B354-5226F41D801B}"> <!--BookTemplate-->
        <Fields>
          <Contributor>%[Contributor.Lastname], %[Contributor.Firstname]</Contributor>
        </Fields>
      </Mapping>
    </Sitecore>  

    Si le champ Contributor est une référence à plusieurs valeurs (c.-à-d. le livre peut avoir plus d'un contributeur), l'utilisateur peut dire au connecteur de concaténer les valeurs en utilisant la syntaxe d'association suivante %{<metadata>:<mapping value>}:

    <?xml version="1.0" encoding="utf-8" ?>
    <Sitecore>
      <Mapping template="{AF0AD32B-8188-45E0-B354-5226F41D801B}"> <!--BookTemplate-->
        <Fields>
          <Contributors>%{Contributor:%[Lastname], %[Firstname]}</Contributors>
        </Fields>
      </Mapping>
    </Sitecore>

Les références à plusieurs valeurs peuvent être organisées par modèle.

Exemple : Dans le site de démonstration Nicam (site Web de démonstration par défaut, installé avec Sitecore), une caméra contient un champ intitulé Accessories. Ces accessoires sont générés à partir de modèles différents : Lenses, Flash, ou Other Accessories.

Pour organiser les références de valeurs par modèle, utilisez la syntaxe suivante %{<metadata|template ID1|template ID2|…>:<mapping value>}. Les identificateurs de modèles doivent être utilisés sans les crochets courbes {, } :

<?xml version="1.0" encoding="utf-8" ?>
<Sitecore>
 <Mapping template="{B072B7C7-6F3F-4316-B8D7-010629AEBEF1}"> <!--SLR-->
  <Fields>
   <Accessories>%[Accessories.Title]</Accessories>
   <Lenses>%{Accessories|8FAC8E12-7459-43F8-97E8-1BC6840B9226:%[Title],%[Focal length]}</Lenses >
   <Flash>%{Accessories|95681CF6-3635-49EC-A09A-CC548FA62389:%[Title],%[Guide number]}</Flash>
   <Misc>%{Accessories|A93FA2C4-3AE4-45C2-8C3F-EFA7E129537E:%[Title]}</Misc>
  </Fields>
 </Mapping>
</Sitecore>  

Finalement, l'association doit être gérée programmatiquement à l'aide de la syntaxe @[<fully_qualified_class_name>]. Le connecteur peut alors utiliser une classe personnalisée afin de résoudre une valeur de champ si aucune des solutions d'associations standards ne correspond à vos besoins. Bien que ceci peut être une approche plus lente (le connecteur n'a aucun contrôle sur l'exécution de code à l'intérieur de la classe), c'est par contre une façon très puissante de résoudre des associations si des règles complexes s'appliquent.

Exemple : Un élément de Sitecore contient les champs suivants : long description, short description, title et name. Seul name est nécessaire dans Sitecore, mais vous souhaitez utiliser long description ainsi que short description si l'un d'eux est présent. Sinon, vous utiliserez le titre avant le nom.
<?xml version="1.0" encoding="utf-8" ?>
<Sitecore>
  <Mapping template="{AF0AD32B-8188-45E0-B354-5226F41D801B}"> 
    <Fields>
      <Description>@[MyNamespace.MyDescResolver, MyAssembly]</Description >
    </Fields>
  </Mapping>
</Sitecore>  

Voici le code de la classe que contient MyAssembly.dll et utilisé afin de résoudre le champ de description :

using System;
using System.Collections;
using System.Collections.Generic;
using Coveo.CES.CustomCrawlers.Sitecore.ContentService;
using Coveo.CES.CustomCrawlers.Sitecore.Interfaces;

namespace MyNamespace {

public class MyDescResolver: ISitecoreMappingResolver
{
    [CLSCompliant(false)]
    public string ResolveMapping(ContentItemMeta p_Meta, 
                                 Hashtable p_ProcessedMeta,
                                 List<string> p_MediaReferences)
    {
        string desc = null;
        string shortdesc = null;
        string title = null;

        foreach (ContentItemField field in p_Meta.Fields) {
            if (field.Name == "long description") {
                desc = field.Value.StringValue;
	            } else if (field.Name == "short description") {
                shortdesc = field.Value.StringValue;
	            } else if (field.Name == "title") {
                title = field.Value.StringValue;
	            }
        }

        return desc ?? shortdesc ?? title ?? p_ProcessedMeta["_CESSCName"].ToString();
    }
}
} //namespace  

La classe doit implémenter l'interface ISitecoreMappingResolver. Votre assemblage doit faire référence à Coveo.CES.CustomCrawlers.Sitecore.dll, après quoi vous n'avez qu'à implémenter la méthode ResolveMapping. Cette méthode contient les paramètres suivants :

  • ContentItemMeta : Les métadonnées Sitecore de l'élément.

  • Hashtable : Les métadonnées de système déjà traitées (voir À propos des métadonnées de Sitecore avec l'ancien connecteur).

  • List<string> : La liste d'éléments média référencés par les éléments. Cette liste peut être modifiée si nécessaire.

Note : Les valeurs d'associations sont sensibles à la casse. Si le champ Sitecore s'appelle Short Description, la syntaxe suivante ne fonctionne pas :
<?xml version="1.0" encoding="utf-8" ?>
<Sitecore>
  <Mapping template="{AF0AD32B-8188-45E0-B354-5226F41D801B}"> 
    <Fields>
      <ShortDesc>%[short description]</ShortDesc > <!—No field will match-->
    </Fields>
  </Mapping>
</Sitecore>