SharePoint à l'intérieur Création d'une solution de stockage externes pour SharePoint

Pav Cherny

Téléchargement de code disponible à : ChernySharePoint2009_06.exe(2,006 KO)

Contenu

Stockage binaire interne
Stockage binaire externe
Création d'un fournisseur EBS non géré
Création d'un fournisseur EBS géré
Enregistrement d'un fournisseur EBS dans SharePoint
L'implémentation de nettoyage
Conclusion

Microsoft estime qu'autant que 80 % des données stockées dans Microsoft Windows SharePoint Services (WSS) 3.0 et bases de données de contenu Microsoft Office SharePoint Server (MOSS) 2007 sont des données non relationnelles objet BLOB binary large () Object, comme les documents Microsoft Office Word, des feuilles de calcul Microsoft Office Excel et des présentations Microsoft Office PowerPoint. Seulement 20 pour cent est métadonnées relationnelle, ce qui implique une suboptimal Utilisation des ressources de Microsoft SQL Server à la principale base de données. SharePoint ne tire pas parti des innovations de SQL Server récentes des données non structurées introduites dans SQL Server 2008, comme les FILESTREAM attribut ou l'API de stockage à distance BLOB, mais offre ses propres options pour augmenter l'efficacité du stockage et la facilité de gestion des volumes de données massifs.

Plus précisément, SharePoint inclut un fournisseur de stockage binaire externe API, ISPExternalBinaryProvider qui Microsoft publié en tant qu'un correctif dans 2007 tout d'abord et intégrées plus tard dans le Service Pack 1. L'API ISPExternalBinaryProvider est distinct de l'API de stockage BLOB à distance. Les fournisseurs tiers peuvent utiliser cette API pour intégrer SharePoint avec solutions de stockage avancée, tels que les systèmes de stockage adressables de contenu (CAS). Vous pouvez également utiliser cette API pour gérer données BLOB SharePoint sur un serveur de fichiers central en dehors de bases de données de contenu si vous souhaitez créer une solution personnalisée pour augmenter l'efficacité de stockage et l'évolutivité d'une batterie de serveurs SharePoint. Gardez à l'esprit, toutefois, que cette API est spécifique à WSS 3.0 et MOSS 2007. Il change dans la prochaine version de SharePoint, que vous devez mettre à jour de votre fournisseur.

Dans cette chronique, j'explique comment étendre l'architecture de stockage SharePoint en utilisant l'API ISPExternalBinaryProvider, y compris avantages et inconvénients, détails d'implémentation, améliorer les performances et garbage collection. JE également étudier un 64 bits de compatibilité problème de Microsoft Visual Studio qui peuvent provoquer SharePoint Échec du chargement gérés composants ISPExternalBinaryProvider malgré une implémentation interface correcte. Le cas échéant, J'AI reportez-vous à la documentation ISPExternalBinaryProvider dans le Kit de développement WSS 3.0. Une autre référence important de mentionner est Blog de Tillman Kyle.

Kyle fait un excellent travail expliquant comment il assimilé les obstacles implémentation en code géré, mais ni le Kit de développement WSS 3.0 ni du Kyle billet de blog inclut un projet d'exemple de Visual Studio, par conséquent, J'AI décidé de fournir des échantillons ISPExternalBinaryProvider dans du code non géré et géré dans Compagnon matériel cette colonne. Le ces exemples vise à vous aider à démarrer si vous êtes intéressé par Intégration des solutions de stockage externes à SharePoint. N'oubliez pas, cependant, que ces exemples sont non et pas prêt pour une utilisation de production.

Stockage binaire interne

Par défaut, SharePoint stocke des données BLOB dans la colonne contenue de la table AllDocStreams dans la base de données de contenu. L'avantage évident de cette approche est simple cohérence transactionnelle entre données relationnelles et le contenu du fichier non relationnelles associé. Par exemple, il se n'est pas compliquée pour insérer les métadonnées d'un document Word ainsi que le contenu non structurée dans une base de données de contenu, ni compliqué pour associer des métadonnées le contenu de non structurée correspondant dans la sélection, mise à jour ou supprimer des opérations à. Toutefois, l'inconvénient plus évident de l'approche par défaut est une utilisation inefficace des ressources de stockage. Malgré un sous-système d'E / S est optimisé pour des performances élevées, le moteur de stockage SQL Server est pas exactement un remplacement de fichier-serveur.

Une base de données SQL Server se compose de transaction de journal et données fichiers, comme illustré dans la figure 1 . Afin de garantir fiable comportement transactionnelle, SQL Server écrit tout d'abord tous les enregistrements de transactions dans le fichier journal avant qu'il vide les données correspondantes dans les pages 8KB au fichier de données sur disque. Selon le modèle de récupération sélectionnés, cette opération nécessite plus de deux fois la taille BLOB en capacité de stockage jusqu'à ce que vous effectuez une sauvegarde et vider le journal des transactions. En outre, SQL Server ne stocke pas du contenu non structuré SharePoint directement dans les pages données. Au lieu de cela, SQL Server utilise un ensemble distinct de pages de texte/image et ne stocke qu'un pointeur de 16 octets texte au nœud racine le BLOB de la ligne de données. Texte/image pages sont organisés dans une arborescence équilibrée, mais il n'est qu'une collection de pages Text/image pour chaque table. De la table AllDocStreams, cela signifie que le contenu de tous les fichiers est répartie sur la même collection de pages Text/image. Une page de texte/image unique peut contenir des fragments de données à partir de plusieurs blob ou il peut contenir nœuds intermédiaires pour BLOB plus 32KB de taille.

Figure 1 stockage BLOB SharePoint par défaut dans SQL Server

Pas Plongeons-nous trop profondément dans SQL Server internes, cependant. Le point est que lorsque lire du contenu non structuré, SQL Server doit passez la ligne de données pour obtenir le pointeur de texte et puis par le BLOB nœud racine et éventuellement autres nœuds intermédiaires pour trouver toutes les données fragments réparties sur n'importe quel nombre de pages de Text/image ce serveur SQL doivent charger en mémoire en entier pour obtenir tous les blocs de données. Cela est dû au fait que SQL Server effectue les opérations d'E / S au niveau de la page. Ces complexités affecter les performances de fichiers-diffusion en continu par rapport à accès direct via le système de fichiers. SQL Server impose également une limite de taille dur de 2 Go sur SharePoint car c'est la capacité maximale du type de données image. La colonne contenue de la table AllDocStreams est une colonne image, donc vous ne pouvez pas stocker plus de 2 Go de fichiers dans une base de données de contenu SharePoint.

Stockage binaire externe

L'API ISPExternalBinaryProvider offre une alternative astucieux au stockage BLOB interne dans les bases de données contenus SharePoint. Il est une interface COM simple avec uniquement deux méthodes (StoreBinary et RetrieveBinary), que vous pouvez utiliser pour implémenter un fournisseur de stockage binaire externe (EBS). Pour architecture d'informations, voir la rubrique » Architecture de stockage BLOB externe« Dans WSS 3.0 SDK.

SharePoint charge votre fournisseur EBS lorsque vous définissez la propriété ExternalBinaryStoreClassId de l'objet batterie locale (SPFarm.Local.ExternalBinaryStoreClassId) à identificateur de classe COM du fournisseur (CLSID). SharePoint appelle ensuite la méthode du fournisseur StoreBinary chaque fois que vous envoyer des données BLOB, tels que lorsque vous vous téléchargez un fichier à une bibliothèque de documents. Le fournisseur EBS pouvez décider de stocker le BLOB dans son système de stockage externe associé et renvoyer un identificateur BLOB correspondant (ID de BLOB) à SharePoint ou il peut définir le paramètre pfAccepted dans la méthode StoreBinary sur false pour indiquer qu'il n'a pas traiter le BLOB. Dans ce dernier cas, SharePoint stocke le BLOB dans la base de données de contenu comme d'habitude. D'autre part, si le fournisseur EBS accepté le BLOB, SharePoint uniquement insère le code BLOB dans la colonne contenue de la table AllDocStreams, comme indiqué dans la figure 2 . L'ID d'objet BLOB peut être toute valeur permet le fournisseur EBS pour localiser le le contenu dans le système stockage externe, comme un nom de fichier, un chemin d'accès au fichier, un identificateur global unique (GUID) ou un résumé de contenu. Les exemples de fournisseurs du support associé, par exemple, utilisent GUID comme noms de fichier pour l'identification fiable des données BLOB sur un serveur de fichiers.

La figure 2 stockage un BLOB de SharePoint dans un système de stockage externe

SharePoint également effectue le suivi de fichiers externe stockés en définissant le bit DocFlags le plus élevé de ces fichiers à 1. DocFlags est une colonne de la table AllDocs. Lorsqu'un utilisateur demande à télécharger un fichier externe stocké, SharePoint vérifie DocFlags et transmet la valeur de contenu de la table AllDocStreams à la méthode RetrieveBinary du fournisseur EBS. En réponse à l'appel RetrieveBinary, le fournisseur EBS doit extraire le BLOB indiqué le système de stockage externes et revenir le contenu binaire au SharePoint dans la forme d'un objet COM qui implémente l'interface ILockBytes. Notez que SharePoint ne pas appeler la méthode de RetrieveBinary pour BLOB stocké directement dans la base de données de contenu.

Notez également que les processus de stockage et la récupération sont transparent pour l'utilisateur tant que l'utilisateur n'est pas essayer de contourner SharePoint. Par conséquent, vous ne devez remplacer des composants WebPart intégrés par personnalisées versions que métadonnées égalité dans une liste avec un document stockées en externe ; les applications de productivité, telles que Microsoft Office, ne doivent savoir comment stocker des métadonnées dans un seul emplacement, puis sur le document dans un autre ; et recherche n'a pas besoin traiter les métadonnées distincte de documents. En outre et c'est un des mes avantages de l'architecture de fournisseur EBS préférés, l'utilisateur doit passer par SharePoint accéder aux données BLOB externe stockées. Un utilisateur contourner SharePoint et directement accéder à une base de données contenu via une connexion SQL Server finit par téléchargement BLOB ID au lieu du contenu du fichier réel, comme illustré dans la figure 3 . Vous pouvez vérifier ce problème si vous déployez le SQL composant télécharger WebPart (que J'AI utilisé dans la colonne 2009 avril pour montrer comment contourner la protection SharePoint AD RMS) dans un environnement de test. En outre, les utilisateurs n'avez pas besoin et doit être pas — autorisations d'accès à la banque BLOB externe. Seuls les comptes de sécurité de SharePoint requièrent l'accès car SharePoint appelle les méthodes de fournisseur EBS dans le contexte de sécurité de compte du pool d'applications du site.

La figure 3 EBS le fournisseur peut être un problème pour contourner les autorisations de SharePoint pour les téléchargements de fichiers

Gardez à l'esprit, toutefois, fournisseurs EBS également qu'inconvénients due à la complexité de conserver l'intégrité entre métadonnées dans les bases de données contenu de la batterie SharePoint et la banque BLOB externe. Pour une bonne explication d'et les inconvénients, consultez la rubrique » Limites opérationnelles et Trade-Off analyse« Dans WSS 3.0 SDK. Assurez-vous que vous consultez cette rubrique très importante avant d'implémenter un fournisseur EBS dans un environnement de SharePoint.

Création d'un fournisseur EBS non géré

Maintenant nous allons résoudre les défis de création de fournisseurs EBS. L'interface ISPExternalBinaryProvider est bien documenté dans WSS 3.0 SDK sous » L'interface Access BLOB : ISPExternalBinaryProvider." Toutefois, il semble que Microsoft oublié couvrir les détails de fournisseur EBS. Après tout, nous avons pas simplement utilisent l'interface d'un serveur COM existant. Nous chargées de création de ce serveur COM nous-mêmes et implémentant l'interface ISPExternalBinaryProvider. Plus important encore, le Kit de développement logiciel (SDK) de WSS 3.0 échoue Indiquez le type de serveur COM que nous sont supposés version et le modèle de thread requis. Un serveur COM classique pouvez exécuter out-of-process ou in-process, et il peut prend en charge le modèle STA (single-threaded apartment, le modèle MTA (multithreaded apartment ou les deux, ou du modèle de thread libre. Pour le fournisseur EBS fonctionner correctement, vérifiez que vous créez un thread-safe serveur in-process COM qui prend en charge le modèle de thread « les « pour STAs et l'agent de transfert des messages.

Vous devez également penser à la langue de programmation à utiliser. Il est important car l'interface ISPExternalBinaryProvider est l'API de SharePoint de niveau le plus bas. Problèmes de performances peuvent affecter la batterie entière. Pour cette raison, j'est recommandé d'en utilisant un langage qui vous permet de générer petit et rapide des objets COM, tels que Visual C++ et ATL (Active Template Library). ATL fournit des classes C++ utiles qui simplifient le développement des serveurs de COM thread-safe de code non managé avec le niveau approprié de threads prise en charge.

Visual Studio inclut également une variété de ATL Assistants. Uniquement créer un projet ATL, sélectionnez bibliothèque Dynamic-link (DLL) pour le type de serveur, copie la définition d'interface ISPExternalBinaryProvider à partir de la WSS 3.0 SDK dans le fichier interface définition langue (IDL) de votre projet ATL, ajoutez une nouvelle classe pour un ATL Simple Object "deux" Sélectionnez le modèle de thread et aucune agrégation ne puis cliquez avec le bouton droit sur la nouvelle classe, pointez sur Ajouter, cliquez sur Implement Interface et sélectionnez ISPExternalBinaryProvider. C'est tout ! L'Assistant Interface implémenter effectue toutes les plomberie nécessaire, afin que vous pouvez vous concentrer sur implémenter les méthodes StoreBinary et RetrieveBinary.

Et ne pas laisser non géré du code C++ vous intimidate. Si vous analysez le fichier SampleStore.cpp dans le matériel associé, vous pouvez voir que les implémentations StoreBinary et RetrieveBinary sont relativement simples. En fait, la méthode StoreBinary exemple génère un chemin de fichier basée sur une valeur de Registre StorePath, le code de site transmis à partir de SharePoint et un GUID généré pour le BLOB et puis utilise la fonction WriteFile Win32 pour enregistrer les données binaires obtenues à partir de l'instance ILockBytes. L'exemple RetrieveBinary méthode, d'autre part, construit le chemin du fichier en fonction de la même valeur de Registre StorePath, le code de site et le code BLOB transmis à partir de SharePoint et puis utilise la fonction ReadFile de Win32 pour récupérer les données non structurées, qui le fournisseur EBS copie dans une nouvelle instance ILockBytes qui il transmet à SharePoint. la figure 4 illustre comment le fournisseur EBS construit le chemin d'accès au fichier.

La figure 4 Élaboration des chemins d'accès pour les opérations de StoreBinary et RetrieveBinary dans les exemples de fournisseurs EBS

Création d'un fournisseur EBS géré

Bien entendu, SharePoint développeurs peuvent préfèrent utilisant des langages gérés familiers pour créer des fournisseurs EBS, même si la création géré EBS fournisseurs n'est pas nécessairement moins complexe que la création de fournisseurs non gérés en raison de la complexité de l'interopérabilité COM. N'oubliez pas qu'une application écrite dans le code non managé peut uniquement charger une version du common language runtime (CLR), donc votre code doit compatible avec la même version du CLR qui utilise le reste de SharePoint, sinon vous pourriez haut dont le comportement inattendu. En outre, vous toujours devez utiliser interfaces non gérés et le correspondant marshaling de paramètres et de tampons. Uniquement comparer SampleStore.cpp avec SampleStore.cs dans le matériel associé. Il existe sans gains en utilisant un langage géré en termes de structure de codes ou de simplicité de programmation.

En outre, n'oubliez pas de problèmes de compatibilité 64 bits si vous développez des fournisseurs EBS gérés sur la plate-forme x 64. la figure 5 illustre une erreur typique résultant de paramètres de l'enregistrement de COM non valides sur un ordinateur développement. Si vous activez l'historique des transactions pour COM Interop case à cocher dans les propriétés du projet dans Visual Studio 2005 ou Visual Studio 2008, vous obtiendrez avec COM enregistrement paramètres de votre fournisseur dans le Registre sous HKEY_CLASSES_ROOT\Wow6432Node\CLSID\ <providerclsid>. Visual Studio utilise la version 32 bits de l'outil d'inscription d'assembly (Regasm.exe) même sur la plate-forme x 64.

La figure 5 dû aux paramètres de l'enregistrement COM non valides, un fournisseur géré EBS Impossible de charger

Toutefois, la version 64 bits de SharePoint ne peut pas charger un serveur COM 32 bits enregistré sous le Wow6432Node, donc vous devez manuellement vous inscrire votre fournisseur EBS géré à l'aide la version 64 bits Regasm.exe, située dans le répertoire %WINDIR%\Microsoft.NET\Framework64\v2.0.50727. Par exemple, la commande % WINDIR%\Microsoft.NET\Framework64\v2.0.50727\Regasm.exe ManagedProvider.dll crée les paramètres de Registre requise pour le fournisseur géré exemple sous HKEY_CLASSES_ROOT\CLSID\ <providerclsid>. Une autre approche consiste à créer un programme d'installation et sélectionnez le fournisseur EBS pour l'enregistrement COM automatique.

N'oubliez pas également que fournisseurs EBS gérés fournis avec beaucoup plus pénalités de frais généraux et les performances que leurs équivalents ATL non gérés. Vous pouvez voir si vous comparez les paramètres d'inscription COM dans le Registre. En tant que le révèle InProcServer32 clé, le runtime COM charge DLL de fournisseur non gérées EBS directement, tandis que les fournisseurs EBS gérés reposent sur mscoree.dll comme le serveur in-proc, qui est le moteur de base du CLR. Par conséquent, pour les fournisseurs gérés, le runtime COM charge le CLR et ensuite le CLR charge l'assembly fournisseur EBS enregistré sous la clé d'assembly et crée un proxy CCW (COM callable wrapper) pour gérer l'interaction entre le client non géré SharePoint (owssvr.dll) et le fournisseur géré EBS.

Gardez à l'esprit qui le serveur SharePoint non géré n'interagit pas directement auprès de votre fournisseur géré. C'est le CCW qui regroupe des paramètres, appelle les méthodes gérés et gère HRESULT. Cette indirection est particulièrement visible dans les différents types de retour de méthodes gérés en comparaison à méthodes non managées. Méthodes non managées renvoient HRESULT pour indiquer les succès ou défaillances tandis que les méthodes gérés sont supposés avoir le type de retour void. Donc ne renvoyer HRESULT explicite dans du code managé. Vous devez augmenter système ou des exceptions définis par l'utilisateur en réponse à des conditions d'erreur. Si une méthode managée se termine sans une exception, le CCW renvoie automatiquement S_OK au client non géré.

En revanche, si une méthode managée génère une exception, le CCW mappe codes et messages sur HRESULT et des informations d'erreur. Le CCW implémente différentes interfaces de gestion des erreurs pour cela, tels que ISupportErrorInfo et IErrorInfo, mais SharePoint ne tire pas parti de ces interfaces. Fournisseurs EBS doivent implémenter leurs propres rapport par le biais le journal des événements Windows, SharePoint journaux de diagnostic, les fichiers de suivi ou tout autre moyen d'erreurs. SharePoint seulement prévoit que les HRESULT valeurs S_OK de réussite et E_FAIL pour toutes les erreurs. La méthode Marshal.ThrowExceptionForHR permet de renvoyer E_FAIL dans SharePoint, comme illustré dans SampleStore.cs.

Enregistrement d'un fournisseur EBS dans SharePoint

Facilement la section plus confuse sur ISPExternalBinaryProvider dans le Kit de développement WSS 3.0 est la rubrique" L'installation et configuration de votre fournisseur de BLOB." Au moment de la rédaction de ce document, cette section a été remplie avec les informations trompeur et les erreurs. Même les commandes de Windows PowerShell étaient incorrectes. Si vous affectez le fournisseur EBS à yourProviderConfig $ et ensuite utilisez $ providerConfig.ProviderCLSID, n'est pas peut surpris lorsque vous recevez une erreur indiquant que providerConfig $ n'existe pas. Bien entendu, vous ne même joindre ce point car les propriétés active et ProviderCLSID ne font pas partie de l'interface ISPExternalBinaryProvider. Ces propriétés mysterious appartient à une interface double qui n'est pas couvert dans la documentation. Pour vous amuser, J'AI implémenté une version exemple dans le code non géré et géré, mais votre implémentation ISPExternalBinaryProvider ne nécessite pas ces propriétés propriétaires du tout.

La propriété ProviderCLSID peut être pratique, mais le CLSID est également disponible dans le Registre si vous recherchez l'identificateur de programme, comme UnmanagedProvider.SampleStore ou ManagedProvider.SampleStore, et vous pouvez également trouver les CLSID dans les fichiers de code SampleStore.rgs et SampleStore.cs. Comme nous l'avons vu précédemment, définir la propriété ExternalBinaryStoreClassId de l'objet de batterie local pour le CLSID inscrit le fournisseur EBS. Définir la propriété ExternalBinaryStoreClassId de l'objet de batterie local en un GUID vide ("00000000-0000-0000-0000-000000000000 ») de supprime l'inscription du fournisseur EBS. N'oubliez pas appeler méthode de mise à jour l'objet batterie pour enregistrer les modifications dans la base de données de configuration et de redémarrer Internet Information Services (IIS). La liste de code suivant montre comment accomplir ces tâches dans Windows PowerShell :

[System.Reflection.Assembly]::LoadWithPartialName('Microsoft.SharePoint')
$farm = [Microsoft.SharePoint.Administration.SPFarm]::Local

# Registering the CLSID of an EBS provider
$farm.ExternalBinaryStoreClassId = "C4A543C2-B7DB-419F-8C79-68B8842EC005"
$farm.Update()
IISRESET

# Removing the EBS provider registration
$farm.ExternalBinaryStoreClassId = "00000000-0000-0000-0000-000000000000"
$farm.Update()
IISRESET

L'implémentation de nettoyage

Une autre section dans le Kit de développement WSS 3.0 featuring mysterious composants et les extraits de code critique est intitulée » L'implémentation de nettoyage différée." Au moment de la rédaction de ce document, cette section contenue des références à une autre classe d'utilitaire mysterious méthodes DirFromSiteId et FileFromBlobid ainsi que d'une affectation incorrecte des résultats Directory.GetFiles à un tableau de FileInfo, mais à alléger la disons ne pas être trop charge sur la qualité de documentation de WSS 3.0 des. Les méthodes d'application d'assistance DirFromSiteId et FileFromBlobid révèlent leur objectif via leur nom et le tableau de FileInfo incorrect est facilement remplacé par un tableau de chaînes, ou vous pouvez remplacer la méthode Directory.GetFiles par un appel à la méthode GetFiles d'un objet DirectoryInfo. Le programme d'exemple Garbage Collector dans le support Compagnon utilise l'approche DirectoryInfo et suit la séquence suggestion des étapes de garbage collection.

Un écart important de l'échantillon Garbage Collector des explications de Kit de développement logiciel (SDK) concerne la gestion des conditions de synchronisation. Ce critique problème est parce que les conditions de synchronisation peuvent entraîner misidentification et la suppression de fichiers valides lors de garbage collection. Observez figure 6 , qui illustre la méthode WSS 3.0 SDK–recommended pour déterminer les fichiers orphelins en énumérant tous les fichiers BLOB de la banque EBS puis supprimer ces références de la liste BLOB figurant toujours dans la base de données de contenu comme indiqué dans le site ExternalBinaryIds collection. Les références restantes dans la liste BLOB sont censés pour indiquer les fichiers orphelins qui doivent être supprimés.

La figure 6 Misidentification d'un objet BLOB valide en tant qu'orphelin en raison d'une condition de synchronisation

Toutefois, le fournisseur EBS doit, bien entendu, tout d'abord fini d'écrire données BLOB avant qu'il peut renvoyer un IDENTIFICATEUR de BLOB dans SharePoint. Niveau d'en fonction de la bande passante réseau et autres conditions, performances e / S fluctuation. Par conséquent, il est possible que le fournisseur EBS peut créer un nouvel objet BLOB — les puis apparaît dans la liste BLOB, mais se termine écriture des données BLOB après avoir déterminé le ExternalBinaryIds sorte que le code BLOB n'est pas encore présent dans cette collection. En conséquence, la référence à la nouvelle BLOB reste dans la liste BLOB orpheline et si vous purgez les BLOBs orphelins à ce stade, vous supprimez un élément de contenu valide accidentellement et perdez des données ! Afin d'éviter ce problème, l'exemple Garbage Collector vérifie l'heure de création fichier et ajoute uniquement les éléments à la liste BLOB qui sont plus datant d'une heure.

Conclusion

En intégrant une solution de stockage externes à SharePoint, vous pouvez augmenter l'efficacité de stockage, aux performances système et l'évolutivité d'une batterie SharePoint. Un autre avantage est que cela oblige les utilisateurs de passer par SharePoint pour accéder à contenu non structurées. Extraire des données de bases de données de contenu via les connexions directes SQL Server génère uniquement binaires identificateurs BLOB au lieu des fichiers réels. Cependant, fournisseurs EBS également comporter d'inconvénients due à la complexité de conserver l'intégrité entre métadonnées dans les bases de données contenu de la batterie SharePoint et la banque BLOB externe.

Afin d'intégrer SharePoint avec une solution de stockage externe, vous devez créer un fournisseur EBS, qui est un serveur COM qui implémente l'interface ISPExternalBinaryProvider avec ses méthodes StoreBinary et RetrieveBinary. Vous pouvez créer non géré et gérés EBS fournisseurs, mais sachez des problèmes de performances et la compatibilité si vous décidez d'utiliser du code managé. Gardez également à l'esprit que l'interface ISPExternalBinaryProvider n'inclut pas une méthode DeleteBinary. Vous devez explicitement supprimer BLOB orphelins dans différée garbage collection et veillez à éviter les conditions de temps qui peuvent entraîner la suppression accidentelle d'éléments BLOB valides.

Pav Cherny est un expert informatique et l'auteur spécialisé dans les technologies Microsoft de collaboration et de communication unifiée. Son compositions incluent les blancs, produit manuels et livres avec une spécialisation sur les opérations INFORMATIQUES et d'administration système. Pav est président de Biblioso Corporation, une entreprise spécialisée dans les services de documentation et de localisation gérés.