Questions about using RS in a web app
-
With Ray's help, I've got my first Reporting Services project onto a server where it can be used. (YEAH!)
First major question dealing with scheduling reports to be printed.
Now, we would like to be able to use this report in 2 ways. First, we want to be able to schedule it to run once every two weeks and generate a report. Is that done through the http://servername/reports website? (I'm sorry, the book I'm using doesn't really help me much.)
Second major question dealing with how to access Report Services reports from an ASP.NET application.
Additionally, we also want to make it possible to use this report in an ASP.NET 2.0 web app. This leads me to ask two questions about it. First, we've put the new RS report on one of a SQL Server server that is behind our firewall. For confidentiality reasons it is not a good idea to make this report available online - it must be in a secure environment where a user is both authorized and authenitcated to be able to use it and what data they can use. So, the question is can the ASP.NET application access the RS app via it's URL and display the data/HTML to the user, even though that server that hosts the RS reports is behind the firewall?
Second, how do you access RS reports on a server's SQL Server Reporting environment from an ASP.NET application?
Kindest Regards, Rod Connect with me on LinkedIn.
-
Yes, you can access the report through a URL (I'm attempting to answer your second question) programmatically. The actual URL that your application uses can contain all necessary parameter values, so that your application can request these things from the user and construct the full URL on the fly. (I'm telling you this in case your RS report has any such dynamic behavior required, since I can't tell from your question).
It is quite common, in fact, to create a proxy this way (no need to explain why the RS app should not be exposed outside the firewall, IOW).
*HOW* your ASP.NET application performs the HTTP request (the second part of your second question) is, first, it constructs that URL we just discussed. It should have a configuration setting, or more than one, telling it what internal server to address the URL to (IOW: you don't hard code this).
The ASP.NET app should also be configured to address the request using an identity that has rights to the report on the internal RS server -- how you set up the ASP.NET application with this information about the identity depends on how you've configured RS, and whether the ASP.NET app uses impersonation, etc. But probably the easiest way would be to make the ASP.NET application run under an identity that is also a member of a group that has rights to the report in RS.
Now you're just left with how an ASP.NET application performs a programmatic HTTP request, receives the results, and makes those results what it displays to the user. Um, are you an ASP.NET programmer or do you have access to one at your organization? Because these are standard problems.
You might want to look at the WebClient or HttpWebRequest class. You will also need to look at various Credentials features, but again how you do this will depend on how you have the ASP.NET application set up in general.
HTH,
>L<
-
Hello Lisa,
OK, I've been experimenting and I am really not getting this. It might be best if I work through an example.
Let's suppose my report is called ProviderData. It has 2 parameters: ProviderNumber (a short, i.e.: 2-byte signed integer type), and NumberOfDays (another short) and a bit field, which I specify as a Boolean. I have tried the following:
http://myserver/reportserver/ProviderData?ProviderNumber=89&NumberOfDays=45&Shownames=True
and that has failed. I got into Reporting Services manager and tried to figure out what the URL might be from that. I got the following:
http://myserver/Reports/Pages/Report.aspx?ItemPath=%2ProviderData%2ProviderData
Since I wanted to pass in parameters in the query string, I then added them like so:
http://myserver/Reports/Pages/Report.aspx?ItemPath=%2ProviderData%2ProviderData?ProviderNumber=89&NumberOfDays=45&Shownames=True
but that also failed.
So, given my report's name, how do I specify the URL so that I can access it from another application?
Kindest Regards, Rod Connect with me on LinkedIn.
-
i'm not sure I can debug this from your example, because a lot would be determined on how you had installed RS on the server, I guess... but I'll give it a go. First: I don't think that your problem is necessarily the "access from another application part".
IOW, I'm not sure - and can't tell for sure - whether your base URL is correct. It might be something like this:
... where the doubled ProviderData after the questionmark represents the application folder/path (ProviderData) followed by the report name (also ProviderData).
Notice that this is not a name-value pair (item=value) in the query string, but the literal path; I'm doing this because it works, not because I know why it would be this way <s>. I got the idea from drilling down into my reporting setup via the report browser mode and seeing what *it* used. There may be other ways but this seems to work pretty well for me.
I got the idea from drilling down directly from http://myserver/ReportServer and seeing what it used. Note this is *not* the "report manager" interface or http://myserver/reports (I'm using what I hope are default values here). http://myserver/ReportServer looks like browsable directories, not ASPX pages.
When you go directly to the report doing this, you'll see a URL that will look similar to what I've provided above (minus the params and their values), and you'll see input items for your args. At least, I do. The URL you'll see will include a final instruction that will look like this:
... which you will not want to use when you're passing the URL yourself; you'll replace that part of the query string with your args as name-value pairs.
Following the path information in my example, I've added ampersands and your three arguments as you showed them (or that's what I meant to do and hope I have done clearly enough for you to see it <s>
. To be honest I have not used booleans as arguments; I tend to provide them as 0-1 to avoid any case sensitivity or other casting difficulties. With that caveat, I don't see anything wrong with your parameter syntax.
NB: I provide this type of information to end users so that they can get directly to their favorite reports with their favorite selections in place; that's why I say it isn't necessarily an application-to-application difficulty. The appropriate URL should work no matter what user agent is calling it and no matter what type of HTTP request code does the actual call. Once you derive the *right* URL, if you have additional "from an application" issues, this is usually a rights issue, not a question of the query string syntax. OK?
HTH,
>L<
-
I've got a follow-up question about this. The ASP.NET application uses SSL, and the Reporting Services report is on a different server, behind our forewall. When I ran the report from home (outside of our firewall). it could not bring it up the data/report in the IFRAME, and I am sure it is because the RS is on that separate server behind the firewall.
So, is it possible to use RS on a server behind a firewall in an ASP.NET application that can only be reached by SSL?
Kindest Regards, Rod Connect with me on LinkedIn.
-
You haven't really explained anything about your ASP.NET application or where it's situated on your network. But the fact that it "uses SSL" doesn't change anything in the equation, or shouldn't.
If I understand what you're doing correctly, the ASP.NET application is available externally. It is then going to query your RS by facing internally, and as I think I explained earlier, when it turns around to face your RS server, it is going to be probably using a Windows network identity that is completely distinct from the original request that was made to it (the request that the external user made to the ASPX page). It is a *proxy* for the external user when it makes this request.
Having made its internal request, with whatever identity it requires to make that request of the RS server, it is going to display the information that it has received to the external user.
I don't see what the display being in an IFRAME has to do with it; I wouldn't make a particular display type some sort of requirement for the architecture. For example, suppose that sometimes the external user would prefer the report data as XML, other times as a TIFF or whatever... The ASP.NET application may also provide an option to the user for him/her to enter an e-mail address, and have the TIFF delivered that way.
If none of what I'm saying is making sense to you, I have misunderstood your scenario... this is all pretty general information, based on what (I *think*) you are trying to do.
>L<
-
Hi Lisa,
I'll try to be clearer. The ASP.NET application is on our web server, and that server is the only server outside of our firewall, so that it might be used by our business partners (it is an extranet, if you will. It isn't meant to be used by anyone on our network.) The server with SQL Server 2005 and Reporting Services, is a separate server behind our firewall.
What I think is causing the problem is that, for example, the web page serving up the report to the outside world would look something like this: http://www.ourcompany.com/RsPage.aspx However, the URL to the report in RS on the SQL Server server, is something like this: http://OurSQLServer/reportserver?/MyReport/MyReportSub&(some parameters go here) which I am sure is not visible to the outside world. I believe that is why the report is not showing up in the IFRAME on the RsPage.aspx page. Now, if I am wrong about that; if it is possible for the RsPage.aspx in our ASP.NET application to run the report, get the result back and we can use that in the IFRAME (or whatever else, I am just using an IFRAME in this case to prevent the user from seeing the parameters, which I've left out) and allow the user to interact with the navigational elements of the Reporting Services report so they can go to the next page, previous page, last page, first page, export, etc and yet not have access to the SQL Server server, then great! If that is possible, how is it done? If there are some sort of permissions or privileges I need to give to ??? in order to make this possible, then where and what privileges are they?
Kindest Regards, Rod Connect with me on LinkedIn.
-
'Scuse me, Rod, but I understand why your ASP.NET server is outside the firewall, I do understand the purpose of separating out these functions, working with partners, etc. I am not sure *you* understand what a proxy is, as I have been suggesting you use it.
I did not suggest that your method of satisfying your requirements would be to expose the internal SQL Server/RS Server's URL via the ASP.NET application. Nor did I expect that the way your ASP.NET application would expose the report would be via putting this URL into an IFrame. (If you want to do this, see below, it just was not what I was talking about...)
I suggested that you would *programmatically* post "backwards" into the RS Server, that *IN CODE* the ASP.NET *application* would post a request to the RS Server. It then turns the result around (re-purposes what it receives from the RS server) to display a result to the external client.
I suggested you look at the WebClient and HttpWebRequest classes. Instances of these classes will be doing the posting, and they will supply whatever credentials you have allowed on the RS Server for this purpose, as part of the post/request.
In no way is this the same thing as using an IFRAME "just to hide the params". Nor is it showing the RS client interface (first page/last page) directly to your external client via the ASP.NET page. A proxy is a proxy -- your web page would be supplying its own navigational capabilities, interpreting them correctly, and doing a lot of extra work, as needed to substitute for the RS client interface.
If you want to supply direct access to your RS Server to a partner via a web interface, via the RS client component, and if your web interface is on an SSL connection, then perhaps you want to provide appropriate log-in security in the ASP.NET application to your partner. I suppose it might work to surface the RS client interface in an IFRAME ... In this scenario, there is no proxy, but the ASP.NET application still has to run using an identity that has access to internal resources, or with impersonation of an identity that has access to internal resources.
Again, are you an ASP.NET programmer or do you have access to one? This is a security issue, so it isn't something you should just try to circumvent cavalierly, it needs to be planned properly by people who understand how your network is set up and what is best in that set up. As I said in my first response to you, I don't know and don't want to guess. A proxy approach is more work but puts in a layer of indirection, so it's safer than just punching a hole through the barriers...
>L<
-
Hello Lisa,
I'm am home now, thus the different "handle" (at work I use "Rod at work"; at home it is "Doctor Who").
I'm sorry, I did not mean to offend. I thought when you said, "You haven't really explained anything about your ASP.NET application or where it's situated on your network." that I wasn't being clear at all. At least it appeared to me as though I wasn't. All that stuff about SSL was irrelevant, so I got pretty basic in my description as to what we're doing with the website, etc.
I'll take your response, especially with the WebClient and HttpWebRequest classes and investigate them.
You asked if I had access to an ASP.NET programmer. Where I work, I am the ASP.NET programmer, or at least one of three. One of the 3 is our supervisor, and he does very little programming. The other is not very good. (The other day I caught him putting C++ code into HTML, and getting confused by the fact that it wasn't working. I told him it just won't, that he had copied the C++ code from off of the Web somewhere, and it won't work in HTML.) So, basically, I'm it. I do the best I can in an environment that doesn't support me and with really legacy (a lot of VB6 code) code that requires constant attention. This results in little time to really devote to researching, and learning, things as thoroughly as I should.
I really appreciate your thorough explanation/response. I hit a nerve, and I am really sorry about that. I didn't mean to, and I ask your forgiveness.
Rod
Doctor Who -
Well, Rod, I'm sorry to hear that your environment doesn't support you... and you didn't hit a nerve except maybe for the one that says "didn't I explain all this in the FIRST message I sent in this thread??" <g>
AAR you don't need my forgiveness!
But, let me be clear about this, if your experience is limited and your resources are also limited, this would be the *worst* time for me just to give you some easy way to obviate all security restrictions and find some way to tunnel through, to do what you originally had in mind.
I thought as much, when I read *your* first message... and this is one reason I suggested a proxy approach in the first place. I do understand that it is an extra layer of code (or perhaps two) and more work. But it's safer.
BEGIN RANT
Believe me, if I am truly irritated at anything or anybody in all this, it isn't you! It's the promise made, somewhat thoughtlessly and facilely made IMHO, that RS is just going to make all of this complexity go away without attention to detail and security. If you have been led down a garden path in this department, that is certainly not your fault.
I am irritated by easy demos and wizards where things "just work" but if you so much as sneeze on the process you uncover gaping holes and deficiencies in products.
I guess I am also irritated by the idea that it doesn't take knowledge or understanding to build complex things, just drag and drop and you've got it made... but even if you've internalized that idea, I don't blame you for it. It's all over the place...
I've been reading a number of technical threads in which people insist that it "should" not be so hard to do something, that users "won't stand for it", we have to make it all simple. Well, okay, noble goal but... some things are hard and take professional qualifications and training.
[Even if Boeing came out with some airplane that theoretically didn't take any skills or training to fly, and did some demos to prove it... would that make me trust anybody with the money for an airplane to pilot me across the ocean?]
END RANT
Sorry for snapping at you earlier and sorry that I'm old-and-crotchety on this subject (and probably others). I should add that one of the reasons I've enjoyed SQL Server Central is a relative willingness to deal with detail, and the reality of complexity, that I've found in these forums.
If you are willing to continue to work at this and if I can help, I certainly want to do that -- and I'm sure there are other people who want to encourage you, as well.
Here is some information that should help you:
http://blogs.msdn.com/tudortr/
... you may wish to concentrate on the following entry:
Posted Thursday, November 03, 2005 1:16 PM by tudortrDeploying Report Manager on an Internet-Facing Web Server
I have seen a lot of questions on deploying Reporting Services in an internet facing configuration. In SQL Reporting Services 2005, this is easier than in the previous version, but still not as seamless as we would have liked.
In SQL Server Reporting Services 2005, you can install a report server and Report Manager on separate computers. For example, you can install report mananger on a internet facing machine, and report server inside the firewall.
This will help you see how to do the setup, if you don't want to create a proxy viewer and feel confident about the network issues involved in your environment/with your network staff.
BTW, which is the earliest Dr. Who you remember???
>L<
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply