Architecture du stockage des données BLOB externe

Dernière modification : jeudi 8 octobre 2009

S’applique à : SharePoint Foundation 2010

Avant l'introduction du fournisseur de magasin de données BLOB externe (Binary Large Object) (fournisseur EBS), la sémantique du stockage des données BLOB consistait à acheminer le flux de données binaires associé à un fichier SharePoint vers la base de données de contenu Microsoft SQL Server, qu'elle partageait avec les données structurées du site. Dans ce scénario, lorsque vous appeliez une commande Save dans le fichier SharePoint, un analyseur dans le chemin d'accès Save reconnaissait la commande Save et promouvait une partie des métadonnées à partir du flux de fichier. Ensuite, les métadonnées, ainsi que l'objet BLOB associé au fichier, étaient stockées dans la base de données de contenu SQL Server.

Toutefois, une fois le fournisseur EBS installé, configuré et activé, la sémantique change considérablement. (Voir Figure 1.) À présent, au lieu de l'application Web, la pile d'accès au stockage intermédiaire achemine les flux de données BLOB et utilise le fournisseur EBS pour stocker les données BLOB dans le magasin de données BLOB externe, puis retourne les métadonnées qui lui permettent de récupérer l'objet BLOB à la demande. Notez que le modèle objet SharePoint Foundation est totalement isolé de la sémantique du fournisseur EBS, ainsi que de l'existence d'un magasin de données BLOB externe. Grâce à cette séparation, les applications et les services existants sont totalement ignorants des implémentations de stockage. Seule la pile d'accès au stockage est consciente de l'existence et de la sémantique du magasin de données BLOB externe.

Figure 1. Architecture du magasin de données BLOB externe

Le fournisseur EBS constitue votre implémentation personnalisée de l'interface de fournisseur, le ISPExternalBinaryProvider non managé, et est intégré à la pile d'accès au stockage en tant que composant COM.

L'interface de fournisseur vous propose deux méthodes : StoreBinary et RetrieveBinary. La pile d'accès au stockage reconnaît les commandes Save et Open et, lorsque celles-ci sont associées aux fichiers BLOB, appelle les méthodes StoreBinary et RetrieveBinary, respectivement.

Stocker le pipeline des objets BLOB : utilisation de la commande Enregistrer

Vous pouvez stocker les données BLOB dans le magasin de données externe en agissant sur la commande Save. La figure 2 est une illustration fonctionnelle de la façon dont une commande Save issue de l'application Web frontale est acheminée depuis la pile d'accès au stockage vers le fournisseur EBS, puis conservée de manière externe. Enfin, un enregistrement de son emplacement est conservé sous forme de métadonnées dans la base de données de contenu.

Figure 2. Stockage des objets BLOB à l'aide la commande Enregistrer

Lorsqu'une commande Save est appelée sur l’application Web frontale, la logique intermédiaire de l'application fournit une validation de logique d'entreprise, notamment les vérifications antivirus, la promotion de propriétés, la gestion des droits et d'autres tâches de prétraitement. Ensuite, la pile d'accès au stockage reconnaît que la commande Save concerne un fichier BLOB. L'interface de fournisseur transmet la demande au fournisseur EBS, qui enregistre le flux binaire dans le magasin de données BLOB externe.

Ensuite, le fournisseur EBS retourne l'ID de l'objet BLOB (BlobId) à l'interface, qui le transmet à la pile d'accès au stockage. Ensuite, la pile d'accès conserve l'ID et les métadonnées BLOB dans la base de données de contenu.

Le fournisseur EBS est chargé de retourner un identificateur unique ([out] ppbBinaryId) pour le fichier BLOB qu'il place dans le magasin de données BLOB externe.

Récupérer le pipeline des objets BLOB : utilisation de la commande Ouvrir

La récupération des données BLOB à partir du magasin de données BLOB externe est l'inverse de l'opération Save. Lorsque le fournisseur EBS reconnaît une commande Open sur un fichier associé à un objet BLOB, il appelle les méthodes sur l'interface de fournisseur pour récupérer le fichier à partir du magasin de données BLOB externe. La figure 3 est une illustration fonctionnelle de la façon dont une commande Open issue de l'application Web frontale permet à la pile d'accès au stockage de récupérer l'ID de l'objet BLOB dans la base de données de contenu, puis utilise l'ID pour récupérer le flux binaire dans le magasin de données BLOB externe.

Figure 3. Récupération d'un objet BLOB à l'aide de la commande Ouvrir

La pile d'accès au stockage récupère les métadonnées et BlobId en envoyant une requête Transact-SQL à la base de données de contenu ; ensuite, elle transmet la valeur de retour (BlobId) au fournisseur EBS afin qu'il puisse extraire le fichier binaire approprié du magasin de données BLOB externe à l'aide de la méthode RetrieveBinary sur l'interface ISPExternalBinaryProvider. La méthode retourne une interface ILockBytes à la pile d'accès au stockage.

Comme dans le cas de la méthode StoreBinary, le fournisseur EBS est responsable de la journalisation des événements de récupération. Windows SharePoint Server enregistre les retours HRESULT inattendus, mais se comporte sinon comme si les retours étaient simplement S_OK ou E_FAIL.

Les erreurs du fournisseur EBS sont mappées par la pile d'accès au stockage sur des codes d'erreur connus.

Voir aussi

Concepts

Stockage externe des objets BLOB (Binary Large Objects) dans SharePoint Foundation