Friday, 7 January 2011

RBS Primer

Problem: Provide a quick overview of Remote Blob Storage (RBS).

Overview:  When uploading files into a document library or list, the data is stored in the content database, this consists of meta data and the binary blob.  All content database storage is done using SQL Server, the recommended maximum threshold for content databases is 200GB (they can be bigger depending on you IO speed on your SQL Server - this applies to SP2010 (pre SP1), MOSS had a recommended 100GB content db limit from MS) these binaries can make your content database big that results in expensive storage as the disks are usual RAID 10, backup operations can take a long time and speed of data access/write can slow down.
You can configure RBS on a per content database on your farm using 'storage providers'.  There are 3rd party suppliers that provide the storage and the 'storage provider' and they make claims of saving clients up to 90% of their content database size.  You can also store the blobs on files systems.  RBS is useful for medium and large farms, it can be applied retrospectively be setting up RBS on a content db and performing a backup and restore.  EBS was performed at a farm level whereas RBS is content database level.
RBS is only a good candidate if your content database has blobs, the blobs are individually bigger than 256KB and you content database is over 100GB.  RBS is more useful on really big content db's.  Content database size is bizaarly calculated by including the content db size plus the RBS storage.
Tip: RBS is similar to EBD in MOSS except it's applied at a content db level.
Tip: RBS requires SQL Server 2008 R2 (I'm not sure if SQL 2008 will work).  FILESTREAM needs to be activated on SLQ Server for RBS to work.
Tip: SP 2010 has a hard limit of 2GB per item, this is due to SQL server using the varbinary (max) column type for storage and IIS recommended max app pool sizing.  Changing to RBS will still enforce a maximium size of 2GB per file.
Tip: RBS is setup on the farm using PowerShell there is no CA UI interface.

What RBS gives you:
  1. Performant SharePoint farm - the most common bottle neck is SQL Server in SP2010 farms, by reducing the blobs being stored and retrieved within the content database you get better performance on your farm.
  2. Lower cost of disk storage - SQL is normally stores data on your SAN, these disks are expensive and usually RAID10.  Additionally, the backup/HA/mirroring/clustering will also be expensive disk space.  Using RBS moves all your storage to cheaper disk storage.  Furthermore, you normally use an external RBS supplier so if you RBS storage is growing you only pay for the current storage unlike in SQL you would need to have the space to provide for future growth.
  3. Faster DR - Your farm backup and recovery process will generally be faster but more complex.  As the content db's are smaller you can backup and recover quicker however you now have to ensure RBS data is part of your DR planning.
  4. Dead link data - you need to run RBS tools to delete data from RBS that has already been removed by SP2010.
Source: Srini Acharya & Burzin Patel - Externalising BLOB storage in SP2010 slide deck.  This slide shows the process of saving a document using RBS and SP2010.

Providers of RBS:
  • AvePoint
  • OpenText
  • EMC (EBS based I believe)
  • StoragePoint (Metalogix) EBS or RBS based.
More Info:
http://technet.microsoft.com/en-us/library/ff628254.aspx

Tuesday, 4 January 2011

Developer dashboard custom scoped monitoring

Problem: You have poor performing code how do you identify the bottleneck.
Initial Hypothesis: Use the SPMonitoredScope to determine how long code takes to execute.
Resolution: Turn on the developer dashboard, deploy your custom code that includes monitored code.
Exampleusing Microsoft.SharePoint.Utilities 
using (new SPMonitoredScope(“My Scope Name”))
{
   doSomeWork();    //  Shows in the ULS and the Developer dashboard
}
Tip: You can't use SPMonitorScope in sandbox solution code.  If you try us 'SPMonitorScope' your VS project won't compile and you will get the error: 'Microsoft.SharePoint.Utilities.SPMonitoredScope' is inaccessible due to its protection level.

More Info:
Post explaining how to turn on the developer dashboard
MSDN about using SPMonitorScope (like stopwatch in .NET)

SharePoint 2010 Editions

Compare SharePoint 2010 Editions
SharePoint 2010 Development Stack Platform
Licencing SharePoint 2010

Themes and branding

Themes can be set programatically and allow for an easy method to change corporate colours.
Themes combined with master pages allow for a fast way to change pages and colours.  It is faster than the generally prefered method of altering the css
Theme's reference

Friday, 31 December 2010

Closing a popup dialog after running server side code

Problem: A base page allows a user to perform additional logic such as inserting a a new row into a list via the Dialog Framework.  The new row is a custom page that is shown thru the Dialog framework.  The custom page contains a web part that allows the user to fill in a form, perform custom logic and insert the record.  You now need the dialog page/popup to close automatically after the server side code is run.  The problem is you need to run the server side code before closing the window.

Initial Hypothesis:  I have been using jQuery with a hidden server control to set a value on the server side after my custom server side actions.  Then after the page reloads due to the postback, on the jQuery $document ready I check if the hidden value has been set and if it has I use the dialog framework to close the page.  A fair amount of work and round trips to solve my problem.

I saw a post on the msdn forums which is much simpler & better solution.  I implemented this and it is much easier and better than my hidden variable approach.

Resolution:
Place the code snippet in the server side code i.e. in the button click after you have performed your server side logic.

More Info:
http://social.technet.microsoft.com/Forums/en-US/sharepoint2010programming/thread/ba06d5e5-8c4c-4bca-95f8-65f40c1b11fa

Wednesday, 29 December 2010

LINQ to SharePoint by Example

Problem: Simple examples to perform CRUD operations using LINQ to SharePoint. 
Resolution:
Read Operation/Select (Get a single row) & Update Operation/Update (Update a row), this code uses the default context constructor to retrieve the customer, you can use less code to achieve the same result.
Create Operation/Insert (Add a new row to a list)
Delete a customer list item.

Connected Web Part Series - Part 1

Problem: There is a lot of information relating to web parts however this series is aimed at connected web parts in SharePoint 2010.  This 1st post deals with creating a custom connection between 2 visual web parts (a provider & a consumer).

Overview:  Create a Interface to enable communication between the provider and the consumer web part.  Create Visual User controls to connect to each other. 
Tip: Web Parts are easier to connect than Visual Web Parts, so only use Visual web parts if there is a heavy visual requirement.

Steps:
Create a new Web Part (it will be the provider web part)
 Create an Interface (contract between the provider and consumer web parts)
 Implement the Interface in the Provider web part
Create the Consumer web part as shown below
Deploy the solution and activate the feature that contains the 2 web parts
In a browser add the 2 web parts to a page (Provider & Consumer) 
 Connect the 2 web parts as shown below