Outlook Mail Attachment’s from SSRS

It would be naïve to think that The World Wide Web is by any means a “safe” place to be. If I were developing a browser, I would likely do everything I could to protect the public from the outlaws in the Ether.  That being said, there are, on occasion, legitimate reasons to want to perform actions on an Intranet that should never be allowed in the wild.

Recently I was exploring attaching a file created from SQL Server Reporting Services (SSRS), running on an intranet web app, directly to a MS Outlook Email. Using the Outlook ActiveX from JavaScript makes it relatively painless to open up an Outlook E-mail, set the information and attach a file. Using SSRS, the best approach to tackling the attachment seemed to be either stream the file directly into an Outlook attachment or download the file directly (read: without prompts)  to the client and attaching the file.

For those not familiar with SSRS, it has some great features for creating reports and easily exporting them (to PDF, Excel, etc.). There are even alternate ways to access reports in multiple formats, including:

  1. Using the SSRS viewer control, the user has buttons to export as they see fit
  2. In code, one can use the viewer to export or save a report programmatically
  3. Direct via  URL/Parameters

There had to be a way, given the flexibility of the service, to solve this problem. The answer: “Sort of.”

I began using a VS2008 report viewer control. This route allowed me to use server-side code to generate the report to a PDF and save it to the client, but this required the user to acknowledge the file download. I then looked at the web services to stream the file directly to a byte array and send it to the client. Almost, but not quite – the user still needs to acknowledge the file download. I tried to use the server control itself to generate a file, but this was saved on the server-side (as expected), and not directly accessible to the client. I also tried WinHTTP to grab the file and save it using FSO but that wasn’t built for binary files, and the ADODB.Stream Object is disabled for access without a registry hack that could cause even larger issues (not to mention not being an easy thing to do on machines in a client’s network).

A little more digging gave me hope when I learned the report viewer in VS2010 had a JavaScript API. This HAD to be the solution! There is, in fact, an ExportReport method but again, the user is prompted to accept the report. Not what I had hoped for.

My final attempt lead me to consider Acrobat automation. While the ActiveX API has many functions, I was again faced with an inability to take a stream and save it to the client without intervention. Strike 100…

If you found your way to this post because you have a similar requirement, hopefully my journey will save you some time exploring these paths. I did come up with a sort-of-work-around thanks to input from the guys around me (sometimes you can get so focused on the tree you forget there’s a forest, too). Assuming your requirement is for an Intranet app, and the users with the requirement and the servers are on the network, you can save the file server-side to a shared network location and attach it from the share. This save the user from a having to intervene and gives them a nice Outlook e-mail with the report attached. As with a lot of solutions, it’s not pretty, but it works…

It’s good to know that not just anyone can download a file to a (read: my) machine without explicit permission but, in this case, there needs to be a way to allow files to be downloaded without notification as long as it has been set as a trusted site. Lock it down as a general rule, but let me decide if I want to (potentially) shoot myself in the foot. With web apps quickly replacing traditional desktop apps, there needs to be a way to set the browser’s security settings lower to enable more full-featured functionality.  I don’t want to have to write a browser plug-in every time I need to do something out of the norm.