Search
IT Pro Magazine – SharePoint 2013 en 5 points
Hello à tous
Dans le numéro du moi de Mai, vous pouvez trouvez mon article sur SharePoint 2013 en 5 points.
Consultable sur le site : www.itpro.fr
Bonne lecture !
SharePoint 2013 : Taxonomy & Search Service Application Database & VariantType
Beaucoup de changement sont apparus au niveau du moteur de Search, la cause étant le renouveau en terme d’architecture, FAST oblige, mais aussi la capacité à tenir la charge notamment sur la haute disponibilité. Ici je me suis intéressé sur le schéma de base de données de Search Service Application Database, qui s’est vu offrir de nouvelle table et modèle. Je me concentre plus particulièrement sur les gestion de la Taxonomy. En effet, lors de certains test relatif à la construction de champs taxonomique purement CUSTOM (TAXHTFIELD0 etc..), je me suis demandé si les VariantType lors de la création via Powershell étaient toujours renseignés au sein des tables SQL sous SharePoint 2013. Il s’avère que NON, car le modèle à changer et permet aujourd’hui d’offrir plus de souplesse.
SharePoint 2010 Schéma :
Voici le schéma relatif à la gestion de la Taxonomy sous Search, en somme un schéma assez simple.
Le contenu de la table MSSManagedProperties
Suivi du contenu de la table MSSCrawledProperties où nous retrouvons notre Colonne VariantType.
SharePoint 2013 Schéma :
Voici maintenant l’évolution , ca risque de piquer un peu !
Cette fois-ci nous retrouvons de nouvelle tables et relations, l’existant de 2010 est présent mais a été remanié.
MSSSchemaOwner : Schéma Directeur , Permet la gestion du multi tenant et d’assuré de la disponibilité sur la ferme, elle comprend MSSTenant et MSSSiteCollection
Dépendent d’elle : MSSSchemaPropertyMappings, MSSCrawledProperties, MSSManagedProperties, MSSSchemaPropertyMappingsPending, MSSManagedPropAlias, MSSMnagedPropOverrides
Notons aussi l’évolution de la table MSSCrawledProperties
Comme vous le pouvez constater le VariantType a disparu.
Ainsi que MSSManagedProperties
VariantType Déprécié:
Afin de vérifier que la création de d’une nouvelle CrawledProperty et de m’assurer que les VariantType ont bien disparu, direction MSDN
http://technet.microsoft.com/en-us/library/ff608064(v=office.15).aspx l’on voit l’option VariantType est toujours supporté.
Alors un petit script pour tester :
$searchapp = Get-SPEnterpriseSearchServiceApplication
$cat = Get-SPEnterpriseSearchMetadataCategory -SearchApplication $searchapp -Identity People
$crawlprop = Get-SPEnterpriseSearchMetadataCrawledProperty -SearchApplication $searchapp -Category $cat
New-SPEnterpriseSearchMetadataCrawledProperty -SearchApplication $searchapp -Name "MyCrawlProp" -PropSet "00110329-0000-0110-c000-000000111146"
-Category "People" -IsNameEnum $false -VariantType 4127 -IsMappedToContents $false
Et lors de son exécution l’on s’aperçoit qu’elle est finalement dépréciée !
La CrawledProperty est bien créée mais ne possède plus la propriété VariantType ( Un champ vide se situe sous PropertyName)
Nous pouvons conclure qu’il vous faudra lors de la migration de certains scripts s’assurer que les options soient disponible.
IT Pro Magazine : SharePoint, Search et la Taxonomie
Hello à tous !
Dans le numéro d’octobre, vous pouvez retrouver en détail l’exploitation de la Taxonomie dans le moteur de recherche ” Search”.
Consultable bientôt sur le site : www.itpro.fr
Magazine Programmez – SharePoint 2010 PowerShell & Search
Hello à tous !
Ce mois-ci dans le numéro de Programmez vous retrouverez un article sur l’exploitation de la brique Search via des scripts PowerShell.
L’article est téléchargeable ici : http://www.programmez.com/magazine.php
Bonne lecture
SharePoint 2010 : Taxonomy & Search
Lorsque vous mettez en place ou utilisez la brique Search au sein d’une architecture Sharepoint ou de développement spécifique vous serez tôt ou tard contraint d’utiliser la taxonomie lors de votre recherche. Dans cet article nous allons exposer une problématique récurrente comment avoir dans ma recherche, un panneau de raffinement avec mes champs taxonomiques ?
Taxonomie et les côtés cachés
Bien souvent l’on se pose la question mais quel mode de fonctionnement interne SharePoint met en place pour la taxonomie. Voici un schéma récapitulatif
A chaque fois qu’une lise est créée et que celle-ci est provisionnée une autre liste l’est aussi, la TaxonomyHiddenList. Cette liste cachée qui se situe au niveau de la collection de site fait une copie littérale des éléments taxonomique de la liste standard. Son but principal est d’éviter les charges au niveau du service de métadonnées gérées et de fournir un cache de données pour la recherche.
Une fois que les données sont présentes, cela va déclencher d’autres évènements, qui sont pleinement associés à un Timer job, le « TaxonomyUpdateScheduler ». Celui-ci est chargé de mettre à jour le service de métadonnées gérées de façon répétée.
Concernant la TaxonomyHiddenList il est intéressant d’en comprendre sa structure:
Nous pouvons voir que bon nombre des composants sont destinés à assurer un lien vers le TermStore, les Termset et les Terms. Notons que deux champs sont assez spécifiques, CatchAllData et CatchAllDataLabel. Ce sont deux champs qui dépendent d’une feature cachée la TaxonomyFieldAdded et sont les points de destination des champs cachés TaxCatchAll et TaxCatchAllLabel de type LookupMulti dans une liste standard. En définitif un réel parallélisme s’opère entre nos listes et la TaxonomyHiddenList.
Search engine
Côté moteur de recherche, l’ensemble des remontées des données se fait en fonction d’un schéma bien précis. Celle-ci repose en partie sur l’utilisation d’une propriété spécifique de type crawl « ows_taxid_MetadataAllTagsInfo». Celle-ci permet de connecter l’ensemble des valeurs de type crawl sous-jacentes et des métadonnées dépendantes. Il est important de signaler que pour une remontée effective des données taxonomiques, il est nécessaire d’avoir l’ensemble des composants présents dans le moteur de recherche. En cas de non présence de ceux-ci, nous nous retrouverons avec une recherche non effective et incohérente.
Bonne pratique
Lorsque vous utilisez pleinement l’UI de SharePoint pour créer vos collections de site, vos listes avec des données taxonomiques et que vous opérez une recherche, tout fonctionnera correctement, car l’ensemble des mécanismes (expliqué plus haut) sont gérés nativement par SharePoint. Qu’en est-il lorsque vous passez par solutions « Customs » ?
Le fait de passer par des solutions personnalisées, englobant collection de site, listes, bibliothèques de documents etc.., doivent elles aussi prendre en compte les mécanismes internes de SharePoint. Pour ce faire voici quelques bonnes pratiques à avoir lorsque vous créer des listes personnalisées reposant sur des champs taxonomiques.
Champs de la liste
Ici rien de bien compliquer, il suffit de bien renseigner les attributs de vos champs (TaxonomyFieldType / TaxonomyFieldTypeMulti), puis de prendre en compte la convention de nommage obligatoire de Microsoft, permettant de bien spécifier que les champs de de type Note, sont des champs taxonomiques (XXX_Note_0, et XXX_NoteTaxHTField0).
Binding de la liste
Une fois que les définitions sont correctes, il vous faudra les associer (binding), dans notre exemple nous utilisons la façon déclarative, mais vous pouvez tout à fait utilisez la voie programmatique.
FieldRef de la liste
Restons toujours dans la bonne démarche en ajoutant, côté définition, les champs propres à notre taxonomie, puis les fameux « TaxCatchAll » et « TaxCatchAllLabel » avec leur guid associé. Ainsi nous sommes sûrs que la liste sera bien reliée à la TaxonomyHiddenList.
Features de la liste
Dernière étape, il vous faudra associer deux features, l’un de type ItemAdding, et l’autre de type ItemUpdating. Les deux héritent de l’assembly Microsoft.SharePoint.Taxonomy et implémente la classe Microsoft.SharePoint.Taxonomy.TaxonomyItemEventReceiver.
Dernière feature à ajouter à votre projet, elle concerne la « TaxonomyFieldAdded ». Petit rappel, cette feature n’est pas activée dans une solution de type BLANK. En tant que bonne pratique, il faut l’ajouter en tant que Feature Activation Dependencies.
Lancement de la recherche
A ce stade nous disposons de l’ensemble des bonnes pratiques permettant côté déclaratif de positionner notre structure taxonomique il nous reste cependant à relier le tout côté programmatique. Cela se fait dans l’EventReceiver de la feature dédiée au déploiement de nos listes.
public override void FeatureActivated(SPFeatureReceiverProperties properties) { SPSite site = properties.Feature.Parent as SPSite; ConnectTaxonomyField(site,"FF7B4A1E-43FC-432C-973A-23C57C5C09CD", "TermGroup", "Termset"); } public static void ConnectTaxonomyField(SPSite site, Guid fieldId, string termGroup, string termSetName) { if (site.RootWeb.Fields.Contains(fieldId)) { TaxonomySession session = new TaxonomySession(site); if (session.DefaultKeywordsTermStore != null) { // get the default metadata service application var termStore = session.DefaultKeywordsTermStore; var group = termStore.Groups.GetByName(termGroup); var termSet = group.TermSets.GetByName(termSetName); TaxonomyField field = site.RootWeb.Fields[fieldId] as TaxonomyField; // connect the field to the specified term field.SspId = termSet.TermStore.Id; field.TermSetId = termSet.Id; field.TargetTemplate = string.Empty; field.AnchorId = Guid.Empty; field.Update(); } else { throw new TermStoreNotFoundException(
string.Format("DefaultKeywordsTermStore not found in site {0}", site.Url)); } } else { throw new ArgumentException(
string.Format("Field {0} not found in site {1}", fieldId, site.Url), "fieldId"); } } } [Serializable] public class TermStoreNotFoundException : Exception { public TermStoreNotFoundException() { } public TermStoreNotFoundException(string message) : base(message) { } public TermStoreNotFoundException(string message, Exception inner) : base(message, inner) { } protected TermStoreNotFoundException(
System.Runtime.Serialization.SerializationInfo info,
System.Runtime.Serialization.StreamingContext context) : base(info, context) { } } public static class TaxonomyExtensions { public static Group GetByName(this GroupCollection groupCollection, string groupName) { if (String.IsNullOrEmpty(groupName)) { throw new ArgumentException("Taxonomy group ne peut pas être nul", "name"); } foreach (var group in groupCollection) { if (group.Name == groupName) { return group; } } throw new ArgumentOutOfRangeException("groupName", groupName, "Impossible de trouver le taxonomy group"); } public static TermSet GetByName(this TermSetCollection termSets, string termSetName) { if (String.IsNullOrEmpty(termSetName)) { throw new ArgumentException("Term set name ne peut être vide", "name"); } foreach (var termSet in termSets) { if (termSet.Name == termSetName) { return termSet; } } throw new ArgumentOutOfRangeException("termSetName", termSetName, "Impossible de trouver le term set"); } }
Une fois le code d’exemple écrit dans notre Event Receiver, nous pouvons procéder aux tests en lançant un Full crawl.
Résultat dans Search
Une fois un item ajouté voici ce que nous devons retrouver dans notre interface de Search au niveau des Metadata properties.
Dans cette figure je vous ai présente les valeurs correctes qui doivent être retournées afin d’avoir une recherche effective au niveau du panneau de raffinement et les mauvaises valeurs qui mal conceptualisées ne vous permettront pas de retourner votre recherche.
Ce qui a pour effet de nous donner ceci lors de la recherche de nos éléments.
Conclusion
Il est important dès le début de bien cadrer les besoins nécessaires à la Taxonomie dans votre processus de création. De plus ce genre de problématique très fréquente, fait que si nous ne connaissons pas le mécanisme de SharePoint au niveau Taxonomique, nous serons contraints de passer énormément de temps à le découvrir et à trouver des solutions de correction, qui bien souvent se révèlent compliquées à mettre en place compte-tenu de l’existant.
Sharepoint 2010 – PowerShell et Search (Metadata)
Dans notre article nous allons aborder la modification de propriété d’indexation du moteur de recherche, ainsi que celle des Métadonnées gérées de SharePoint 2010 en PowerShell.
L’objectif recherché est de proposer des exemples simples, compréhensibles et de voir comment via l’utilisation de ILSPY, que certaines commandes ne sont pas si complètes que ça.
Crawling
Trois cmdlets sont principalement utilisées pour le Crawling : Get-SPEnterpriseSearchMetadataCrawledProperty, qui permet de récupérer les propriétés, Set-SPEnterpriseSearchMetadataCrawledProperty, celle-ci pour les mettre à jour et New-SPEnterpriseSearchMetadataCrawledProperty, pour la création.
Voici un exemple afin de récupérer des composants existant et de les mettre à jour avec la propriété IsMappedToContents qui permet de faire un mapping sur des métadonnées existantes, nous utilisons un fichier XML pour la récupération des éléments.
<? xml version=”1.0″ encoding=”utf-8″?>
<SearchProperties>
<ServiceName>Search Service Application</ServiceName>
<CrawledProperties>
<CrawledProperty Name=”ows_ContentType” />
</CrawledProperties>
<ExistingProperties>
<ManagedProperty Name=”ContentType”/>
</ExistingProperties>
<NewManagedProperties>
<!–Types = 1:Text, 2:Integer,3:Decimal,4:DateTime,5:YesNo,6 :Binary–>
<ManagedProperty Type=”4″ Name=”Demo”>
<Map Category=”Basic” Variant=”64″>15</Map>
</ManagedProperty>
</NewManagedProperties>
</SearchProperties>
Voici maintenant le code de Recherche :
if ( (Get-PSSnapin -Name Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue) -eq $null )
{
Add-PsSnapin Microsoft.SharePoint.PowerShell
}
#Fichier XML
[System.Xml.XmlDocument] $XmlDoc = new-object System.Xml.XmlDocument
$file = resolve-path(“.MonFichier.xml”)
if (!$file)
{
Write-Host “Fichier non trouvé- Opération Annulé.” -ForegroundColor red
Break
}
write-host -f Green “Traitement du fichier:” $file
$XmlDoc = [xml](Get-Content $file)
#Parse des données
$sa = $XmlDoc.SearchProperties.ServiceName
$searchapp = Get-SPEnterpriseSearchServiceApplication $sa
$CrawledPropNodeList = $XmlDoc.SearchProperties.CrawledProperties
write-host -f Yellow ” Recherche des données Crawl existantes :”
foreach ($CrawledPropNode in $CrawledPropNodeList.CrawledProperty)
{
$SPCrawlProp = $CrawledPropNode.Name
#Vérification
if($crawledproperty =Get-SPEnterpriseSearchMetadataCrawledProperty -Name $SPCrawlProp -VariantType $SPCrawlVariant -SearchApplication $searchapp -ea “silentlycontinue”)
{
write-host -f Green “Des Crawl existent: Nom :” $crawledproperty.Name “- Indexé :” $crawledproperty.IsMappedToContents
write-host “Mise à jour :”
$crawledproperty | Set-SPEnterpriseSearchMetadataCrawledProperty -IsMappedToContents $True
write-host -f Green “Nom :” $crawledproperty.Name “- Indexé :” $crawledproperty.IsMappedToContents
}
else
{
write-host -f Red “Veuillez vérifier dans le fichier XML et Sharepoint qu’ils existent”
}
}
Metadata
Concernant les Metadata ici nous utilisons deux méthodes Get-SPEnterpriseSearchMetadataManagedProperty, pour récupérer des métadonnées et Set-SPEnterpriseSearchMetadataManagedProperty, pour la mise à jour.
Concernant les attributs nous utilisons EnabledForScoping, pour définir l’indexation, FullTextQueriable, pour rendre la propriété requêtable, RespectPriority qui correspond dans votre interface utilisatrice aux phrases suivantes : « Inclure les valeurs à partir de toutes les propriétés analysées mappées » ou « Inclure les valeurs à partir d’une propriété analysée unique en fonction de l’ordre spécifié »
function ExistingMeta
{
#Gestion de propriétés pour Settings
$OthersPropertyNodeList = $XmlDoc.SearchProperties.ExistingProperties
foreach ($PropertyNode in $OthersPropertyNodeList.ManagedProperty)
{
$SharePointProp = $PropertyNode.Name
if($mp=Get-SPEnterpriseSearchMetadataManagedProperty -SearchApplication $searchapp -Identity $SharePointProp -ea “silentlycontinue” )
{
if($mp.EnabledForScoping -eq $False)
{
$mp | Set-SPEnterpriseSearchMetadataManagedProperty -EnabledForScoping 1
}
if($mp.FullTextQueriable -eq $False)
{
$mp | Set-SPEnterpriseSearchMetadataManagedProperty -FullTextQueriable 1
}
if($mp.RespectPriority -eq $False)
{
$mp | Set-SPEnterpriseSearchMetadataManagedProperty -RespectPriority 1 -ea “silentlycontinue”
}
}
}
}
Concernant la création nous utilisons la cmdlet suivante New-SPEnterpriseSearchMetadataManagedProperty
try
{
write-host “Création :”
$mp = New-SPEnterpriseSearchMetadataManagedProperty -SearchApplication $searchapp -Name $SharePointProp -Type $SharePointPropType -EnabledForScoping 1 -FullTextQueriable 1
$mp.HasMultipleValues = $True
$mp.Update()
}
catch [Exception]
{
write-host -f Red “Erreur de création” $_;
}
Pour associer un mapping au Metadata il vous faut exécuter le code suivant :
$PropertyNodeList = $XmlDoc.SearchProperties.NewManagedProperties
foreach ($PropertyNode in $PropertyNodeList.ManagedProperty)
{
$SharePointProp = $PropertyNode.Name
$SharePointPropType = $PropertyNode.Type
$SharePointPropMapList = $PropertyNode.Map
$SharePointPropMultiple = $PropertyNode.Multiple
foreach ($SharePointPropMap in $SharePointPropMapList)
{
$SPMapCat = $SharePointPropMap.Category
$SPMapName = $SharePointPropMap.InnerText
$SPVariant = $SharePointPropMap.Variant
$cat = Get-SPEnterpriseSearchMetadataCategory –SearchApplication $searchapp –Identity $SPMapCat
$prop = Get-SPEnterpriseSearchMetadataCrawledProperty -SearchApplication $searchapp -Category $cat -Name $SPMapName -VariantType $SPVariant
write-host -f Cyan $cat.Name “-” $prop.Name
$mp=Get-SPEnterpriseSearchMetadataManagedProperty -SearchApplication $searchapp -Identity $SharePointProp -ea “silentlycontinue”
try
{
write-host “Création de la donnée finale”
$property = New-SPEnterpriseSearchMetadataMapping -SearchApplication $searchapp -CrawledProperty $prop -ManagedProperty $mp
}
catch [Exception]
{
write-host -f Red “Erreur de création de la donnée finale” $_;
}
}
}
ILSPY
Deux propriétés ne sont pas accessibles au niveau des options des cmdlets, celles qui apparaissent dans la section suivante de l’interface utilisatrice des métadonnées : « Optimiser le stockage des propriétés gérées »
Pour mettre à jour les propriétés nous utilisons ILSPY afin de voir le code appelé dans la librairie suivante : Microsoft.Office.Server.Search.dll puis nous cherchons la propriété suivante : Microsoft.Office.Server.Search.Internal.UI.ManagedPropertyPage, la méthode correspondante à OkButtonClicked(object sender, EventArgs e). Dans cette méthode nous observons que deux propriétés n’existent pas dans les attributs des cmdlets, QueryPropertyBlob = true; et PutInPropertyBlob = true;
Il ne vous reste plus qu’à les appeler dans votre code PowerShell de la façon suivante :
$mp. QueryPropertyBlob = $True
$mp. PutInPropertyBlob = $True
$mp.Update()
Notons toutefois que ces propriétés sont référencées dans la MSDN et sont pleinement accessible en utilisant les API de SharePoint. En conclusion nous avons la possibilité grâce à PowerShell d’automatiser certains processus de création et de modification des composants de recherche.
Nabil BABACI 