SharePoint Search

[SharePoint 2013] – Indexation anormalement longue

Posted on Updated on

 

Bonjour à tous.

Aujourd’hui un article / KB concernant le moteur de recherche de SharePoint Server 2013.

Suite à la mise en place de ce moteur de recherche, j’ai pu constater un problème… que je n’avais jamais eu jusque ici !

Concernant le contexte, il s’agit de l’installation de SharePoint Server 2013 Standard en Français, sur Windows Server 2008R2 en Français également et couplé au moteur SQL Server 2008R2 SP1 en Français, installé sur un second seveur.

 

1/ Le problème

 

Lors du déploiement de l’application de service de recherche, j’ai utilisé l’assistant depuis la page de gestion des applications de service dans l’administration centrale de SharePoint.

J’ai nommé mon service “Application de recherche”, utilisé un pool dédié aux applications de service. Lors de la création, aucun problème constaté, le service est bien créé/configuré, les bases de données sont également ok.

Le problème est survenu lors de l’indexation d’une source de données SharePoint (Site SharePoint locaux par défaut) sur un site vide… La première indexation a duré plus de 25 heures !!!!

Evidemment ce n’est pas normal ! Après investigations, sur l’observateur d’évènements, les logs, etc. et activation du mode ‘Verbose” des logs, il s’est avéré que cette erreur se reproduisait constamment lors de l’indexation des données :

 

System.ArgumentException: La longueur de la valeur de la clé ‘application name’ dépasse sa limite fixée à ‘128’.

à System.Data.SqlClient.SqlConnectionString..ctor(String connectionString)     à System.Data.SqlClient.SqlConnectionFactory.CreateConnectionOptions(String connectionString, DbConnectionOptions previous)     à System.Data.ProviderBase.DbConnectionFactory.GetConnectionPoolGroup(DbConnectionPoolKey key, DbConnectionPoolGroupOptions poolOptions, DbConnectionOptions& userConnectionOptions)     à System.Data.SqlClient.SqlConnection.ConnectionString_Set(DbConnectionPoolKey key)     à System.Data.SqlClient.SqlConnection.set_ConnectionString(String value)     à System.Data.SqlClient.SqlConnection..ctor(String connectionString, SqlCredential credential)     à Microsoft.Office.Server.Data.SqlSession.OpenConnection()     à Microsoft.Office.Server.Data.TransactionalSqlSession.RetrySqlConnectionInitialization(Action`1 initializer)     à Microsoft.Office.Server.Data.TransactionalSqlSession.OpenConnection()     à Microsoft.Office.Server.Data.SqlSession.ExecuteNonQuery(SqlCommand command) à Microsoft.Office.Server.Search.ManagedSqlSession.ExecuteNonQuery()

SqlCommand: ‘SET XACT_ABORT ON’     CommandType: Text CommandTimeout: 0

 

 

Bon évidemment premier réflexe… un coup de moteur de recherche… pas vraiment concluant. J’ai donc supprimé l’application de service, recréé… et même erreur !

 

 

La solution

 

En fait… ce n’est pas si compliqué que ça ! En nommant mon application de service de recherche “Application de recherche”, l’assistant nomme les bases de données :

“Application_de_recherche_[UN MEGA GUID PAS BEAU]”.

Et il semblerait que la connectionstring soit trop longue !!!!!!! (dépasse les fameux 128 caractères stipulés dans le log de l’erreur)

 

La solution peut donc être de deux formes. Soit on recréé une application de service de recherche à l’aide de l’assistant, en choisissant un nom plus court… et en priant pour qu’il soit assez court.

Soit on déploie le service avec notre ami PowerShell / Management Shell pour SharePoint.

Et vous l’aurez compris… je préfère largement la seconde option.

Voici donc le script que j’ai utilisé pour recréer ce service :

 

Création du pool d’application pour notre service :

  • $appPoolName = Nom du pool : SharePointSearchAppPool
  • $appPool = Pool d’application créé
    • Compte : DEMO\spapppool ==> domaine : Demo, compte utilisé : spapppool

 

$appPoolName = “SharePointSearchAppPool”
$appPool = New-SPServiceApplicationPool -Name $appPoolName -Account “DEMO\spapppool”

 

 

Divers paramètres :

  • $searchServerName  = Nom du serveur de recherche
  • $serviceAppName = Nom du service d’application
  • $searchDBName = Nom de la base de données du service

 

$searchServerName = (Get-ChildItem env:computername).value
$serviceAppName = “Application de recherche”
$searchDBName = “SPSearch_DB”

 

 

Démarrage des services sur le serveur :

 

Start-SPEnterpriseSearchServiceInstance $searchServerName
Start-SPEnterpriseSearchQueryAndSiteSettingsServiceInstance $searchServerName

 

 

Création de l’application de service de recherche et récupération de l’instance :

 

$searchServiceApp = New-SPEnterpriseSearchServiceApplication -Name $serviceAppName -ApplicationPool $appPoolName -DatabaseName $searchDBName
$searchProxy = New-SPEnterpriseSearchServiceApplicationProxy -Name “$serviceAppName Proxy” -SearchApplication $searchServiceApp

$searchServiceInstance = Get-SPEnterpriseSearchServiceInstance

 

 

Clonage de la Topologie de recherche par défaut :

 

$clone = $searchServiceApp.ActiveTopology.Clone()

New-SPEnterpriseSearchAdminComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance

New-SPEnterpriseSearchContentProcessingComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance

New-SPEnterpriseSearchAnalyticsProcessingComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance

New-SPEnterpriseSearchCrawlComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance

New-SPEnterpriseSearchIndexComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance

New-SPEnterpriseSearchQueryProcessingComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance

$clone.Activate()

 

 

Et voilà !

Advertisements

SP2010 – Afficher les document Office dans Office WebApps depuis la page de résultat de recherche

Posted on Updated on

Bonjour à tous.

L’une des grandes forces de SharePoint 2010 (et d’autres produits Microsoft bien entendu) est de proposer la visualisation des documents Office (en particulier Word, PowerPoint, Excel, OneNote) directement dans la page Web (dans le navigateur), sans utiliser les applications clientes de la suite Office, le tout grâce aux Office Web Apps.

A quoi servent ces Office Web Apps… et surtout à qui ?

Dans l’entreprise, il est parfois pratique d’utiliser ces Office Web Apps pour visualiser rapidement des documents stockés dans SharePoint (mais également Hotmail, SkyDrive, etc.) dans le navigateur, sans la nécessité d’avoir la bonne version d’Office client installé (2003, 2007, 2010 sans parler des Office XP).

C’est donc très pratique pour s’affranchir des limitations dues à la compatibilité non ascendante des produits Office. Un utilisateur d’Office XP ou 2003 ne pourra pas exemple pas ouvrir un fichier produit avec Office 2010. Effectivement le format de fichier a changé depuis (passage à l’OpenXML depuis Office 2007, et du coup changement d’extension des fichiers pour tous les produits : doc vers docx, xls vers xlsx, ppt vers pptx…).

Et d’expérience, on a souvent cohabitation des toutes les versions de la suite bureautique au sein même d’un même société. Dur dur de collaborer !!! C’est là que les Office Web Apps interviennent, permettant d’afficher mais également de produire ces types de fichier depuis le navigateur, et alors plus de problème avec les versions d’Office !

C’est également bien pratique pour les postes qui ne sont pas sous Windows (ou Mac OS avec la suite Office) : les distributions linux par exemple, tablettes (et j’en passe). Ils utilisent directement le navigateur pour produire les fichiers (attention au navigateur, certains ne sont pas supportés (détail) :

Word, Excel, et PowerPoint peuvent être affichés en utilisant de nombreux périphériques mobiles. Navigateurs mobiles supportés par les Office Web Apps sur SharePoint 2010 : Internet Explorer sur Windows Mobile 5/6/6.1/6.5; Safari 4 sur iPhone 3G et 3GS; BlackBerry 4.x et supérieur ; Nokia S60; NetFront 3.4, 3.5, et supérieur; Opera Mobile 8.65 et supérieur; et Openwave 6.2, 7.0 et supérieur. Navigateurs mobiles supportés par les Office Web Apps sur Windows Live : Safari 4 sur iPhone 3G et 3GS, et Internet Explorer 7 sur Windows Phone 7. Afficher des documents Excel dans un navigateur mobile est uniquement possible avec les Office Web Apps sur SharePoint 2010.

Attention également, tout n’est pas possible avec les Office Web Apps (création d’entêtes / pieds de page, sommaires, …).

Voilà pour l’introduction !

Maintenant le sujet : dans SharePoint Server 2010 (ou SharePoint Foundation + Search Server Express 2010 par exemple), on utilise bien souvent le centre de recherche pour concentrer les recherches des utilisateurs sur un seul site qui fait office de portail de recherche (recherche de documents, personnes).

En installant les Office Web Apps sur votre ferme, les utilisateurs deviennent capable d’ouvrir les documents dans le navigateur (et on peut même modifier le comportement par défaut d’ouverture des documents pour que les ficihers Office soient ouverts dans Office Web Apps et pas dans le client installé.

Mais que se passe-t’il si on ouvre un fichier Office depuis la page des résultats de recherche ? de la même manière si on a fixé le comportement par défaut de la bibliothèque pour que SharePoint ouvre les fichiers dans Office Web Apps ?

Réponse… SharePoint quand même d’ouvrir le fichier dans Word ou de télécharger le fichier si Office n’est pas installé !!! on s’y attend pas…

Mais du coup comment faire pour que la page des résultats de recherche ouvre les document Office dans Office Web Apps ?? Tout simplement en modifiant le template de rendu du WebPart affichant les résultats de recherche. Ce template est du xsl-t, transformant le flux récupéré lors de l’exécution de la recherche (XML) en HTML avec application de Styles.

Il faut donc éditer ce template (propriétés du WebPart, Modèle de rendu) et ajouter juste après :

          <div class=”srch-Title2″>

<div class=”srch-Title3″>

<!– links with the file scheme only work in ie if they are unescaped. For

this reason here we will render the link using disable-output-escaping if the url

begins with file.–>

<xsl:choose>

Ceci :

<xsl:when test=”substring($url,string-length($url) – 4,5) =’.docx’ or substring($url,string-length($url) – 3,4) =’.doc’ or substring($url,string-length($url) – 4,5) =’.pptx’ or substring($url,string-length($url) – 3,4) =’.ppt’ and $IsDesignMode = ‘False'”>

<xsl:text disable-output-escaping=”yes”>&lt;a href=”</xsl:text>

<xsl:value-of disable-output-escaping=”yes” select=”serverredirectedurl” />

<xsl:text disable-output-escaping=”yes”>” id=”</xsl:text>

<xsl:value-of disable-output-escaping=”yes” select=”srwrt:HtmlAttributeEncode(concat($currentId,’_Title’))” />

<xsl:text disable-output-escaping=”yes”>” title=”</xsl:text>

<xsl:value-of disable-output-escaping=”yes” select=”srwrt:HtmlAttributeEncode(title)” />

<xsl:text disable-output-escaping=”yes”>”&gt;</xsl:text>

<xsl:choose>

<xsl:when test=”hithighlightedproperties/HHTitle[. != ”]”>

<xsl:call-template name=”HitHighlighting”>

<xsl:with-param name=”hh” select=”hithighlightedproperties/HHTitle” />

</xsl:call-template>

</xsl:when>

<xsl:otherwise>

<xsl:value-of select=”srwrt:HtmlEncode(title)”/>

</xsl:otherwise>

</xsl:choose>

<xsl:text disable-output-escaping=”yes”>&lt;/a&gt;</xsl:text>

</xsl:when>

Vous l’aurez compris, ce bout de transformation xsl-t teste l’extension du fichier (si docx, doc, pptx, ppt et on pourrait ajouter Excel…) et si le résultat courant est d’un de ces types, on affiche un lien HTML (serverredirectedurl) mis en forme et redirigeant vers la page Office Web apps affichant le type de fichier trouvé. Simple comme bonjour (ou presque) !