Dentro de SharePoint Crear una solución de almacenamiento externos para SharePoint

Pav Cherny

Descarga de código disponible en: ChernySharePoint2009_06.exe(2,006 KB)

Contenido

Almacenamiento binario interno
Almacenamiento binario externo
Creación un proveedor de EBS no administrado
Creación un proveedor de EBS administrado
Registrar un proveedor de EBS en SharePoint
Implementación de la colección de elementos no utilizados
Conclusión

Microsoft estima que el 80 por ciento de los datos almacenados en Microsoft Windows SharePoint Services (WSS) 3.0 y bases de datos de contenido de Microsoft Office SharePoint Server (MOSS) 2007 es datos de no relacionales objeto binario grande (BLOB), como documentos de Microsoft Office Word, hojas de cálculo de Microsoft Office Excel y presentaciones de Microsoft Office PowerPoint. Sólo el 20 por ciento es relacional metadatos, que implica un uso suboptimal de los recursos de Microsoft SQL Server en el servidor de base de datos. SharePoint no aprovecha de recientes innovaciones de SQL Server para los datos no estructurados que se introdujo en SQL Server 2008, tales como el atributo FILESTREAM o la API de almacenamiento de BLOB remoto, pero proporciona sus propias opciones para aumentar la eficacia del almacenamiento y la facilidad de administración de volúmenes de datos masiva.

En concreto, SharePoint incluye un proveedor de almacenamiento externo binario API, que es ISPExternalBinaryProvider, que Microsoft primero publica como una revisión en mayo de 2007 y incorporado más adelante en Service Pack 1. La API ISPExternalBinaryProvider es independiente de la API de almacenamiento remoto BLOB. Otros fabricantes pueden utilizar esta API para integrar SharePoint con soluciones de almacenamiento avanzadas, como sistemas de almacenamiento de contenido direccionables (CAS). También puede utilizar esta API para mantener datos de objeto BINARIO de SharePoint en un servidor de archivos central fuera de las bases de datos de contenido si desea crear una solución personalizada para aumentar la eficacia del almacenamiento y la escalabilidad en un conjunto de servidores de SharePoint. Tenga en cuenta, sin embargo, que esta API es específico para WSS 3.0 y MOSS 2007. Cambiará en la próxima versión de SharePoint, lo que significa que tendrá que actualizar su proveedor.

En esta columna, describa cómo extender la arquitectura de almacenamiento de SharePoint mediante la API ISPExternalBinaryProvider, incluidos ventajas y desventajas, los detalles de implementación, las consideraciones de rendimiento y recopilación de elementos no utilizados. También explico una compatibilidad de 64 bits problema de Microsoft Visual Studio que pueden causar SharePoint un error de carga administrado ISPExternalBinaryProvider componentes a pesar de una implementación de interfaz correcta. Si es apropiado, consulte la documentación ISPExternalBinaryProvider en WSS 3.0 SDK. Otra referencia merece la pena mencionar es Blog de Kyle Tillman.

Kyle hace un excelente trabajo explica cómo había dominado los obstáculos de implementación en código administrado, pero no WSS 3.0 SDK ni del Kyle blog incluye un proyecto de ejemplo de Visual Studio, por lo que decidí proporcionar ejemplos de ISPExternalBinaryProvider en el código no administrado y administrado en material complementario de esta columna. El propósito de estos ejemplos es ayudar a empezar si está interesado en la integración soluciones de almacenamiento externo con SharePoint. Recuerde, sin embargo, que en estos ejemplos son no probados y no está listo para su uso de producción.

Almacenamiento binario interno

De forma predeterminada, SharePoint almacena datos BLOB de la columna contenida de la tabla AllDocStreams en la base de datos de contenido. La ventaja evidente de este enfoque es sencilla coherencia transaccional entre datos relacionales y el contenido del archivo no relacionales asociado. Por ejemplo, no es complicado para insertar los metadatos de un documento de Word junto con el contenido no estructurado en una base de datos de contenido ni es complicado para asociar los metadatos con el contenido no estructurado correspondiente en seleccionar, actualizar o eliminar operaciones. Sin embargo, la desventaja más evidente del enfoque predeterminado es un uso ineficaz de los recursos de almacenamiento. A pesar de un subsistema de E/s optimizado para alto rendimiento, el motor de almacenamiento de SQL Server es no exactamente un reemplazo de servidor de archivos.

Una base de datos de SQL Server consta de transacciones y datos de los archivos de registro, tal como se muestra en la figura 1 . Para garantizar el comportamiento transaccional confiable, SQL Server en primer lugar escribe todos los registros de transacciones en el archivo de registro antes de que vacía los datos correspondientes en las páginas de 8KB en el archivo de datos del disco. Según el modelo de recuperación seleccionado, esto requiere más de dos veces el tamaño de BLOB de capacidad de almacenamiento hasta que realice una copia de seguridad y purga el registro de transacciones. Además, SQL Server no almacena sin estructurar el contenido de SharePoint directamente en las páginas de datos. En su lugar, SQL Server utiliza una colección de páginas de imágenes o texto independiente y sólo almacena un puntero de texto de 16 bytes al nodo de raíz el BLOB de la fila de datos. Las páginas de texto y de las imágenes se organizan en un árbol equilibrado, pero hay sólo una colección de páginas de imágenes o texto para cada tabla. En la tabla AllDocStreams, esto significa que el contenido de todos los archivos se repartidos en la misma colección de páginas de imágenes o texto. Una página de texto o imagen puede contener fragmentos de datos de varios BLOB, o puede contener nodos intermedios de blob mayor 32KB de tamaño.

Figura 1 almacenamiento BLOB de SharePoint predeterminado en SQL Server

Vamos a no profundizar demasiado profundamente en elementos internos de SQL Server, aunque. La cuestión es que al leer el contenido sin estructura, SQL Server debe atravesar la fila de datos para obtener el puntero de texto y, a continuación, mediante el BLOB nodo raíz y nodos intermedios, posiblemente, adicionales para buscar todos los datos fragmentos propagar a través de cualquier número de páginas de imágenes o texto que SQL Server debe cargar en memoria por completo para obtener todos los bloques de datos. Esto se debe a que SQL Server realiza operaciones de E/s en el nivel de página. Estas complejidades afectar rendimiento de transmisión por secuencias de archivo en comparación a acceso directo a través del sistema de archivos. SQL Server también impone un límite de tamaño del disco duro de 2 GB en SharePoint ya que es la capacidad máxima del tipo de datos de imagen. La columna contenida de la tabla AllDocStreams es una columna de imagen, por lo que no puede almacenar archivos mayores de 2 GB en una base de datos de contenido de SharePoint.

Almacenamiento binario externo

La API de ISPExternalBinaryProvider ofrece una alternativa inteligente para almacenamiento interno de BLOB de bases de datos de contenido de SharePoint. Es una sencilla interfaz de COM con sólo dos métodos (StoreBinary y RetrieveBinary), que puede utilizar para implementar un proveedor de almacenamiento binario externos (EBS). Para obtener más información de arquitectura, vea el tema" Arquitectura de almacenamiento externo de BLOB"en WSS 3.0 SDK.

SharePoint carga su proveedor de EBS cuando se establece la propiedad ExternalBinaryStoreClassId del objeto SPFarm local (SPFarm.Local.ExternalBinaryStoreClassId) al identificador de clase de COM del proveedor (CLSID). SharePoint, a continuación, llama al método de StoreBinary del proveedor siempre que se envíen BLOB, como cuando se va cargar un archivo en una biblioteca de documentos. Puede decidir el proveedor de EBS almacenar el BLOB en su sistema de almacenamiento externo asociado y devolver un identificador de objeto BINARIO correspondiente (ID. BLOB) en SharePoint, o puede establecer el parámetro pfAccepted en el método StoreBinary en false para indicar que no controlan el BLOB. En este último caso, SharePoint almacena el objeto BINARIO en la base de datos de contenido como de costumbre. Por otro lado, si el proveedor de EBS acepta el BLOB, SharePoint sólo inserta el IDENTIFICADOR de objeto BINARIO la columna contenida de la tabla AllDocStreams, como se indica en la figura 2 . El IDENTIFICADOR de objeto BINARIO puede ser cualquier valor que permite el proveedor de EBS buscar el contenido en el sistema de almacenamiento externo, como un nombre de archivo, una ruta de acceso de archivo, un identificador único global (GUID) o un resumen de contenido. Por ejemplo, los proveedores de ejemplo incluidos en el material complementario, utilizar los GUID como nombres de archivo para la identificación confiable de blob en un servidor de archivos.

La Figura 2 el almacenamiento de un BLOB de SharePoint en un sistema de almacenamiento externo

SharePoint también realiza un seguimiento de los archivos guardados externamente al establecer el bit DocFlags más alto de estos archivos en 1. DocFlags es una columna de la tabla AllDocs. Cuando un usuario solicita para descargar un archivo almacenado externamente, SharePoint comprueba DocFlags y pasa el valor del contenido de la tabla AllDocStreams al método RetrieveBinary del proveedor de EBS. En respuesta a la llamada RetrieveBinary, el proveedor de EBS debe recuperar el BLOB indicado del sistema de almacenamiento externo y devolver el contenido binario a SharePoint en forma de un objeto COM que implementa la interfaz ILockBytes. Tenga en cuenta que SharePoint no llama al RetrieveBinary método de blob almacenados directamente en la base de datos de contenido.

Tenga en cuenta también que los procesos de almacenamiento y recuperación son transparentes para el usuario siempre que el usuario no intenta omitir SharePoint. Por lo tanto, no es necesario reemplazar los elementos Web integrados con versiones personalizadas que almacenan metadatos de corbata de una lista con un documento externo; las aplicaciones de productividad, como por ejemplo, Microsoft Office, no necesita saber cómo almacenar metadatos en un solo lugar y, a continuación, en el documento en otro; y búsqueda no es necesario para procesar los metadatos independiente de documentos. Además y esto es uno de mis favoritas ventajas de la arquitectura con proveedor de EBS, el usuario debe pasar por SharePoint acceso a datos BLOB externamente almacenados. Un usuario eludir las SharePoint y directamente tienen acceso a una base de datos de contenido a través de una conexión de SQL Server termina descarga los identificadores de objeto BINARIO en lugar del contenido del archivo real, como se muestra en la figura 3 . Puede comprobar este comportamiento si implementa el SQL descargar elemento Web (que utiliza en la columna abril de 2009 para demostrar cómo omitir la protección de RMS de Active Directory de SharePoint) en un entorno de prueba. Además, los usuarios no necesitan y no deberían tener, permisos de acceso en el almacén BLOB externo. Cuentas de seguridad de SharePoint sólo requieren acceso porque SharePoint llama a los métodos de proveedor de EBS en el contexto de seguridad de cuenta del grupo de aplicación del sitio.

La figura 3 EBS el proveedor puede ser un barricada para omitir los permisos de SharePoint para descargas de archivo

Tenga en cuenta, sin embargo, los proveedores de EBS también que inconvenientes debido a la complejidad de mantener la integridad entre metadatos en contenido bases de datos el conjunto de SharePoint y el almacén BLOB externo. Para obtener una buena explicación de los pros y los contras, consulte el tema" Los límites operativos y análisis de Trade-Off"en WSS 3.0 SDK. Asegúrese de que leer este tema muy importante antes de implementar un proveedor de EBS en un entorno de SharePoint.

Creación un proveedor de EBS no administrado

Ahora vamos a tratar los desafíos de creación de proveedores de EBS. La interfaz ISPExternalBinaryProvider está bien documentada en el SDK de WSS 3.0 en" La interfaz de Access BLOB: ISPExternalBinaryProvider." Sin embargo, parece que Microsoft olvidado cubrir los detalles del proveedor de EBS. Después de todo, no sólo consumen la interfaz de un servidor COM existente. Se están encargados de crear ese servidor COM nosotros mismos y implementa la interfaz ISPExternalBinaryProvider. Lo más importante, el SDK de WSS 3.0 no Mencione el tipo de servidor COM que se supone que generación y el modelo de subprocesamiento requerido. Puede ejecutar un servidor de COM clásico fuera de proceso o en proceso, y puede admitir el modelo de apartamento de subproceso único (STA), el modelo apartamento multiproceso (MTA) o ambos, o el modelo de subprocesamiento libre. Para que el proveedor de EBS para que funcionen correctamente, asegúrese de que crear un seguro para la ejecución de subprocesos en proceso COM servidor compatible con el modelo de subprocesamiento "ambas" para emisoras y el agente MTA.

También deberá pensar en qué idioma programación se va a utilizar. Esto es importante porque la interfaz ISPExternalBinaryProvider es la API de SharePoint de nivel inferior. Problemas de rendimiento pueden afectar al conjunto completo de SharePoint. Por este motivo, recomienda utilizando un lenguaje que le permite crear pequeño y rápido objetos de COM, como Visual C++ y Active Template Library (ATL). ATL proporciona clases de C++ útiles para simplificar el desarrollo de servidores de COM de subprocesos en código no administrado con el nivel correcto de soporte técnico de subprocesamiento.

Visual Studio también incluye una variedad de asistentes ATL. Sólo crear un proyecto ATL, seleccione Dynamic-link biblioteca (DLL) para el tipo de servidor, copia la definición de interfaz ISPExternalBinaryProvider desde el WSS 3.0 SDK en el interfaz definition language (IDL) archivo de su proyecto ATL, agregar una nueva clase para un ATL Simple Object, seleccione "Both" como el modelo de subprocesamiento y ninguna agregación, a continuación, haga clic con el botón secundario en la nueva clase, elija Agregar, haga clic en Implement Interface y seleccione ISPExternalBinaryProvider. Eso es todo! El Asistente para interfaz de implementación realiza todos los fontanería es necesario, por lo que puede centrarse en la implementación de los métodos StoreBinary y RetrieveBinary.

Y no permiten el código de C++ no administrado le intimide. Si se analizar el archivo SampleStore.cpp en el material complementario, puede ver que las implementaciones de StoreBinary e RetrieveBinary son relativamente sencillos. Básicamente, el método StoreBinary ejemplo construye una ruta de acceso de archivo basándose en un valor de registro StorePath, el ID de localización pasado desde SharePoint y un GUID generado para el objeto BINARIO y usa a continuación, la función de Win32 WriteFile guardar los datos binarios obtenidos de la instancia ILockBytes. El método RetrieveBinary de ejemplo, por otro lado, construye la ruta del archivo basada en el mismo valor de registro StorePath, el ID de localización y el IDENTIFICADOR de objeto BINARIO pasado desde SharePoint y, a continuación, usa la ReadFile de Win32 función para recuperar los datos no estructurados, que el proveedor de EBS copia en una nueva instancia de ILockBytes que pasa a continuación, volver a SharePoint. Figura 4 se ilustra cómo el proveedor de EBS construye la ruta de acceso del archivo.

La figura 4 creación de rutas para las operaciones de StoreBinary y RetrieveBinary en los proveedores de EBS de ejemplo

Creación un proveedor de EBS administrado

Por supuesto, no es necesariamente menos complicado que la creación de los proveedores no administrados de debido la complejidad de la interoperabilidad COM SharePoint a los desarrolladores que prefiera usando lenguajes administrados familiares para crear proveedores de EBS, incluso aunque la creación de administra los proveedores de EBS. Para el código necesita trabajar con la misma versión de CLR que está utilizando el resto de SharePoint, en caso contrario, es posible que terminan con un comportamiento inesperado, tenga en cuenta que una aplicación escrita en código no administrado sólo puede cargar una versión de common language runtime (CLR). También, todavía debe tratar interfaces no administradas y el del cálculo de referencias correspondientes de parámetros y los búferes. Sólo puede comparar SampleStore.cpp con SampleStore.cs en el material complementario. No hay ningún ganancias utilizando un lenguaje administrado en términos de la estructura de código o programación sencillez.

Además, ser consciente de problemas de compatibilidad de 64 bits si desarrolla los proveedores de EBS administrados en la plataforma x 64. la figura 5 muestra un error típico que resulta de no válido configuración de registro COM en un equipo de desarrollo. Si habilita el registro de la casilla de verificación interoperabilidad COM en las propiedades del proyecto de Visual Studio 2005 o Visual Studio 2008, le acabará con configuración de registro de COM para el proveedor en el registro bajo HKEY_CLASSES_ROOT\Wow6432Node\CLSID\ <providerclsid>. Visual Studio utiliza la versión de 32 bits de la herramienta de registro de ensamblado (Regasm.exe) incluso en la plataforma de x 64.

La figura 5 debido a configuración del registro de COM no válido, no se pudo cargar un proveedor de EBS administrado

Sin embargo, la versión de 64 bits de SharePoint no puede cargar un servidor de COM de 32 bits registrado en el Wow6432Node, por lo que debe registrar el proveedor administrado de EBS manualmente mediante la versión Regasm.exe de 64 bits, ubicada en el directorio %WINDIR%\Microsoft.NET\Framework64\v2.0.50727. Por ejemplo, el comando "% WINDIR%\Microsoft.NET\Framework64\v2.0.50727\Regasm.exe" ManagedProvider.dll crea la configuración del registro necesarios para el proveedor administrado de ejemplo en HKEY_CLASSES_ROOT\CLSID\ <providerclsid>. Otra solución es crear un programa de instalación y marca el proveedor de EBS de registro de COM automático.

Recuerde también que los proveedores de EBS administrados vienen con bastante más reducciones de carga y rendimiento que sus homólogos ATL no administrados. Puede ver si se compara la configuración de registro COM en el registro. Como la revela InProcServer32 clave, el motor en tiempo de ejecución COM carga archivos DLL de proveedor de EBS no administradas directamente, mientras que los proveedores de EBS administrados dependen mscoree.dll como el servidor de procesadores, que es el motor principal de CLR. Por lo tanto, para proveedores administrados, el motor en tiempo de ejecución de COM carga el CLR y, a continuación, el CLR carga el ensamblado de proveedor de EBS como registrado en la clave de ensamblado y crea un proxy COM contenedor al que se puede llamar (CCW) para controlar la interacción entre el cliente de SharePoint no administrado (owssvr.dll) y el proveedor administrado de EBS.

Tenga en cuenta que el servidor de SharePoint no administrado no interactúa directamente con su proveedor administrado. Es el CCW que calcula las referencias de parámetros, llama a los métodos administrados y controla los valores HRESULT. Es especialmente evidente en los tipos de devolución diferentes de métodos administrados en comparación con los métodos no administrados de este direccionamiento indirecto. Los métodos no administrados devolver valores HRESULT para indicar éxito o errores mientras métodos administrados se supone que el tipo de valor devuelto void. Por lo que al no, se devuelven valores HRESULT explícitos en código administrado. Deberá elevar sistema o excepciones de definido por el usuario en respuesta a las condiciones de error. Si un método administrado finaliza sin excepción, el CCW automáticamente Devuelve S_OK al cliente no administrado.

Por otro lado, si un método administrado provoca una excepción, el CCW asigna códigos de error y mensajes a los valores HRESULT y la información de error. El CCW implementa varias interfaces de tratamiento de errores para este propósito, tales como ISupportErrorInfo y IErrorInfo, pero SharePoint no aprovecha de estas interfaces. Los proveedores de EBS deben implementar sus propios informes mediante el registro de sucesos de Windows, registros de diagnóstico SharePoint, los archivos de seguimiento o otros medios de errores. SharePoint sólo espera que los valores HRESULT S_OK de éxito y E_Fail para cualquier error. Puede utilizar el método Marshal.ThrowExceptionForHR para devolver E_FAIL a SharePoint, como se muestra en SampleStore.cs.

Registrar un proveedor de EBS en SharePoint

Fácilmente la sección más confusa en ISPExternalBinaryProvider en WSS 3.0 SDK es el tema" Instalar y configurar un proveedor BLOB." En el momento de redactar este artículo, en esta sección se rellena con información confuso y los errores. Incluso los comandos de Windows PowerShell eran incorrectos. Si asigna el proveedor de EBS a $ yourProviderConfig y después utilizar $ providerConfig.ProviderCLSID, no se sorprenden cuando reciba un error que indica que providerConfig $ no existe. Por supuesto, incluso no alcanzar este punto porque las propiedades de activo y ProviderCLSID no forman parte de la interfaz ISPExternalBinaryProvider. Estas propiedades desconcertante pertenecen a una interfaz dual que no se trata en la documentación. Simplemente por diversión, implementa una versión de ejemplo en código no administrado y administrado, pero su implementación ISPExternalBinaryProvider no requiere estas propiedades propietarias en absoluto.

La propiedad ProviderCLSID puede ser útil, pero el CLSID está también disponible en el registro si busca el identificador de programa, como UnmanagedProvider.SampleStore o ManagedProvider.SampleStore, y también puede encontrar los CLSID en los archivos de código SampleStore.rgs y SampleStore.cs. Como se mencionó anteriormente, establecer la propiedad ExternalBinaryStoreClassId del objeto SPFarm local en el CLSID registra el proveedor de EBS. Si se establece la propiedad ExternalBinaryStoreClassId del objeto SPFarm local en un GUID vacío ("00000000-0000-0000-0000-000000000000"), eliminará el registro de proveedor de EBS. No olvide llamar al método de actualización del objeto SPFarm para guardar los cambios en la base de datos de configuración y reiniciar Internet Information Services (IIS). La lista de código siguiente muestra cómo realizar estas tareas de 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

Implementación de la colección de elementos no utilizados

Otra sección en los componentes desconcertante featuring de WSS 3.0 SDK y los fragmentos de código crítico es titulada" Implementar diferida Garbage Collection." En el momento de redactar este artículo, en esta sección contiene referencias a otra clase de utilidad desconcertante con métodos DirFromSiteId y FileFromBlobid, así como una asignación incorrecta de los resultados de Directory.GetFiles a una matriz de FileInfo, pero vamos a no ser demasiado exigentes en calidad de documentación de WSS 3.0. Los métodos auxiliares DirFromSiteId y FileFromBlobid revelan su propósito mediante sus nombres y la matriz de FileInfo incorrecta fácilmente se sustituye por una matriz de cadenas, o puede reemplazar el método Directory.GetFiles con una llamada al método GetFiles de un objeto DirectoryInfo. El programa de ejemplo de recolector de elementos no utilizados en el material complementario utiliza el enfoque DirectoryInfo y sigue la secuencia de pasos para la recolección de elementos sugerida.

Una desviación importante de la muestra recolector de elementos no utilizados de las explicaciones de SDK tiene relación con el tratamiento de condiciones de tiempo. Esto es un problema crítico porque las condiciones de tiempo pueden llevar a misidentification y eliminación de archivos válidos durante la recolección de elementos no utilizados. Eche un vistazo a la figura 6 , que ilustra el enfoque de WSS 3.0 SDK–recommended para enumerar todos los archivos de objeto BINARIO del almacén de EBS y, a continuación, quitar todas esas referencias de la lista de objeto BINARIO que están todavía en la base de datos de contenido como se indica a través ExternalBinaryIds colección del sitio determinar archivos huérfanos. Se supone que las referencias restantes en la lista BLOB para indicar archivos huérfanos que deben eliminarse.

Figura 6 Misidentification de un BLOB válido como " huérfanos " debido a una condición de tiempo

Sin embargo, el proveedor de EBS debe, por supuesto, primero terminado de escribir datos BLOB antes de que puede devolver un IDENTIFICADOR de objeto BINARIO a SharePoint. En función de ancho de banda de red y otras condiciones, puede fluctuación rendimiento de E/s. Por lo tanto, es probable que el proveedor de EBS podría crear un nuevo objeto BLOB, que a continuación, aparece en la lista BLOB, pero termina de escribir los datos BLOB cuando haya determinado la ExternalBinaryIds por lo que el IDENTIFICADOR de objeto BINARIO aún no está presente en esta colección. En consecuencia, la referencia para el nuevo objeto BINARIO permanece en la lista BLOB " huérfanos " y si purgar el blob " huérfanos " en este momento, accidentalmente eliminar un elemento de contenido válido y perder datos. Para evitar este problema, el recolector de elementos no utilizados de ejemplo comprueba la hora de creación de archivo y agrega únicamente aquellos elementos a la lista de objeto BINARIO que son más de una hora anterior.

Conclusión

Al integrar una solución de almacenamiento externo con SharePoint, puede aumentar la eficacia de almacenamiento, el rendimiento del sistema y escalabilidad de un conjunto de servidores de SharePoint. Otra ventaja es que esto obliga a los usuarios a pasar por SharePoint para tener acceso a contenido sin estructurar. Sólo la extracción de datos fuera de las bases de datos contenidos mediante conexiones directas de SQL Server genera identificadores BLOB binarios en lugar de los archivos reales. Sin embargo, los proveedores de EBS también tienen desventajas debido a la complejidad de mantener la integridad entre metadatos en contenido bases de datos el conjunto de SharePoint y el almacén BLOB externo.

Para integrar SharePoint con una solución de almacenamiento externo, debe crear un proveedor de EBS, que es un servidor COM que implementa la interfaz ISPExternalBinaryProvider con sus métodos StoreBinary y RetrieveBinary. Puede crear no administrado y administrar los proveedores de EBS, pero ten de problemas de rendimiento y compatibilidad si decide utilizar código administrado. También se tenga en cuenta que la interfaz ISPExternalBinaryProvider no incluye un método DeleteBinary. Explícitamente debe quitar BLOB " huérfanos " a través de elementos no utilizados diferida colección y tenga cuidado de evitar las condiciones de tiempo que pueden provocar la eliminación accidental de elementos BLOB válidos.

Pav Cherny es un experto en TI y el autor especializado en tecnologías de Microsoft para la colaboración y comunicación unificada. Sus publicaciones incluyen notas del producto, manuales de producto y libros con un foco sobre las operaciones y administración del sistema. Pav es presidente de Biblioso Corporation, una empresa que está especializada en servicios administrados de documentación y localización.