[SPC14] 6 proven steps to get the best out of search in SP2013

Mail de Fabien

Session par Paul Olenik, consultant, AvePoint

// résumé

Session power user, la salle est pleine, le sujet intéresse.
Manque de chance pour moi, c’est ce que l’on connaît déjà tous sur le paramétrage de la recherche, je pensais qu’on allait voir plus de cas concrets et en situation.

// l’expérience de recherche OOTB

Il nous rappelle l’origine de sharepoint search 2013 : fast + sharepoint search
Il souligne aussi que la recherche est maintenant au cœur de SP : cswp, cross site publishing, analytics,…
Une démo de la recherche OOTB pour ceux qui ne la connaissent pas : les verticals de recherche, le panneau de raffinement, le call out avec OWA et le « take a look inside », les suggestions, les résults blocs.

Il nous montre maintenant un call out custom avec des métadonnées custom pour un content type.

Maintenant la recherche de personne. Dommage qu’il nous montre encore le profil SP avec le newsfeed SP, et yammer?

// les outils de paramétrage

Les 4 outils pour customiser la recherche :
• Result sources : scope ou fédération
• Result types : discussion, web site, Word document, items du CRM, documents de Fabien datant de moins de 30j,…
• Display templates: comment on affiche les résulte types, en html/js
• Query rule: une action en fonction de la requete : exemple : redirection vers le support en cas de saisie « support », détection d’un numéro de commande et redirection vers la page de tracking, best bets, etc…

Démos de tout ça, comme dans nos cafés SharePoint, aucune nouveauté.

// les verticals

Il nous fait une démo. Il ajoute un vertical: ajout d’une page de résultat, modification de la webpart search résulte, ajout du lien vers la page. Facile.

// la content search web part

Une énième présentation et démo de la cswp. Je vous l’épargne, voir les CR précédents…

Des variables utiles dans le query builder : {user.name}, {user.email}, {today+30}

// best practices

La qualité des la recherche dépend directement de la qualité de la structuration de l’information et du tagging des documents.

Fabien

SPC14] SPC414 // Search content enrichment and extensibility in SharePoint 2013

Mail de Christian

Mercredi 05/03/2014 à 13h45

Speaker
Brent Groom – Senior Premier Field Engineer @ Microsoft Consulting Services Sreedhar Mallangi – Senior Consultant @ Microsoft Consulting Services

Résumé
C’est une session on-prem sur la façon dont on peut étendre les sources de contenus d’un moteur de recherche SharePoint 2013.
On utilise Search Indexing Toolkit (SIT) qui facilite la création de connecteurs de contenus.
On peut utiliser Content Enrichment Web Service (CEWS Pipeline Toolkit) aussi pour enrichir le contenu indexé par des informations supplémentaires.
Une session très intéressante et qui montre surtout comment le moteur de recherche SharePoint 2013 peut être étendu et configuré avec notamment un ajout de code qui permet d’ajouter du contenu spécifique à nos résultats, tout en gardant une expérience utilisateur poussée où on vient enrichir du contenu indexé pour par exemple enrichir le panneau de raffinement de métadonnées qui ne sont pas automatiquement indexées.

// Agenda
Identifier les extension de contenu
Connecteurs custom
Enrichissement du contenu
Toolkits de la communauté

// Architecture overview
Il décrit l’architecture du service de recherche et notamment le composant de crawl qui prend en input plusieurs connecteurs possibles.
On peut sur SharePoint 2013 faire du crawl continu.

// Content ingestion
Pourquoi est-ce important. On va voir comment fonctionne l’input de contenu, la gestion de contenus crawlante et comment on peut avoir des connecteurs spécifiques propres à chaque contenu.
FAST ESP (Enterprise Search Platforms), permettait d’avoir des APIs d’extraction de contenu.
Maintenant sur SharePoint 2013, on a des connecteurs, des handlers (pour file share, sharepoint, profils), et des connecteurs BCS.
Business Connectivity Services permet pour rappel de connecter des données externes vers SharePoint. BCS peut être utilisé comme source de contenu pour la recherche SharePoint.
On peut faire du BCS sans code avec OData ou SQL.
Ou BCS avec du code avec du WCF ou de l’assembly .NET pour extraire du contenu.

// Search Indexing Toolkit – SIT
C’est une implémentation générique d’un connecteur d’indexation Il a un modèle de données générique mais implémente la complexité du batching, du crawling (full/incrémentale), security trimming (gestion de la sécurité dans les résultats).
Dans le package il y a de l’XML avec un modèle, une interface à implémenter éventuellement.
SIT XML file connecter peut indexer n’importe quel fichier XML.
Bon il va très vite dans ce qu’il sait faire, en résumé c’est un outil top, qui est scalable, performant, flexible.

// DEMO
Il ouvre le package SIT. On voit des éléments de démos. Des DLL, des classes à récupérer. Et des scripts powershell permettent de déployer le tout.
Il montre un fichier XML qui liste différents documents à crawler.
Un autre de configuration SIT.
Le docandidpath permet au connecteur de savoir dans le fichier XML des éléments à crawler, comment le connecteur doit accéder (en DOM) à l’URL de l’identifiant du document.
Il lance une commande Powershell et utilise le Powershell qui va déployer notamment dans le GAC. Un autre Powershell lui permet d’enregistrer le fichier XML de configuration sur le service de recherche et d’ajouter le type de source de contenu à sa content source.
Eventuellement le script peut lancer un full crawl.
En allant voir dans le schéma de recherche, on voit qu’un certain nombre de Managed Properties sont créées pour être utilisées dans les résultats de recherches.
On peut désactiver ça en allant dans les crawled proprettes.
Il ouvre ULS Viewer et filtre sur la catégorie contient SIT pour voir comment se comporte le crawl.
Il utilise Search Query Tool disponible sur Codeplex pour faire une requête et tester son contenu.
Il fait une recherche sur la contentsource wikiabstracts qu’il a créé, et trouve les résultats de son fichier.

// SIT ISearchConnector interface
En implémentant cette interface, il y a 6 méthodes à implémenter.
Le ContentSource permet de définir le nom de la source de contenu.
Initialize() permet d’initialiser les paramètres du connecteur (lieu de stockage etc).
GetAllItems() permet grâce avec les paramètres offset (taille du match), crawlType, changeToken et changeTokenUpdate qui permettent de différencier le contenu de deux crawl consécutifs. Cette méthode génère un tableau d’ID de document.
GetSpecificItem(id) permet de retrouver un item en fonction de son ID fournit ci-dessus.
GetSpecificItemData(id) permet de récupérer le contenu.
GetSecurityDescriptorForSpecificItem(itemId, aclmeta, usesPluggableAuth) permet de gérer la sécurité d’un item (security trimming).

// Item level security
Chaque document doit supporter la sécurité NTLM, et être taggé.
Sinon on doit implémenter custom claims avec un provider ou security trimmer.

// Exemples de scénarios
Crawler des fichiers XML générés depuis des applications tierces.
SQL Server avec du security trimming.
SQL Server avec un BLOB relié sur un partage réseau.

// Content enrichment
C’est la façon d’enrichir du contenu existant.
Content Enrichement Web Service (CEWS).
C’est un web service qui est configuré sur le moteur de recherche via Powershell qui va prendre en input des données déjà existantes, et fournir en sortie des managed propreties qui seraient enrichies, nettoyées ou en tout cas traitées.
Il nous montre dans un rapport du service de recherche que cet enrichissement prend très peu de temps.
Quelques éléments à prendre en compte, c’est que les propriétés doivent exister, que c’est case sensitives, qu’on ne peut pas utiliser d’alias, et des propriétés par défaut sont parfois déroutantes car ressemblant à des propriétés existantes (DisplayAuthors vs Author). Enfin certaines propriétés sont en readonly (body). On ne peut avoir qu’un seul webservice par service application de recherche.
Attention à augmenter la capacité de la ferme en conséquence, et la topologie serveur.
Quelques techniques pour implémenter ça.
On peut utilise WCF Routing grâce à .NET 4.0.(http://aka.ms/Pqkjjj) Faire du Load balancine pour gérer la scalability.

// CEWS Pipeline Toolkit
Il y a un toolkit facilitant l’amélioration du contenu.
Il améliore le Search Index.
C’est fait en WCF avec un XML de configuration.
Il permet de simplifier et de cacher des complexité d’agrégation de service, de gestion de scalability.
Ce qu’il y a dans le package ? 55 stages permettant de gérer vraiment plus configurations avec l’XML de configuration. Cela fonctionne sur SharePoint 2010 avec FAST, ou SharePoint 2013 .. ou tout seul.
On peut le customiser avec Visual Studio 2012 et .NET 4.5.
Il y a beaucoup de documentation sur le wiki TechNet.

// DEMO
Il va montrer de quoi le package est composé.
Il montre déjà le résultat, il recherche « europe » et voit qu’il y a des éléments venant de wikipedia avec des raffinements sur la gauche, wikipedia population, la catégorie wikipedia qui sont custom.
On navigue dans pas mal de fichiers XML dans le package CEWSPT pour décrire comment les raffinements sont faits. Impossible de tout retranscrire mais il explique en gros que c’est très flexible et configurable, et que l’usage est plutôt bien documenté.

// How to get the tools
On peut récupérer les outils via un contact chez MCS, un contact chez PFE.
Le disponibilité en public est en cours d’approbation.

Christian

[SPC14] Search driven publishing portal in SP Online

Mail de Fabien

Session présentée par :
• Alex Pope
• Helge Grenager Solheim: fast team a Oslo
• Tous deux Microsoft

Session IT Pro

// Résumé
Une session sur la CSWP. Une nouveauté: un cache est disponible. C’est tout, le reste, on savait déjà.

// intro
Ca va parler de la content Search webpart.
Elle a été mise a disposition dans online en septembre.

On va parler display Template, group cache,…

Il nous rappelle l’architecture:
Le contenu d’un coté . La recherche l’index et la surface dans les pages :
• Contenu dans des listes, librairies
• Crawl, process index
• Load page , évaluation de la query
• Les résultats sont affichés via display templates

Il nous montre des cas d’usage de la cswp:
• Carrousel de news
• Document populaires
• Mes documents
Les news sont dans une liste sp.
L’ajout d’item n’est pas immédiat car l’index doit tourner.

// Search driver publishing in SPO vs on premise

Dans on premise seulement: faceted navigation, taxonomy refinement, product catalog site template

Dans O365: tout le reste

// CSWP
• On ajoute la wp
• On sélectionne la query
• On sélectionne le display template

// display templates
Des natifs existent, ils sont basiques.
Des custom possible en html/js

// création des propriétés automatiquement
Les colonnes de listes sont automatiquement mappée vers des crawled properties. Les colonnes de site, des crawled et des mapped.

// démo
Il nous fait une démo de paramétrage de CSWP sur O365.

Utiliser sort by viewsRecent pour trier par popularité.
Utiliser filtre by « name of the user who runs the query » pour mes items.

// CSWP group cache

Une nouveauté. Permet de réduire le temps de chargement des pages en ne rejouant pas a chaque fois les pages. 15min de cache par défaut.
Le cache est lié a un groupe AD (qui doit avoir droit de lecture), par exemple « lecteurs de news ».

Dans les settings de la cswp, une option de Caching est apparue.

Il ne faut pas l’utiliser : sur les pages avec requêtes personnalisée, ou avec de la sécurité granulaire ou sur les pages avec peu de trafic.

// best practices

Si on load beaucoup de manager properties, et qu’on ne peux pas cacher le résultat, penser à paramétrer la cswp en mode chargement asynchrone.

// cswp vs cqwp

préférer la cswp.
Cqwp: pas de latence à cause de l’index. C’est le seul avantage.

Fabien