Do you know if it is possible to do interaction with SSRS? IOW, can I use a button (or a link) in an SSRS report which, when clicked, will post back to the server (for example, send some data to the server and save)? I assume it can’t, but I want to listen to your suggestions…. <\/p>\n<\/blockquote>\n
Well, it’s heartwarming that he’s willing to listen to suggestions and I hope he’s also willing to roll up his sleeves! The important parts of my answer are:<\/p>\n
- \n
- It’s definitely possible to do this. I do it a lot (and I’ll show you an example here).<\/li>\n
- There’s some important work to do to achieve this, but the important work is not really done in SSRS at all!<\/li>\n<\/ul>\n
To understand why, what, and how, you need to take a step back.<\/p>\n
Web services methods of access: start with SSRS as an example server.<\/h2>\n
In various posts on this blog, I’ve shown you how to access Report Server using SOAP — here’s a sample post<\/a> — and also using URL access, which most people would call RESTfull interfaces — numerous examples, here’s one calling SSRS with URL access from within SSIS<\/a>. <\/p>\n
Why do you suppose the Microsoft team supports two APIs?<\/p>\n
The answer should be obvious: different clients have different abilities and prefer different methods of access. If you support multiple methods, you support more clients.<\/p>\n
SSRS is a “differently abled” web service client.<\/h2>\n
I would like to think that Microsoft would have done this on general principles and because the more widely you support clients, the more widely you’ll be used. It’s just good manners and good sense. <\/p>\n
But the truth is that Microsoft probably had an ulterior motive here. By internal inclination they would have supported only a SOAP API. <\/p>\n
I’m guessing about this, I have no inside information, but it’s pretty obvious given the extensiveness of their SOAP API that it was the darling of their hearts and URL Access is the red-headed stepchild.<\/p>\n
They tacked on URL access to their feature set because somebody probably asked “what if we want to call a report from another report?” <\/p>\n
“Hah”, MS said, “we’ve already thought of that. There’s an ‘action’ option to go to another report.” <\/p>\n
But that same somebody probably perserved. “Not good enough! What if we want to call another report that’s on another report server? You’ve allowed us to put links on text with an action to ‘go to a URL’, and you’re rendering our reports in an HTML interface in Report Manager. We want to call Report Manager or Report Server” — most people at that stage didn’t even know the difference — “from inside another report! And it should be as flexible to do this as to call any other web site!”<\/p>\n
“Hah”, MS said, “no problem. Just look at the URL for the other report in your browser, capture it, and put that into the action.”<\/p>\n
But that same somebody probably stuck to his or her guns. “Not good enough! What about the parameters, and what about the other options such as rendering to another format?”<\/p>\n
OH. <\/strong><\/h2>\n
And finally MS understood what was needed. <\/p>\n
They added URL Access as a method of using Report Server… because RESTful interaction was the only type of interaction that SSRS Reports themselves would be able to support as a web service client.<\/strong><\/p>\n
In a country of one-version APIs, the two-API’d server is king.<\/h2>\n
They really should have known from the start.<\/p>\n
It’s really obvious, and if you are a .NET developer rather than a SQL developer you should already know this: When you build a web service you should make it available from as many types of clients as you can. <\/p>\n
Now, back to Tom’s question. The work is really on the server side, not on SSRS’s as a client. To have interaction from an SSRS report, he needs to specify a web service somewhere capable of serving an SSRS client, which simply means a web service that supports some form of REST.<\/p>\n
If his company has any brains, they’ll make sure the same web service can serve other clients, which might prefer SOAP, too. It won’t cost any more to build for both at the same time.<\/p>\n
Here’s how I handle it.<\/h2>\n
As I’ve probably mentioned a nauseating number of times, the district runs a huge number of SSRS reports, and a fair number of them have the potential to allow interaction (I’ll show you one, below). I don’t want to create a new methodology every time somebody suggests this requirement.<\/p>\n
To resolve requests as quickly as possible and as flexibly as possible, I built a small ASP.NET application whose sole purpose is to address the database; it only has one method that can be called, but that method has a bunch of rules, addressable as standard argument by the client, to determine what stored procedure, in what database, using what connection string, the web service method will call internally. <\/p>\n
The method also has a standard argument which allows the client to specify whether it wants to receive an XML result or whether an XSLT stored on the server in a known location — which can be specific to your report, if you like — should be applied before the client receives the result. Your xslt, in turn, has standard arguments it’s passed (such as siteRoot, for use in displaying images).<\/p>\n
A final standard argument allows you to specify whether you are looking for a full result set from the stored procedure, which is provided as an XML-serialized dataset, or a single result value.<\/p>\n
Now for the non-standard arguments. These are like the ones that represent your report’s parameters, when you use SSRS’s URL Access, as contrasted with the ones that tell ReportServer that you want a PDF rather than HTML, etc. In URL Access, you prefix the SSRS-standard parameters; in my system, you prefix the names of the custom parameters instead. In my system, these custom parameters are the arguments you want passed to the stored procedure you’ve requested. You use the original parameter names required by the sproc, prefixing them with a special, documented prefix. The method strips off this prefix when calling the named sproc, obviously, and passes your values along when it invokes the sproc. <\/p>\n
The web service method also error-handles appropriately and provides a consistent method of passing back the errors to the client, whether because the sproc you called doesn’t exist, your arguments for the sproc weren’t correct or the sproc threw some other error, or because the sproc in question has not been cleared for this type of access. If you supply a custom XSLT in this system, naturally, there are some additional conventions your XSLT can support so that it displays error messages in conformance with its general UI requirements.<\/p>\n
It sounds complicated, but it’s pretty simple to do, especially when looked at from the client’s side, in this case SSRS. Here’s how simple the XML version accepted by this service looks, appropriate to being sent by a SOAPy client:<\/p>\n
<SISXRequest>
<\/span> <p<\/span> n<\/span>=”<\/span>_sp<\/span>“>sp_<\/span>xxx<\/span><\/p>
<\/span> <p<\/span> n<\/span>=”<\/span>_cn<\/span>“>yyy<\/span><\/p>
<\/span> <p<\/span> n<\/span>=”<\/span>_db<\/span>“>zzz<\/span><\/p>
<\/span> <p<\/span> n<\/span>=”<\/span>_x<\/span>“>my.xslt<\/span><\/p>
<\/span> <p<\/span> n<\/span>=”<\/span>_pLogin<\/span>“>aaa<\/span><\/p>
<\/span> <p<\/span> n<\/span>=”<\/span>_pMyOtherParameter<\/span>“>bbb<\/span><\/p>
<\/span><\/SISXRequest><\/span><\/p>\n… and an equivalent RESTful version of the request above might look like this: <\/p>\n
http:\/\/myserver\/myWebRequestURL.aspx?<\/span>
_sp=<\/span><\/strong>sp_xxx<\/span>&<\/span>_cn<\/strong>=<\/span>yyy<\/span>&<\/span>_db<\/strong>=<\/span>zzz<\/span>&<\/span>_x<\/strong>=<\/span>my.xslt<\/span>&<\/span>_pLogin<\/strong>=aaa<\/span>&<\/span>_pMyOtherParameter<\/strong>=<\/span>bbb<\/span><\/p>\n… an internal process turns the two request versions into an appropriate collection object, exactly the same in both cases of course, and passes that object into the sproc-handler in the engine.<\/p>\n
What’s left for the client to do? Nothing that an SSRS report can’t handle. On the client (RDL) side, the work to be “interactive” now looks like what you see below. <\/p>\n
Here’s one I prepared earlier.<\/h2>\n
In this example, one RDL, showing students’ readiness for college according to some California state university requirements, drills down to another RDL, which provides a list of courses which the student has not yet taken, and which would fulfill some as-yet-unfullfilled requirements for this student: <\/p>\n
![\"\"](\"\/lisa\/wp-non\/migrated\/2012\/8\/EO-1.png\")
<\/p>\n… the second RDL is the “interactive” one. When a counselor helping the student clicks a course number, a Course Request is submitted to the Student Information System for that student, with that course information.<\/p>\n
As you might expect, internally (or at design-time), the second RDL’s clickable link works like this:<\/p>\n
![\"\"](\"\/lisa\/wp-non\/migrated\/2012\/8\/EO-2.png\")
<\/p>\n<\/td>\n![\"\"](\"\/lisa\/wp-non\/migrated\/2012\/8\/EO-3.png\")
<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n![\"\"](\"\/lisa\/wp-non\/migrated\/2012\/8\/EO-4.png\")
<\/p>\n