- Pop-ups – when we need to spawn another window for simultaneous viewing of lower level reports, or for displaying a full list of items (such as lists), which could be limited on our main report
- Navigating from a PerformancePoint dashboard Reporting Services report to a purely Reporting services report and escaping from the PerformancePoint layer
- Opening an custom html page (with or without passing parameters to it), which can then provide some additional functionality to our report (e.g. comments, editing fields…)
- Providing a printable pop-up version of our report
For us as Reporting Services developers the more important ones are the width, height, toolbar, menubar and resizable (not resizeable). The toolbar and menubar have slightly different meanings in different browsers. In IE 6 and IE 7 enabling and disabling (setting them to 0 or 1) these result in different browser elements to get displayed, so testing them should be done in all the browsers our users could use. The resizable property allows/disallows resizing (including maximising) the pop-up window.
It is always a good idea to parametrise the URL and to supply the server and the path as a Reporting Services field or parameter to the expression:
which allows us to maintain the report in our relational back-end easing the deployment of our solution to different environment without changing all our reports.
We can also specify Report Server commands in the URL:
These two commands make Report Server render the report without evaluating the item first (improving performance), and also show the report parameters to the user. There is a thorough article on MSDN showing the various commands that can be passed to the reportserver and I will not go any further in explaining these in this post.
We can also pass report parameters to our target reports:
This expression will then pass our Period parameter to the subreport through the URL. We can specify multiple parameters like this:
concatenating them with the & character. Please note that there is a 255 character restriction on the length of the URL, so multi-value parameters can be problematic to pass if the set of values is too large.
Another point to note here is that we should not pass the UserId of our users as a parameter. Instead of doing this we should always capture the UserId of the person viewing the report with User!UserID.Value in each report, which minimises the security risk of someone gaining access to sensitive report data through passing an edited URL to the browser with someone else’s user id in the parameters section.
As a last section I would like to address the problem with passing a MDX expression as a parameter value. In case we have an MDX value such as:
[Business Unit].[Business Unit Name].&[Australia]
This way we can pass any MDX or any other special or reserved character through the URL.