次の方法で共有

Utilisation des règles de requête, des types de résultats et des modèles d’affichage pour un rapport commercial de recherche personnalisé dans SharePoint 2013

  • [アーティクル]

Article d’origine publié le mardi 24 juillet 2012

(Décharge de responsabilité : la mise en forme des blogs est détestable. Faites plaisir à vos yeux ; téléchargez la pièce jointe qui est une version Word de ce billet.)

Le titre du jour semble bien long, mais il faut dire que nous allons traiter énormément de points importants dans ce billet. SharePoint 2013 offre un grand nombre de fonctionnalités remarquables qui vous permettent d’utiliser et de personnaliser réellement des résultats de recherche comme jamais auparavant. Je ne vais pas tenter de vous donner une présentation complète de chacune d’elles, ni même des détails importants sur les composants que nous allons utiliser dans ce billet, car vous les trouverez parfaitement décrits ailleurs. En revanche, je vous donnerai un ensemble de résultats de recherche de départ et une brève présentation de chacune de ces fonctionnalités, puis j’expliquerai en détails leur utilisation afin de créer un résultat de recherche très cool et personnalisé qui montre comment tous ces éléments fonctionnent ensemble.

 

Commençons, tout d’abord, par voir à quoi ressemblent les résultats de la recherche lorsque j’exécute une requête pour les « rapports commerciaux » dans ma batterie de serveurs (REMARQUE : sachez que nous utilisons ici la version bêta 2, de sorte que la version définitive peut être différente) :

 

 

Ce que vous voyez est l’expérience prête à l’emploi des résultats de la recherche, et cela a fière allure. Toutefois, nous avons ajouté les fonctionnalités suivantes pour vous permettre d’enrichir réellement l’expérience de recherche au niveau de l’utilisateur final dans SharePoint 2013, si bien que nous allons compliquer légèrement le scénario. Notre société est composée de plusieurs départements, et un certain nombre d’entre eux sont responsables de la gestion des ventes au sein de leur département. Chaque département utilise un modèle Excel standard pour rapporter sont activité commerciale au fil du temps. En outre, dans chaque département, une personne est chargée de gérer les relations clients et de rapporter ses informations commerciales.&nbspDonc, comment pouvons-nous utiliser ces fonctionnalités dans SharePoint pour normaliser et faire ressortir les informations importantes concernant le département et ses clients ? Pour résoudre ce problème, nous allons nous appuyer sur une approche à multiples facettes.

 

Type de contenu personnalisé

 

Tout d’abord, nous allons créer un type de contenu personnalisé pour tous ceux qui téléchargent des rapports commerciaux dans SharePoint. Je commence par créer les colonnes de site que j’utiliserai : ce sont les champs que je souhaite pouvoir afficher dans mon rapport commercial. Pour notre scénario, j’ai défini les colonnes de site suivantes :

 

Nom de la colonne de site

Type

Account Manager (Responsable de compte)

Une simple ligne de texte

Direct Reports (Rapports directs)

Nombre

Sales Region (Région commerciale)

Choix : Amérique du Nord, EMEA, Asie

Top Accounts (Principaux comptes)

Une simple ligne de texte

Total Accounts (Nombre total de comptes)

Nombre

 

Ensuite, j’ai créé un type de contenu qui comprend l’ensemble de ces colonnes de site. J’ai créé le type de contenu dans le site concentrateur de publication associé à mon service de métadonnées gérées pour qu’il soit envoyé à tous mes sites d’abonnement dans la batterie de serveurs ce qui, dans mon cas, correspond à tous les sites dans toutes les applications Web.

 

L’étape suivante qui, pour ce qui me concerne, fut manuelle, a consisté à ajouter de type de contenu à la liste des types de contenus disponibles pour la collection de sites de chaque département, dans la bibliothèque de documents dans laquelle ils stockent les rapports commerciaux (entre autres choses). Apparemment, il existe différentes méthodes pour automatiser cette opération, mais pour faire court, je l’ai fait manuellement. Donc, notre première étape est terminée : nous avons un type de contenu personnalisé qui est déployé, et à mesure que les rapports commerciaux sont ajoutés à ces bibliothèques de documents, les Responsables de compte peuvent simplement identifier un rapport commercial lorsqu’ils le téléchargent et renseignent les métadonnées.

 

Propriétés gérées

 

Maintenant que ces rapports commerciaux figurent sur nos sites, nous devons créer des propriétés gérées à partir des colonnes de site personnalisées des rapports commerciaux. Il n’y a rien de bien nouveau ici dans SharePoint 2013 par rapport à SharePoint 2010 en regard de ce scénario : vous devez effectuer une analyse complète pour créer les propriétés analysées, puis créer les propriétés gérées qui sont mappées à ces propriétés analysées, et enfin effectuer une autre analyse complète. J’affirme qu’il n’y a rien de différent dans ce scénario, car nous mettons en œuvre une solution à l’échelle de la batterie de serveurs. Toutefois SharePoint 2013 offre une fonctionnalité fabuleuse qui permet aux administrateurs de collections de sites de marquer leur collection de sites, ou leur site, ou même leur liste pour effectuer une analyse complète. Cette fonctionnalité vous permet d’éviter d’avoir à effectuer une analyse complète de l’entreprise si vous souhaitez le faire à une échelle plus petite, ce qui est véritablement génial. J’essaierai de traiter cela dans un autre billet ; je voulais simplement attirer votre attention sur l’existence de cette fonctionnalité, mais elle n’est pas applicable dans notre cas puisque la portée de notre solution s’étend à l’ensemble de la batterie de serveurs.

 

Règles de requête

 

À ce stade, nous avons des rapports commerciaux qui utilisent un type de contenu personnalisé, et nous avons des propriétés gérées qui sont remplies par les valeurs de métadonnées de ces rapports commerciaux. L’étape suivante consiste à nous assurer que ces éléments attirent l’attention lorsqu’une personne effectue une recherche sur quelque chose qui a des chances d’inclure l’un de ces rapports commerciaux. SharePoint 2013 possède la fonctionnalité parfaite pour cette opération. Il s’agit des Règles de requête. Les règles de requête comportent trois composants principaux :

 

  1. Conditions : les conditions d’une règle de requête déterminent le moment auquel la règle doit se déclencher. Il existe un certain nombre de variantes que vous pouvez faire avec les règles. Nous vous en montrons un petit extrait, mais sachez que leurs possibilités d’utilisation sont IMMENSES et que vous pourrez constater qu’un certain nombre d’entre elles sont livrées prêtes à l’emploi. Autre point intéressant : si vous souhaitez qu’une règle de requête se déclenche sur TOUS LES résultats de la recherche, vous n’indiquez aucune condition. Vous pouvez aussi faire le contraire et indiquer plusieurs conditions. Vous serez rapidement surprise par l’étendue des possibilités. Les conditions que vous pouvez utiliser pour une règle de requête incluent, notamment les suivantes :
    1. une requête qui commence ou se termine par un mot ou une phrase particulière
    2. une requête qui contient un mot d’action (des mots que vous définissez et qui sont généralement des verbes, tels que « télécharger», etc.)
    3. une requête contient un mot qui figure dan un jeu de termes des métadonnées gérées (cette condition permet de faire des trucs GÉNIAUX)
    4. une requête qui est courante dans une autre source de résultats, comme des résultats vidéo, des résultats de documents, etc. : cela peut être n’importe quoi, car c’est vous qui définissez et créez les sources de résultats
    5. le résultat contient un type de résultat sur lequel les utilisateurs cliquent fréquemment, comme des discussions, des feuilles de style Excel, etc.
    6. des règles avancées, dans lesquelles vous pouvez vous éclater avec des expressions régulières, fractionner la requête en termes d’action et en termes de sujet (ce qui reste une fois les termes d’action supprimés), etc.
  2. Actions : les actions sont ce que vous allez faire lorsque les conditions de votre règle de requête seront remplies. Là aussi, vous avez différentes options ; vous pouvez :
    1. Ajouter un résultat promu : cette règle fonctionne de la même manière que les Meilleurs résultats de SharePoint 2010 et les Meilleurs résultats visuels fonctionnaient avec la recherche FAST pour SharePoint 2010. Vous pouvez ajouter un nouveau lien qui s’affichera au début de tous les résultats de recherche. Vous pouvez faire en sorte que le lien s’affiche en tant que lien hypertexte ou en tant qu’image, d’où l’analogie avec le Meilleur résultat visuel.
    2. Ajouter un bloc de résultats : un bloc de résultats est un emplacement dans lequel vous exécutez une requête supplémentaire et retournez et affichez les résultats avec les résultats de la recherche d’origine. Nous parlons de bloc, car les résultats sont affichés tous ensemble, dans un bloc. Vous pouvez faire en sorte que le bloc s’affiche au début de tous les résultats de la recherche ou qu’il soit mélangé avec les autres résultats de la recherche sur la base d’un classement. Attention, cela NE SIGNIFIE PAS qu’il effectue le classement de pertinence entre les deux requêtes. Cela signifie simplement que le bloc dans son ensemble sera classé, en même temps que tous les autres résultats de recherche locaux. Lorsque vous cliquez sur un élément du bloc de résultats, cette action est enregistrée en local et le bloc dans son ensemble devient plus pertinent. Ainsi, si des éléments du bloc reçoivent beaucoup de clics, au fil du temps le bloc commencera à remonter dans les résultats car sa pertinence sera plus importante que des résultats individuels qui ne sont pas sélectionnés aussi souvent. Il existe en réalité des TONNES de possibilités pour configurer un bloc de résultats, mais comme je l’ai déjà mentionné, ce n’est pas l’objet de ce billet.
    3. Modifier des résultats classés en modifiant la requête : cette option fait exactement ce qu’elle dit. Vous pouvez effectivement modifier la requête requise comme bon vous semble. Vous pouvez ajouter des critères, supprimer des termes, utiliser XRANK pour modifier le classement ; cette règle offre un grand nombre d’options.
  3. Publier : la publication est ce qui vous permet de contrôler l’utilisation d’une règle de requête. Par exemple, vous pouvez créer un ensemble de règles que vous souhaitez déclencher le lendemain de la fin des soldes. En revanche, vous ne souhaitez pas qu’elles se déclenchent avant cette date. Par conséquent, vous créez les règles, mais configurez la publication pour qu’elles soient inactives. Ou, vous rendez les règles actives, mais les configurez de sorte qu’elles ne démarrent pas avant une date particulière et qu’elles se terminent à une date ultérieure .

Voilà, c’était un petit récapitulatif sur les règles de requête. Maintenant, comment allons-nous les utiliser ? En fait, il existe une règle de requête qui est livrée prête à l’emploi et qui s’occupe de tout pour nous. Il se trouve que je l’ai désactivée lorsque j’ai pris la capture d’écran ci-dessus pour mieux vous faire comprendre l’impact qu’elle peut avoir. Dans notre cas, nous avons besoin de créer des requêtes pour que les utilisateurs qui souhaitent afficher un rapport commercial tombent directement sur le rapport commercial de notre département. Donc, accédez à votre collection de sites de recherche, Paramètres de site, puis cliquez sur le lien Règles de requête. Dans la liste déroulante modifiable Sélectionner une source, cliquez dessus et sélectionnez Résultats de la recherche de rapports et de données locaux ; la règle de requête appelée Rapports et données s’ouvre. Cliquez dessus et sélectionnez Afficher dans le menu déroulant pour voir comment la règle est construite. Voici comment cela fonctionne :

 

  • Condition : la condition de la règle est que la requête contienne un des mots suivants au début ou à la fin : analyse ; cube ; tableau de bord ; tableaux de bord ; données ; base de données ; rapport ; rapports ; commercial. Notez la présence des deux termes rapports et commercial. Ainsi, si un utilisateur effectue une requête pour « rapport commercial », cette règle de requête s’exécute. C’est parfait. Si une personne recherche « rapport commercial », il faut à tout prix qu’elle voit les rapports de vente de notre département. Cette règle définit la correspondance sur les termes d’action et attribue tout le reste aux termes de sujet. Dans notre cas de figure, elle attribue « rapports » au terme d’action, et « commercial » au terme de sujet.
  • Action : l’action correspondant à cette règle consiste simplement à exécuter une autre requête basée UNIQUEMENT sur les termes de sujet. Ainsi, sur la base de la condition ci-dessus elle exécute une requête séparée uniquement pour « commercial ». Cela permet d’ajouter un bloc qui est toujours renvoyé au début de tous les autres résultats. MAIS, cela permet UNIQUEMENT de rechercher le terme commercial dans la source Résultats de la recherche de rapports et de données locaux. C’est également une source de résultats qui est livrée prête à l’emploi, et qui, effectivement retourne uniquement des documents Excel (dont l’extension de fichier se termine par .XLSX, XLS, etc.). Parfait, c’est donc une requête qui permet d’exécuter un requête pour le terme « commercial » uniquement par rapport à des documents Excel.
  • Publication : la règle est active sans restriction de date de début ni de fin, de sorte qu’elle se déclenche en permanence.

 

J’ai réactivé cette règle de requête. Voici comment les résultats s’affichent maintenant lorsque j’effectue une requête pour des rapports commerciaux :

 

 

Super, la règle de requête a fait son boulot et nous avons obtenu nos documents sur la base du type de contenu de rapport commercial personnalisé qui s’affiche au début des résultats. C’est génial ! En revanche, nous n’avons toujours pas affiché les métadonnées concernant les documents, or ce sont elles qui permettent de regrouper le tout.

 

Modèles d’affichage

 

Dans SharePoint 2010, si vous souhaitiez générer un élément de manière différente, il fallait aller modifier une portion énorme de XSLT dans le composant WebPart principal des résultats, ce qui était extrêmement difficile. Il fallait être un crac du XSLT pour tenter de retrouver dans cet énorme document l’emplacement dans lequel insérer votre code personnalisé. Globalement, c’était un véritable cauchemar.

 

Dans SharePoint 2013, nous disposons de modèles d’affichage, ce qui représente une amélioration considérable. Vous n’avez plus besoin de vous embarrasser du XSLT, vous pouvez désormais créer votre propre code d’affichage personnalisé en pur HTML : hourra ! En fait, pour ce billet j’ai fait appel à Dreamweaver CS6 d’Adobe pour créer le « code » de mon modèle d’affichage personnalisé. Voyons, maintenant comment fonctionnent les modèles d’affichage. 

 

Avec un modèle d’affichage, vous devez conserver le suivi d’un certain nombre d’éléments différents :

 

  1. Propriétés gérées : vous devez lui indiquer quelles propriétés gérées il doit récupérer au moment de la requête. Vous pouvez ensuite utiliser ces propriétés dans votre HTML, à l’aide d’une méthode décrite plus loin.
  2. Fichiers JS et CSS externes : si vous avez des fichiers JavaScript ou CSS que vous voulez utiliser avec votre modèle d’affichage, vous pouvez les externaliser et les ajouter à votre modèle d’affichage.
  3. Code Inline JS : vous pouvez aussi utiliser du code inline JS dans votre modèle d’affichage. N’oubliez pas de le placer en dessous du premier <div> dans votre modèle d’affichage (nous y reviendrons, un peu plus loin).
  4. HTML : vous créez le HTML pour votre modèle d’affichage qui génèrera les résultats.

 

Pour notre modèle d’affichage, nous allons rassembler les attributs du type de contenu de rapport commercial personnalisé que nous avons créé de sorte qu’ils s’affichent de la façon suivante dans les résultats de la recherche :

 

 

Tout d’abord, il est clair que lorsque vous créerez un modèle d’affichage, vous souhaiterez presque toujours utiliser un modèle existant. Accédez à la collection de sites de votre centre de recherche, Paramètres de site, puis cliquez sur Pages maîtres et sur le lien de mises en page. Dans la bibliothèque, cliquez sur le dossier Modèles d’affichage, puis sur le dossier Recherche. Vous y trouverez tous les modèles d’affichage fournis prêts à l’emploi. Vous verrez un certain nombre de fichiers qui portent le même nom, mais avec l’extension .html ou .js. Ceux qui vous concernent sont les fichiers .html ; les fichiers .js sont générés automatiquement lorsque vous téléchargez les fichiers .html correspondants. Dans notre cas, étant donné que le modèle d’affichage est destiné à des fichiers Excel, j’ai choisi le fichier Item_Excel.htm. J’en ai téléchargé une copie en local, que j’ai nommée SalesReport.html et que j’ai ouvert dans Dreamweaver.

 

Ensuite, j’ai ajouté mes propriétés gérées. Il existe une balise, appelée mso:ManagedPropertyMapping, dans laquelle vous placez les propriétés gérées dont votre modèle d’affichage a besoin. J’ai donc ajouté les miennes à la fin de la liste, dans le même format que les autres propriétés gérées, ce qui donne ceci :

 

<mso:ManagedPropertyMapping msdt:dt="string">'Title':'Title', 'Author':'Author', 'Size':'Size', 'Path':'Path', 'Description':'Description', 'LastModifiedTime':'LastModifiedTime', 'CollapsingStatus':'CollapsingStatus', 'DocId':'DocId', 'HitHighlightedSummary':'HitHighlightedSummary', 'HitHighlightedProperties':'HitHighlightedProperties', 'FileExtension':'FileExtension', 'ViewsLifeTime':'ViewsLifeTime', 'ParentLink':'ParentLink', 'ViewsRecent':'ViewsRecent', 'FileType':'FileType', 'IsContainer':'IsContainer', 'ServerRedirectedURL':'ServerRedirectedURL', 'ServerRedirectedEmbedURL':'ServerRedirectedEmbedURL', 'ServerRedirectedPreviewURL':'ServerRedirectedPreviewURL', 'AccountManager':'AccountManager', 'SalesRegion':'SalesRegion', 'TotalAccounts':'TotalAccounts', 'TopAccounts':'TopAccounts', 'DirectReports':'DirectReports', 'ContentType':'ContentType'</mso:ManagedPropertyMapping>

 

Comme vous pouvez le constater, j’ai ajouté AccountManager, SalesRegion, etc., toutes les propriétés que j’avais créées pour mon type de contenu personnalisé. Ensuite, j’ai défilé jusqu’à la ligne suivante :

 

<div id="_#= $htmlEncode(itemId) =#_" name="Item" data-displaytemplate="ExcelItem" class="ms-srch-item" onmouseover="_#= ctx.CurrentItem.csr_ShowHoverPanelCallback =#_" onmouseout="_#= ctx.CurrentItem.csr_HideHoverPanelCallback =#_">

                                                                _#=ctx.RenderBody(ctx)=#_                                                     

                <div id="_#= $htmlEncode(hoverId) =#_" class="ms-srch-hover-outerContainer"></div>

</div>

 

Puis, j’ai supprimé tout ce qui se trouvait entre les balises DIV extérieures (surlignées en rouge ci-dessus). Maintenant, il ne me reste plus qu’à écrire mon HTML. Toutefois, avant de commencer, permettez-moi d’attirer votre attentions sur les trois points suivants :

 

  1. Il vous semblera certainement plus simple de conserver une balise <style> dans la section <head> de votre modèle d’affichage. Or, pour des raisons que je ne développerai pas maintenant, ces balises style seront ignorées lors de la génération de votre modèle d’affichage. C’est pourquoi, il vous faudra les copier pour les placer dans un fichier CSS séparé. Lors de la création de votre HTML, vous pourrez alors les utiliser et les modifier de sorte à obtenir l’aspect souhaité dans votre modèle d’affichage.
  2. Comme je l’ai indiqué précédemment, vous pouvez ajouter du code inline JavaScript, dans la mesure où vous l’insérez à l’emplacement approprié. Cela signifie que vous devez impérativement le placer après la première balise DIV de votre modèle d’affichage. Vous devez également l’entourer d’une balise de début et d’une balise de fin, comme ceci : <!--#_ et _#-->. Je vous reparlerai des balises personnalisées, mais sachez pour le moment que si votre JavaScript n’est pas placé entre ces balises, il ne s’exécutera pas. Ce qui est génial, par contre, c’est que vous pouvez utiliser les variables que vous définissez dans votre code inline JavaScript lorsque vous créez le HTML qui sera généré. Je vous ’expliquerai cela plus en détails, un peu plus loin.
  3. Pour émettre une propriété gérée ou une variable à partir d’un code inline JavaScript que vous avez créé, vous devez l’entourer d’une balise de début et d’une balise de fin, comme ceci : _#= et =#_. Toutes les propriétés gérées sont disponibles dans un objet appelé ctx.CurrentItem. Par exemple, pour émettre la propriété gérée AccountManager, j’ajoute la balise suivante : _#= ctx.CurrentItem.AccountManager =#_. Si mon JavaScript ressemblait à ceci : var foo = “The current Account Manager is “ + ctx.CurrentItem.AccountManager + “.”;, pour émettre « foo », il me faudrait ajouter la balise suivante : _#= foo =#_. Comme vous le voyez, vous disposez d’une totale flexibilité pour ajouter ou traiter les données à utiliser pour votre modèle d’affichage.

 

Bien, maintenant que vous comprenez les mécanismes de création du HTML, je vais vous montrer comment j’ai crée le modèle d’affichage que je vous ai montré précédemment ; dans la balise head, j’ai ajouté les attributs style suivants :

 

<style>

.ReportDiv

{

                float:left;

}

.ReportText

{

                font-family: Verdana, Geneva, sans-serif;

                font-size: 12px;

}

.ReportHeading

{

                font-weight: bold;

}

.LogoImg

{

                margin-top: 15px;

                width: 118px;

                height: 101px;

}

.MasterDiv

{

                float:left;

                height: 215px;

                width: 342px;

                background-repeat: no-repeat;

                background-image: url(https://sps/sites/search/PublishingImages/SalesReportBackground.PNG);

                padding: 15px;

}

.DetailsContainer

{

                background-color:#CCC;

}

</style>

 

Le point le plus important à noter ici, c’est que l’image que j’ai utilisée pour l’arrière-plan des informations détaillées du responsable de compte est une image que j’avais déjà téléchargée sur mon site ; tout le reste semble être assez évident. Là encore, du fait que ma balise style figure dans ma section <head>, je peux voir exactement comment la disposition se présente en même temps que je la crée dans Dreamweaver.

Maintenant, voyons le code HTML qui sert à créer le modèle d’affichage :

            <div>

                <div class="ReportDiv">

                                <img class="LogoImg" src="https://sps/sites/search/PublishingImages/SalesReportLogo.PNG" />

                </div>

                <div class="MasterDiv">

                   

                    <!-- Title and link to item -->

                    <a href="_#= ctx.CurrentItem.Path =#_" class="ReportText">_#= ctx.CurrentItem.Title =#_</a>

                    <br/><br/>

 

                    <!-- Account Manager -->

                    <span class="ReportHeading ReportText">

                      Account Manager:

                    </span>

                    <span class="ReportText">

                      _#= ctx.CurrentItem.AccountManager =#_

                    </span><br/>

                   

                    <!-- Sales Region -->

                    <span class="ReportHeading ReportText">

                      Sales Region:

                    </span>

                    <span class="ReportText">

                      _#= ctx.CurrentItem.SalesRegion =#_

                    </span><br/>

                   

                    <!-- Total Accounts -->

                    <span class="ReportHeading ReportText">

                      Total Accounts:

                    </span>

                    <span class="ReportText">

                      _#= ctx.CurrentItem.TotalAccounts =#_

                    </span><br/>

                   

                    <!-- Top Accounts -->

                    <span class="ReportHeading ReportText">

                      Top Accounts:

                    </span>

                    <span class="ReportText">

                      _#= ctx.CurrentItem.TopAccounts =#_

                    </span><br/>

                   

                    <!-- Direct Reports -->

                    <span class="ReportHeading ReportText">

                      Direct Reports:

                    </span>

                    <span class="ReportText">

                      _#= ctx.CurrentItem.DirectReports =#_

                    </span><br/>

                   

                    <!-- Hit Highlighted Text -->

                    <br/>

                    <span class="ReportHeading ReportText">

                                Details:

                    </span>

                    <br/>

                    <span class="DetailsContainer ReportText">

                                _#= Srch.U.processHHXML(ctx.CurrentItem.HitHighlightedSummary) =#_

                    </span>

                </div>

            </div>        

 

Je vais vous parler des données de ce contenu, et non des fonctionnalités de mise en forme. Vous pouvez constater que partout j’ai inséré les propriétés gérées en utilisant les balises _#= et =#_. Cette opération consiste purement et simplement à remplacer un jeton. Je peux donc même l’utiliser directement dans mon attribut <a> href ci-dessus (ce qui m’évite d’avoir à faire appel au langage XSLT qui est beaucoup plus compliqué). Tous les autres champs sont insérés dans les balises DIV ou SPAN appropriées à la mise en forme souhaitée. La seule exception concerne la propriété HitHighlightedSummary qui utilise un composant de traitement intégré fourni avec la recherche. Je ne possède pas actuellement la liste complète des composants et des méthodes, avec leurs fonctions, mais si j’ai ajouté cette propriété, c’est uniquement parce que si vous ne l’utilisez pas votre récapitulatif ne figurera pas dans les résultats de la recherche. N’oubliez donc pas de le faire également.

 

Maintenant que tout fonctionne correctement, je dois encore effectuer une autre opération sur mon balisage. Je copie tout ce qui se trouve entre mes balises <style> pour le placer dans un nouveau document CSS appelé SalesReport.css. Dans ma galerie de pages maîtres, dans le dossier /Display Templates/Search, j’ai créé un autre dossier appelé styles. J’ai téléchargé mon fichier SalesReport.css dans ce répertoire. Pour l’utiliser maintenant dans mon modèle d’affichage, je dois ajouter une nouvelle balise script. Elle doit figurer sous la balise <body> et au-dessus de la première balise <div>. Pour que le modèle d’affichage puisse utiliser le fichier CSS, je fais appel à la fonction JavaScript SharePoint appelée $includeCSS. Voici donc à quoi mon balisage de début ressemble :

 

<body>

<script>

                                $includeCSS(this.url, "./styles/SalesReport.css");

</script>

 

<div id="Item_SalesReport">

 

Le code est terminé. Mais, comment notre modèle d’affichage personnalisé sera-t-il utilisé ?

 

Types de résultats

Les types de résultats permettent de faire appeler des modèles d’affichage sur la base d’un ensemble de règles. Les règles sont très simples à utiliser. Vous pouvez faire en sorte qu’elles se déclenchent pour un type de contenu prédéfini, tel que message électronique, document Word ou PDF, Wiki SharePoint, etc. Vous pouvez aussi faire en sorte qu’elles ne soient utilisées que lorsque la requête concerne une source de résultats spécifique. Enfin, vous pouvez également choisir une propriété gérée comme critère de la règle, avec des comparaisons communes. Par exemple, vous pouvez faire en sorte qu’une règle de type de résultat se déclenche lorsque le champ AccountManager contient le terme « Vice-Président » si vous souhaitez qu’un autre type d’affichage soit utilisé pour vos vice-présidents. Dans notre cas, nous voulons que notre type de résultat se déclenche uniquement lorsque le type de contenu est égal à « Rapport commercial ».&nbspNous ajoutons donc pour notre type de résultat une condition qui indique lorsque ContentType est égal à « Sales Report (Rapport commercial) ».

 

 

Ainsi, nous pourrions même ajouter plusieurs valeurs de correspondance. Nous pouvons également ajouter plusieurs propriétés, that get AND’d together. Pour ce scénario, nous n’avons besoin que de ContentType. Après avoir défini les conditions, nous pouvons configurer l’action de la règle. Pour un type de résultat, l’action consiste uniquement en une liste déroulante dans laquelle figurent tous les modèles d’affichage disponibles. Il me suffit alors de sélectionner dans la liste mon modèle d’affichage Rapport commercial et de cliquer sur le bouton Enregistrer pour créer mon type de résultat. Là encore, si vous ne savez pas encore très bien comment créer des types de résultats, consultez ceux qui sont fournis prêts à l’emploi dans SharePoint. Ils vous donneront de bonnes idées pour en créer de nouveaux.

 

Conclusion

Tous les éléments nécessaires sont désormais en place : un type de contenu personnalisé qui capture les métadonnées souhaitées, des propriétés gérées pour l’extraire et le placer dans l’index, une règle de requête pour assurer que nos rapports commerciaux s’afficheront au début de la liste lorsqu’un utilisateur effectuera une recherche sur « sales report (rapport commercial) », un modèle d’affichage personnalisé qui présente les métadonnées que nous avons capturées dans un format unique et utile qui ressemble tout à fait un résultat de recherche standard et un type de résultat qui garantit que notre modèle d’affichage sera utilisé lorsque notre type de contenu personnalisé sera retourné dans les résultats de la recherche. Voici à quoi ressemble le résultat final :

 

 

Ainsi se termine cette introduction à quelques unes des fonctionnalités géniales de SharePoint 2013 qui permettent de présenter des résultats de recherche. J’espère que vous avez compris à quel point celles-ci sont puissantes, et que vous pourrez trouver de nombreuses façons utiles et intéressantes de les utiliser.

Ce billet de blog a été traduit de l’anglais. La version originale est disponible à la page Using Query Rules, Result Types and Display Templates for a Custom Search Sales Report in SharePoint 2013