Creating an Application Design - remote BLOB storage

Ramona Maxwell’s study notes, ©2010 All rights reserved

•      Remote BLOB storage requires BCS in order to retrieve BLOB data types into SharePoint and BCS in turn uses the StreamAccessor method to accomplish the task. It is recommended to use SharePoint Designer for the steps that can be performed within it, which are CRUD [create, read, update and delete] items. To actually call the specific data stream though, you must separately code in XML the actual StreamAccessor stereotype method. You can start with (for instance) a ReadItem method in SP Designer [SPD], add various property values for creating the external content type,  and after several other incremental steps proceed to ReadList - where you will want to include (per the test objective of storage management) a 'Limit' setting under Filter Paremeters configuration to restrict the number of records returned. After building this framework in SPD you can bump it out to an XML editor and build the StreamAccessor method manually. The method, when properly constructed, will call the column of the record containing the document based on its unique document ID passed in as a parameter.
•      The StreamAccessor method accepts four property type definitions including FileName, MimeType, MimeTypeField and and FileNameField. The FileName will serve as an identifier for the current and all subsequent StreamAccessor operations on one kind of file (for instance all Word .docx documents) while the FileNameField serves to determine whether there is a matching document type among the External Content Type (ECT) objects. The MimeType does more than identify the proper mail extensions, it also allows SP to select the correct IFilter type for the document being streamed. Both of the *Field properties are equivalent to the TypeDescriptor property of ECTs and therefore the MimeTypeField, when matching a TypeDescriptor within the ECT database, will return the proper MIME type for the document that is being streamed in. The contents of the MimeTypeField can be inferred by SP based on the file name extension listed in the FileName for standard file types however it doesn't make its own guess, based on the FileName or MimeType properties, until it checks for specific assignments in the FileNameField and MimeTypeField. Then SP processes the association of file type to its owning program on the server rather than querying associations on the client machine. If the MIME type cannot be determined by SP then the choice of owning program will be passed to the client in the form of a typical 'which program would you like to use to open this file' dialogue box with their installed programs listed.
•      At the point where you have created the StreamAccessor method in the XML file exported from SPD you are not quite done. You must delete your original SPD file because your completed BDC [Business Data Connectivity] model will not import successfully if the half-baked initial model is still present with the same name. Then you may follow the steps to import your BDC model from within the SP2010 BDC service application. As an aside, your  model is restricted from using special characters in the file name. You can continue to assign permissions to your model and also create a profile, or help page to assist anyone authorized to utilize it.
•      In the Microsoft TechNet article Overview of Remote BLOB Storage the cautionary introduction "Before you implement RBS, we highly recommend that you evaluate its potential costs and benefits." would certainly apply to the extra development effort described above. Non-BLOB content is delivered to SP by BCS on a menu-based silver platter.
       The respositing considerations involved in using RBS [Remote Blob Storage] vary by SP edition. In either edition, RBS is generally not recommended until the size of your content databases will exceed 500GB and/or the BLOB data files themselves are larger than 256KB. However if the BLOB data files are at minimum 80KB and the database server is hamstrung trying to process them through, then using RBS may improve performance by relieving I/O pressure and reducing the processing load. Factored into the decision to use RBS are first an expected benefit in reduced storage costs from moving BLOB data over to less expensive storage mediums, the size of the BLOB data and the frequency with which it is accessed. If the files are large and rarely accessed the benefit will be greater than for small files that are frequently sought out, which would increase latency. Not only is the SP edition you use a consideration, but how you are able to implement BLOB storage may be affected by which version of SQL Server you run, as just the  Enterprise edition can store the BLOB data remotely on Network Attached Storage (NAS) and that is only without using FILESTREAM as the RBS provider. This is not a limitation of FILESTREAM, which in SQL Server R2 does support NAS - but rather that SP does not yet fully implement the FILESTREAM provider's capabilities. The other versions of SP, Server and Foundation, must store the 'remote' BLOB data on the local database server's Directly Attached Storage [DAS] whether using FILESTREAM or another RBS provider. It was also noted in the documentation that SP Foundation users who do not want to upgrade from the free SQL Express to a full SQL Server edition (with associated licensing costs) can use RBS to fit their databases within the 4GB SQL Server Express allows.
•      The respositing considerations involved in using RBS [Remote Blob Storage] vary by SP edition. In either edition, RBS is generally not recommended until the size of your content databases will exceed 500GB and/or the BLOB data files themselves are larger than 256KB. However if the BLOB data files are at minimum 80KB and the database server is hamstrung trying to process them through, then using RBS may improve performance by relieving I/O pressure and reducing the processing load. Factored into the decision to use RBS are first an expected benefit in reduced storage costs from moving BLOB data over to less expensive storage mediums, the size of the BLOB data and the frequency with which it is accessed. If the files are large and rarely accessed the benefit will be greater than for small files that are frequently sought out, which would increase latency. Not only is the SP edition you use a consideration, but how you are able to implement BLOB storage may be affected by which version of SQL Server you run, as just the  Enterprise edition can store the BLOB data remotely on Network Attached Storage (NAS) and that is only without using FILESTREAM as the RBS provider. This is not a limitation of FILESTREAM, which in SQL Server R2 does support NAS - but rather that SP does not yet fully implement the FILESTREAM provider's capabilities. The other versions of SP, Server and Foundation, must store the 'remote' BLOB data on the local database server's Directly Attached Storage [DAS] whether using FILESTREAM or another RBS provider. It was also noted in the documentation that SP Foundation users who do not want to upgrade from the free SQL Express to a full SQL Server edition (with associated licensing costs) can use RBS to fit their databases within the 4GB SQL Server Express allows.