Partager via

Amélioration du fichier de modèle BDC pour la recherche SharePoint Server

  • Article

Cette rubrique fournit des informations sur les approches que vous pouvez adopter pour améliorer le fichier de modèle BDC pour Recherche SharePoint Server.

Dernière modification : mercredi 13 octobre 2010

S’applique à : SharePoint Server 2010

Dans cet article
Utiliser des E/S de propriétés inline lors de l’extraction de données à grande échelle
Optimisation de l’énumération lors de l’analyse de systèmes externes
Amélioration de la vitesse d’analyse avec la propriété UseClientCachingForSearch
Sécurité dans les fichiers de modèles BDC

Le modèle de métadonnées BDC comprend des propriétés conçues pour prendre en charge Recherche Microsoft SharePoint Server 2010 de manière spécifique. Pour obtenir une liste de ces propriétés et leurs descriptions, voir le tableau Propriétés spécifiques à la recherche dans les fichiers de modèles BDC dans Infrastructure de connecteur de recherche SharePoint Server. Lorsque vous souhaitez créer un fichier de modèle BDC pour un système externe que vous voulez activer pour la recherche, vous pouvez améliorer le fichier de modèle de façon à optimiser les performances lors de l’analyse des systèmes externes.

Utiliser des E/S de propriétés inline lors de l’extraction de données à grande échelle

En règle générale, si certaines des données renvoyées pour un élément sont à grande échelle, au lieu de les renvoyer avec la méthode SpecificFinder, vous devez utiliser l’une des méthodes spécialisées suivantes pour extraire les données :

  • Utilisez la méthode BinarySecurityDescriptorAccessor lorsque vous passez une liste de contrôle d’accès de sécurité plutôt qu’une propriété WindowsSecurityDescriptor.

  • Utilisez la propriété StreamAccessor lorsque vous passez des flux.

À moins que la latence du réseau ne soit élevée, le gain de performances est généralement supérieur au coût d’un trajet supplémentaire jusqu’au système externe.

Optimisation de l’énumération lors de l’analyse de systèmes externes

N’énumérez pas plus de 100 000 éléments par appel au système externe. Les énumérations de longue durée peuvent provoquer des interruptions intermittentes et empêcher l’achèvement d’une analyse. Il est conseillé que votre modèle BDC structure les données en dossiers logiques pouvant être énumérés individuellement, comme indiqué dans l’exemple suivant.

Cet exemple illustre l’énumération contre une table de base de données avec un million de lignes, mais avec un ensemble fixe de valeurs dans ColumnA. Dans ce scénario, vous pouvez considérer ColumnA comme le type de contenu externe et écrire un énumérateur pour cet ensemble de valeurs à l’aide de l’instruction SQL suivante.

SELECT DISTINCT( ISNULL(ColumnA,'unknown')) as ColumnA  FROM table

Ensuite, définissez le finder spécifique à l’aide de l’instruction SQL suivante.

SELECT DISTINCT( ISNULL(ColumnA,'unknown')) as ColumnA  FROM table where ColumnA = @Value

Pour finir, vous devez définir l’opération de navigation d’association comme suit.

Select * from table where ColumnA=@value

Toute méthode doit commencer à renvoyer des résultats dans les deux minutes, sinon le robot annule l’appel. Par exemple, l’exécution d’une instruction SQL complexe qui utilise une clause LIKE peut prendre plus de deux minutes et par conséquent provoquer l’annulation de l’appel par le robot.

Amélioration de la vitesse d’analyse avec la propriété UseClientCachingForSearch

La propriété UseClientCachingForSearch améliore la vitesse des analyses complètes en mettant en cache l’élément durant l’énumération. L’utilisation de cette propriété est également recommandée lors de l’implémentation d’analyses incrémentielles basées sur des journaux des modifications, car elle améliore la vitesse des analyses incrémentielles.

Important

Si les éléments font en moyenne plus de 30 kilo-octets, ne définissez pas cette propriété car cela entraînerait une augmentation du nombre d’échecs d’accès au cache et aurait un impact négatif sur les performances.

Sécurité dans les fichiers de modèles BDC

Si le référentiel utilise l’authentification NTLM, nous vous recommandons de spécifier l’authentification directe (PassThrough) pour l’analyse.

Les pages de profils peuvent nécessiter l’utilisation du Service Banque d’informations sécurisé à cause du problème de délégation multi-saut du serveur Web frontal. Si vous rencontrez ce problème, vous pouvez optimiser l’analyse tout en autorisant les pages de profils en créant deux instances LobSystemInstance similaires. La première instance doit utiliser des informations d’identification de l’authentification du Service Banque d’informations sécurisé. Cette instance ne doit pas contenir la propriété ShowInSearchUI. La seconde instance doit utiliser l’authentification directe et doit contenir la propriété ShowInSearchUI. Les pages de profils utilisent la première instance LobSystemInstance et le robot utilise la seconde instance.

Notes

Cela impose de définir la propriété ShowInSearchUI au niveau LobSystemInstance plutôt qu’au niveau LobSystem.