OK let's see if I can explain this one in a way that makes sense...
We are building an ASP .NET application which has a "Pop-Up Reports" menu item which launches Report Manager in a new browser window. The idea is to allow the user to continue to access data in the application and compare that data with data in reports. The user is permitted to have multiple Pop-Up Report windows open at the same time so they can also compare output from multiple reports at the same time.
Users will be able to run the ASP .NET application against different database instances (there is one database instance per client). After they log in to the application they will be presented with a list of the databases they have permission to access. After they have selected a client database, the application will restrict them to accessing information in that database.
So here is the issue. When the user clicks the "Pop-Up Reports" menu item, ideally the reports run via Report Manager will be restricted to running against the selected database.
In the thread "Switching reports between database instances at run time" you can see the solution for having the reports switched from one database to another at run time (which works great). The problem with this approach is it requires the user to pick the database they want to access before they can run the report. Ideally that would not be required and the reports would "know" which database to access.
So what is the best way to accomplish this, if it is even possible
The ASP.NET application and Report Manager will probably be running on different web servers, so they will not share the same session state.
I was thinking when the Pop-Up Report Manager window is opened maybe the new window can be named with some identifier that indicates the database to be accessed. Is there a way that a running report could access that window name so it could parse out the identifier
Of course we could have one Reporting Services instance configured for each client database instance but that is not practical.
We could also have a separate folder and copy of the reports for each client, but again that is a maintenance headache.
We could also build a custom user interface using the Report Viewer control, etc., but we would rather leverage the functionality already provided by Report Manager if possible.
We could also create a Reporting Services user account for each combination of application user and client. user1_client1, user1_client2, user2_client1, etc. The report could then parse the client name from the user name. But of course this means many more users have to be defined, and the ASP.NET application would some how have to impersonate the new user account (userx_clientx) when opening the Report Manager window.
Any other ideas for how to solve this problem would be greatly appreciated.
-- Chris G.
Any clever ideas for associating a Report Manager session with a web application session?
Siebe Tolsma
I was wondering, would this problem be easier to solve if Report Manager were installed on the same web server as the ASP.NET application
-- Chris G.
bri5
Paul,
>>You should use the Reporting Services Web Services.
Please see my reply to your reply in the other post. I think you misunderstood what we are trying to accomplish.
-- Chris
whs45
Rather than launch report manager, you could use the ReportViewer control inside your application.
You can then do either:
1) embed your reports in your application and determine the data source they use by programmatically
2) store the reports on the report server and feed the database to the report programmatically using a report parameter and an expression based connection string (dynamic connection string).
The first solution has the advantage that everything is controlled by your server and the disadvantage of not using additional services like scheduling and subscriptions. The primary advantage is that you know who is the user, what access they have, and you don't have to worry about changing session contexts.
The second solution adds these services but it makes securing your application a little more tricky - you have to pay attention to which users have access to run the reports when connecting directly to the report server (circumventing your application). One solution is to have your application use a standard identity to communicate with the report server, thus preventing users from directly running reports. This of course has some trade offs. you could also prevent users from running reports with certain values of database name in the report parameter by using clever valid values lists generated by a query. Following this approach offers more benefit, but also has increased complexity, so plan accordingly.
Hope that helps,
-Lukasz
swo
See the reply to your other post. You should use the Reporting Services Web Services.
Paul.