• 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

To achieve this functionality we need to use the Navigate to URL option in our report Navigation properties and we need to provide a javascript link to our target report.

Through using javascript we can pass parameters to the targeted URL and we can also choose how to display the targeted page. In example, to open a simple html page the javascript code we need to use in our Navigate to URL expression is:

 

In this simple example we provide the javascript expression as a simple string without passing any report parameters or fields as page parameters. The result of clicking on our report link will be opening a new pop-up window, which will then display the html page at the specified address.

 

First, lets explore the target javascript parameter. _blank means that every time we click on the link, we will spawn a new pop-up window. If we supply _parent as a value for the target parameter, javascript will pass the URL to the current window and will render the html page in the already open browser window, thus allowing us to replace the content of the current tab/window with new content. Another option is to provide a custom javascript property:

 

which will result in opening a pop-up which we can reuse afterwards from any javascript link. If we have more than one javascript link on our report and we want to open some or all of those in the same pop-up window, we can name our target windows and then use the name in multiple javascript links, which then render their target pages in the same pop-up.

Furthermore, we can specify other javascript properties. An example of using some of these is:

 

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.

 

To form the URL we can either point to Report Manager or to the Report Server directly. Pointing to Report Manager will display the report with the report manager wrapper, which is in most cases not required. Supplying the Report Server URL results in rendering only the actual report in the javascript window. To form the ReportServer URL we need to supply the full path to it and the report. An example of a complete URL is:

 

or as a part of a javascript pop-up expression in Reporting Services:

 

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:

 

the & character will be interpreted as a concatenation between parameters and the URL will be parsed with this presumption. To avoid this we can use the escape() function in javascript to substitute the ampersand character with its URI value of %26:

 

This way we can pass any MDX or any other special or reserved character through the URL.

In conclusion, javascript in Reporting Services widens our set of tools to tackle difficult requirements in a relatively simple way. The combination of the powerful javascript language and its widespread support and the options that Reporting Services provides for report rendering control through the URL is very powerful and report developers can benefit through exploring both areas.