Using URL parameters with Mobile Reports in Reporting Services

image

One area I’ve found folks looking for additional information recently has been how to use URL parameters with Mobile Reports in SQL Server 2016 Reporting Services.  This was a fairly popular feature in Datazen, so naturally people want to use it in SQL Server 2016 as well.

Quick background for folks who don’t know what URL parameters are in the context of mobile reports.  You can create a mobile report with parameters in SSRS 2016 so you and your report readers can filter your reports.  This is helpful when you have a large dataset, for example, so not all the records are loaded at once (If you aren’t familiar with how to write a shared dataset query with parameters in Reporting Services, you can learn more about that at this link – https://msdn.microsoft.com/en-us/library/dd239345.aspx).  Sometimes, you’ll want to provide those parameters as part of the URL for the report.  This can be useful if the report is a drill-through target from another report you’re viewing, for example.

First off, there is support for this feature.  You can find documentation on MSDN for it here – https://msdn.microsoft.com/en-us/library/mt772301.aspx

The article, however, only covers the basic scenario around using a dataset parameter.  Dataset parameters are passed on to the shared dataset that they were specified for when you created the mobile report. The parameter name must be specified as:

<Dataset Name>.<Parameter Name>

Below is a sample URL for supplying a value for the @Reqtype parameter of for an ExecutionLogs dataset:

http://rsserver/Reports/mobilereport/ExecutionLogs%20with%20Filter?ExecutionLogs.@Reqtype=Subscription

There are also parameters that are tied to the selection state of the control in the mobile report it was specified for.  These can be thought of as selection control parameters.  An easy way to find the name of the selection control to use in your URL is on the “Set drillthrough URL” screen in Mobile Report Publisher.

image

Like dataset parameters, the parameter name must specified in the following manner:

<Control Name>.SelectedItem
<Control Name>.SelectedItems

Below are sample URLs for specifying these:

http://rserver/Reports/mobilereport/ExecutionLogs%20with%20Filter?SelectionList.SelectedItem=Subscription

http://rsserver/Reports/mobilereport/ExecutionLogs%20Multi?SelectionList.SelectedItems=Subscription,Interactive

A special type of selection control in Mobile Reports is the Time Navigator control.  The time navigator control supports the following properties you can set in your URL –

– SelectedStartTime
– SelectedEndTime
– ViewportStartTime
– ViewportEndTime

The values for these properties are date time values formatted like this – “2017-02-15T00:00:00”.

Please Note: the “:” character needs to be URL encoded as “%3A” (browsers will usually do this automatically for you).

Now please read carefully the following item, because here’s where folks often run into trouble – if a user specifies a dataset parameter value via the URL and there is also a selection control wired up to supply values for the very same dataset parameter, a conflict occurs. The mobile report resolves this conflict by applying the dataset parameter value supplied via the URL (and discarding the initial selection control value). Note that this is true even as the user starts interacting with the report and chooses other selection values!

You can easily avoid this by supplying a selection control parameter via the URL instead of a dataset parameter.  The MSDN article is being updated to reflect this information as well, but keep this in mind when you are designing your mobile reports.

Finally, there is an item you can apply to your entire report via URL, and that’s to enable/disable showing the report title.

To disable the title, simply add “?title=false” to your URL, so it looks like the following –

http://rserver/reports/mobilereport/Claims%20Trends?title=false

If you want to show the title, just don’t add this to your URL.  Simple enough, right?

Hope this has been helpful for you and helped clear up a few things on this topic.  I want to give a special thanks to Andre M. from the engineering team for helping me with this blogpost.