Pros and Cons of Integrated SharePoint SSRS
A customer recently asked me wether they should install SSRS in integrated or native mode in thier environement. Unfortunately the answer is “It Depends”….
Lets go over the pros and cons
|Use SharePoint to create a user friendly ReportMart using security baked into SharePoint||Users must access SharePoint to access their report. This seems like a non-issue at first until you begin to look at reports in a SOA pattern. Application that want to use reports will now need to access them thru the “SharePoint Layer”|
|Reports run slower. On average 500ms slower and it gets worse as load on the front ends increases. Probably not a big issue for SI|
|Reports can be snapshot at specific intervals to create a history of what the report what at a specific time interval. (run the report at each month end and keep a PDF of it)||Reports can be snapshot at specific intervals to create a history of what the report what at a specific time interval. (Welcome to server bloat land.)|
|Reports are treated like documents in a doc library so they can be versioned, workflowed, etc.||No SSRS Report Manager web site. All admin happens thru SharePoint and all reports end up in the SharePoint content databases (because they are really documents in a doc library.|
|Additional software cost. You need to install SSRS and a SharePoint front end into the farm in integrated mode. This adds one more box (at a minimum) to the farm.|
It really boils down to “Is it OK to ALWAYS access SharePoint to run a report (licensing, load, etc.) or do I sometimes need to access the report outside of the SharePoint environment from a client or system that cant/won’t talk to SharePoint?”
If the answer is its ok we can access ALL reports thru SharePoint then I would go the SharePoint route. If your organization needs to consume reports in client applications and treat reports as a service consumed by other applications then I would go the native route.
With all this in mind nothing stops you from doing both…….