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] SPC305 // SharePoint Web Templates On-premises and in the Cloud

Mail de Christian

Mardi 04/03/2014 à 17h00

Speaker
Mirjam van Olst – SharePoint Architect @ Avanade Netherlands // MVP

Résumé
Très bonne session sur les WebTemplate que Mirjam conseille d’utiliser à la place des SiteDefinitions.
Que ce soit pour créer des sous-sites ou des collections de sites, c’est l’approche à utiliser.
Pour les sous-sites, il est possible d’utiliser ça dans le cloud. Même pour les collections de sites, c’est possible même si cela nécessite un peu plus de configuration à la création.

// Agenda
Site provisioning options
Web Template fundamentals
WebTemplates and App Webs
Custom solutions for site provisioning

// Site definitions
En SharePoint 2003 et SharePoint 2007, on ne pouvait faire que ça.
Depuis 2010, elle déconseille maintenant cette utilisation qui est faisable que côté full trust solutions.
Pour des questions de changement d’avis de clients (de quoi parle t-elle ? 🙂 ou de lourdeur de migrations etc.

// Web Templates
Introduit en 2010.
On peut créer les webtemplates en full trust ou en sandbox.
Ils ont un mécanisme de mise à jour.

// Site Templates
Créé en save site as template. Faisable en sandboxed.
Utilise les Webtemplates mais contient les fonctionnalités du site originel.
Ils sont faciles à créer mais ne sont pas stables (ne serait-ce quand on créé les champs ou types de contenus custom).

// Custom solutions for site provisioning On peut maintenant créer des Apps (en provider hosted) pour faire du remote provisionin.
On utilise alors les webservice full trust.
Voir la session de mercredi correspondante.

// Web Templates features
On utilise l’élément XML WebTemplate.
La feature qui la déploie est de scope Site ou Farm.
En Site, on peut créer que des sous-sites.
En Farm, on peut créer des collections de sites basées dessus.
On peut faire du on-premise et faire un full trust WSP.
En faisant du Sandbox, on peut déployer en Office 365, mais on ne peut plus mettre du code behind.
Pour ce faire, on va sur Visual Studio, on ajoute un Empty Element dans le projet SharePoint 2013.
On ajoute un fichier onet.xml. Dans le Elements, on va mettre les métadonnées du WebTemplate.
Si nous sommes en Farm Solution, le onet.xml sont stockés dans la feature.
Si nous sommes en Sandbox, on stocke tout en base de données.
Les WebTemplate sont basés sur un site définition, mais ils n’héritent PAS de leur site définition de base.
L’avantage des WebTemplate est qu’ils peuvent être changés après coup.
Dans l’Eléments, dans le noeud <WebTemplate> on a bien un BaseTemplateName, BaseTemplateID, BaseConfigurationID correspondant aux informations de la site def de base.
A noter, on ne peut avoir qu’une seule configuration dans le WebTemplate. Il faut donc créer plusieurs WebTemplates si on veut plusieurs « configurations ».

// Web Template provisioning
Processus de provisioning d’un site avec le Webtemplate.
Le système crée une URL pour le site.
Il lui applique la site def de base (le GLOBAL).
Si on crée une collection de sites : il active les features de scope Site dans l’ordre défini.
Si on crée un sous-site, il vérifie que les features de site collections sont activées.
Ensuite les features de scope Web sont activés.
Ensuite les listes instances du onet.xml sont créées.
Attention donc avec cet ordre, à l’ordonnancement des événements.

// Limitations des WebTemplate
On ne peut créer qu’une seule Configuration.
On ne peut utiliser de Module dans l’onet mais on peut créer des features avec des Module.
Feature Stapling ne fonctionne pas mais il n’y en a pas besoin car les WebTeampltes peuvent être mise à jour même en cours d’utilisation – il faut juste éviter les dépendances.
Les hiérarchies de variations ne sont pas possible, celle-là n’est pas contournante et il faut passer par la site définition – c’est un cas plus rare.

// Web Templates best practices
Il n’y a pas d’information sur les WebTemplate.
La parade : créer une feature scope web cachée. La rajouter au onet. Stocker le WebTemplate ID et son nom dans un property bag (ou une liste).

// DEMO
Elle a créé des solutions farm et sandbox avec des WebTemplate.
// En Farm solution. Le Name du WebTemplate doit matcher.
Elle créé une feature scope Farm où elle met son WebTemplate.
Elle copie le onet qui est dans le hive 15, elle supprime ce qu’elle n’avait pas besoin comme les DocumentTemplates. Elle a laissé une seule configuration.
Elle a copié depuis la feature BaseSiteStapling, les feature staplée à son site.
Elle a ajouté une feature scope Site qui ajoute une WebPart à la galerie, et un property bag qui enregistre en property bag sur la version de son WebTemplate.
Enfin elle a une feature scope Web qui ajoute la WebPart à la page.
Debug —> En déployant, elle peut maintenant créer une collection de sites basée sur son WebTemplate. Une fois créée, elle utilise SharePoint Manager // En Sandbox Elle fait globalement la même chose mais basé sur un PROJECTSITE. Elle s’aperçoit alors que dans l’onet, un module est présent pour la homepage. Elle copie ce module pour l’extraire dans un Module à part entière, qu’elle ajoute à une feature de scope Site.
Pour cette sandbox, il est aussi possible de créer un WebTemplate pour une collection de sites même si cela nécessite plus de travail de configuration. Effectivement il suffit de créer une collection de sites sans modèle (à choisir plus tard). On arrive sur le site, ajoute la solution sandbox, l’active, puis sélectionnons le modèle développé.

// AppWebs
Elle explique le fonctionnement des Apps et des sous-sites créés pour stocker les fichiers de l’App.
On peut créer l’App basée sur un custom WebTemplate.
Le WebTemplate se déploie en scope Web, dans l’App même.
Dans l’AppManifest, on spécifie WebTemplate dans les Properties avec un attribut ID=[GUID de la feature App Web]#[WebTemplate name].

// Custom solutions for Site Provisioning Une App provider-hosted qui provisionne le site et modifie à nos volontés. Jusque à on devait faire un webservice pour créer des collections de sites on-prem.
Maintenant on peut faire du site provisioning de collections de sites sur Office 365 en revanche.
Pour du on-prem, il faut attendre l’évolution de remote provisionning.
Il faut aller voir la session parlant de ça.

Christian

[SPC14] Branding internet facing website with SharePoint in the cloud

Mail de Fabien

Session présentée par :
• John Ross
• Randy Drisgill
• MVPs SharePoint chez Rackspace

// résume
Awesome session de la SPC 2012 !
Pas de chance, on est en 2014. Donc j’ai revu à 99% ce que j’ai vu il y a 1 an 1/2.
Mais petit rappel quand même pour ceux qui connaissent pas les composed look ou le design manager.

// intro to branding

Dans SharePoint: le branding s’applique sur les masters pages, les page layouts, css, webpart, images, …

Dans SharePoint 2010:
• Simple : thème
• Medium : custom css
• Complexe : master et layouts et xslt

Dans SharePoint 2013 ou SPO:
• Simple : composed look
• Medium : design manager custom css
• Complexe : master et layouts et display templates

Dans O365:
P plan : public web site
E plan : publishing feature disponibles + public site

// intro SPO public sites

Un site publishing simplifié public au maximum est disponible dans O365.
Header et Footer editable, un device Channel mobile, pas de cswp ou cswp.
Très limité mais parfait pour des petit sites vitrine de petites entreprises.
Il y a 41 composed looks dans ces sites contre 18 pour les sites standards.

Exemple : http://whymicrosoft.com

// branding simple : composed looks

Explication rapide du principe. Plus de détails dans la session précédente de Christian.
Il font une démo, rien de neuf.

// Branding moyen : design manager

Aucun changement.
Le design manager est toujours là pour permettre de designer dans SharePoint avec n’importe quel outil, pas forcement SPD. Il nous fait une démo sur online. Mais c’est pareil on premise.

// branding complexe : masters et layouts

Pas abordé.

// Cloud vs on premise

3 possibilités:
Cloud : O365
On premise dans le Cloud : Azure (ou autre hébergeur)
On premise : chez moi

Il y a une grille de décision dans les slides. En gros le public site de SPO n’est adapté que pour des petits sites vitrine.

Bref… next.

Fabien