SQL Server Reporting Services ships with two delivery extensions: one to deliver reports through email, and one to deliver reports to a shared network drive. A third extension to deliver reports to a printer exists in the SSRS samples directory.
One day I was setting up an email subscription and a thought occurred. Delivering reports to a blog instead of to a company email alias would be ideal. Instead of sitting in a slew of inboxes, a new delivery extension could post these reports with the blog’s web service API and intranet users could easily comment on and link to the report. Anyone needing the report subscribes to the blog with an aggregator and knows when a new report is ready.
I learned quite a bit and have quite a number of tips to share about the experience, but I’ll have to save those for future posts. Implementing, deploying, testing, and debugging a reporting service extension involves a little more work than I initially suspected. It looks easy in theory (just implement these 3 simple interfaces!).
In the meantime, you can look at the source if you dare. It has no warranty, no guarantees, contains liberal amounts of TODO comments, and comes with no installation instructions (yet).
On the plus side, it does work on the simple reports I've tested so far. I have not tried reports with images, I suspect these are going to pose a problem. I just finished adding DPAPI calls to keep the blog user's password encrypted in the ReportServerDB, and the next step is to look at the fancier reports.
Feedback and criticism welcomed.
If you find reporting to be a boring subject, then I'm sure you won't download the code, and won't offer any feedback, because you've already stopped reading this.