Category: Mobile Reports Publisher

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.

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.

Happy Saturday to all!

As you may have noticed, I haven’t posted on my personal blog in some time (although I have been posting over at the SQL Server Reporting Services team blog fairly regularly).  If you’re wondering why, just watch the presentation Riccardo Muti gave at Ignite this past week, where he showed an early preview of publishing Power BI Desktop reports to SQL Server Reporting Services.  We’ve all been extremely hard at work on that, but with the (undefeated) Philadelphia Eagles off this weekend, I wanted to take some time to do a “catch-up” post where I touch on a number of topics.

1. There is a new version of the SQL Server Mobile Report Publisher now available for download.  I am planning on doing a post on the official team blog about this (and yes, it will list all of the changes that were included in the release), but I wanted to bring one item to your attention that was addressed in this release since this was something multiple customers asked us to address –

– Dataset column names should be made more presentable before displayed in mobile report

Previously, if you had column names with underscores in your dataset, there was no way to remove those underscores or show a user friendly name for your report.

Now, when you create a mobile report, you’ll see that we now hide the underscores when presenting the column name in the report.

You’ll also need to install the latest cumulative update for SQL Server 2016 to make sure mobile reports you create and view on the server reflect this change as well.

2. A number of people had been looking for ways to more easily build custom brand packages for SQL Server 2016 Reporting Services.  A new third party tool is now available on CodePlex called the SSRS Branding File Editor that lets you use an Excel template to do everything around that process.  Folks who’ve tried it have let me know they’ve found it quite useful, so I’d encourage you to take a look.

3. We recently released an update for Report Builder (that I wrote the blogpost on) where we alluded to some improvements that were related to shared datasets.  These should help significantly with shared datasets built against SQL Server Analysis Services data sources for your Mobile Reports, especially if your datasets have parameters in the query.  However, because a few of these fixes also required some updates on the server, you won’t be able to take advantage of all of them until we have our next server update sometime later this year.

4. I pulled together some of the custom map shape files previously found on the sample Datazen dashboards, including the jumbo jet and stadium map files.  You can download these for use in your mobile report projects if you’re interested.  As usual, these maps aren’t officially supported by Microsoft in any way.

5. One of the pieces of feedback we’ve gotten recently is folks asking about the documentation for Mobile Reports and KPI’s in SQL Server 2016.  While the best place to get started for this is the MSDN documentation, it sounded like folks were looking for more advanced topics as well.  Feel free to leave me a comment if there is a specific topic or walkthrough you’d be interested in seeing a post on, or even having it added to the MSDN documentation.  I can’t promise I’ll be able to tackle every topic right away, but I’d definitely would like to.

Hmm – I wasn’t planning on focusing just on mobile reports this post, but that’s how it turned out.  I guess that means I’ll just need to do a part 2 of this post as well.  Until then, enjoy the rest of your weekend!