External blob Storage Architecture

Before introducing an external Binary Large Object (BLOB) storage provider (EBS provider, blob storage semantics transfers binary data streams associated with SharePoint files to the Microsoft SQL server content database shared with site structured data. In this case, if you call the Save command for a Sharepoint file, the analyzer in the SAVE path recognizes the Save command and promotes some metadata in the file stream. Store the metadata and blob associated with the file in the SQL server content database.

However, after the EBS provider is installed, configured, and enabled, the semantics changes significantly (see figure 1 ). Currently, BLOB data streams are transmitted not by Web applications but by the intermediate layer storage access stack, and BLOB data is stored in external blob storage using the EBS provider, then return the metadata that allows the blob to be retrieved as needed. Importantly, the SharePoint object model has nothing to do with the semantics of the EBS provider and the existence of external blob storage. This separation ensures that the storage implementation does not fully understand the existing applications and services. Only the storage access Stack knows the semantics of the external blob storage and whether it exists.

Figure 1. External blob Storage Architecture

The EBS provider is a custom implementation of the provider interface. It is a non-hosted ispexternalbinaryprovider and can be integrated into the storage access stack as a COM component.

The provider interface provides two methods: storebinary and retrievebinary. The storage access stack recognizes the SAVE and open commands. When these commands are associated with BLOB files, they call the storebinary and retrievebinary methods respectively.

Storage blob pipeline: Use the Save command

You can use the Save command to store BLOB data to external data storage. Figure 2 shows how to transfer the Save command in the front-end web application from the storage access stack to the EBS provider and store it to the outside. Finally, records about their locations are stored in the content database as metadata.

Figure 2. Blob storage using the Save command

When you call the Save command for a front-end web application, the middle layer logic of the application provides business logic verification, including anti-virus check, attribute upgrade, copyright management, and other preprocessing tasks. After that, the storage access stack recognizes that the Save command is for blob files. The provider interface passes the request to the EBS provider, and the EBS provider saves the binary stream to the external blob storage.

The EBS provider then returns the Blob ID (blobid) to the interface, which then passes the ID to the storage access stack. Access the stack and save the ID and blob metadata to the content database.

The EBS provider is responsible for returning a unique identifier ([Output] ppbbinaryid) for the Blob file stored in the external blob storage ).

Retrieve blob pipeline: use the open command

Retrieving BLOB data from external blob storage is opposite to the Save operation. When the EBS provider identifies the open command to be executed on the file associated with blob, it calls some methods on the provider interface to retrieve the file from the external blob storage. Figure 3 shows how the storage access stack uses the open command in the front-end web application to retrieve the Blob ID from the content database, and then uses the ID to retrieve the binary stream from the external blob storage.

Figure 3. Blob search using the open command

The storage access stack sends a Transact-SQL query to the content database to retrieve metadata and blobid. Then, the return value (blobid) is passed to the EBS provider, this allows the latter to use the retrievebinary method on the ispexternalbinaryprovider interface to obtain the corresponding binary file from the external blob storage. This method returns an ilockbytes interface to the storage access stack.

Like the storebinary method, the EBS provider is also responsible for recording retrieval events. Windows Sharepoint Server records unexpected hresult return values, but from the record results, the returned values seem to only include s_ OK or e_fail.

Storage Access stack maps EBS provider errors to known error codes.