1. A topic that often comes up is “Can I pass parameters via URL to my mobile reports?” This answer is yes, however, there is something I wanted folks to be aware of when they use this functionality.
The linked article I referenced covers how you can do this with a dataset based on a SQL Server Analysis Services MDX query, but it doesn’t currently say that it only covers that scenario right now. We’re updating the article to show the difference for how the URL needs to be formatted for SSAS and SQL based data sources, which I’ll also cover here. In the following screenshot from that article, you’ll see the parameter we want to pass is for the Category column in the TimeChartLoD dataset. So depending on what the data source is, for step 4 I’d need to format it two different ways –
If it’s based on SQL Server, then it requires the @ sign before the column name, and would look like this.
If it’s based on Analysis Services, then no @ sign is required, and would look like this.
That (hopefully) clears up the confusion on that point, and again, you’ll see that article updated with this additional detail in the next few days.
2. While we’re on the topic of parameters, one item that tends to trip folks up is around using user-based parameters to enforce row-level security. This usually happens because unlike other parameters for mobile reports, you don’t need to use a dropdown list in your mobile report to pass this parameter, nor does it need to be called out in a URL. I covered how this works in a blogpost earlier this year that may help with your questions on that.
3. Another question I get quite a bit is around how to setup an SSRS server to allow users access to their reports when they aren’t on the corporate network. There are some blog posts out there that touch on this topic, including one done by Jaime Tarquino (who happens to sit right next to me in the office) that covers using Azure Active Directory Application Proxy to access your mobile reports and KPI’s with the native mobile apps.
Another option you should be aware of is using the Web Application Proxy for Windows Server (both 2012 and 2016) for this purpose. This enables “reverse proxy functionality for web applications inside your corporate network to allow users on any device to access your web applications from outside the corporate network.” I can confirm that this does work for SQL Server Reporting Services scenarios currently that require “browser only” access. While this isn’t currently supported by the native mobile apps (because you need to authenticate using ADFS), I think it’s fair to say it’s something we’re actively looking at supporting as well.
4. I wanted to take a moment to call out the recent blog post by the Visual Studio LightSwitch team where they announce that LightSwitch will no longer be in future releases of Visual Studio. For those of you following this blog, you know I loved that product and used it extensively in my day to day work before coming to Microsoft. I am genuinely sad to see it go, especially since it was responsible for me even being hired by Microsoft in the first place (that story is an entire blogpost of its own). That being said, I have complete confidence in the team working on PowerApps to create a worthy (and superior) successor to LightSwitch. In fact, I’d argue it will offer a far better option for many users who were interested in in tools like LightSwitch but were intimidated by the idea of using Visual Studio to build LOB applications (I saw this firsthand quite a bit).
5. Finally, I’ll be co-presenting at SQL PASS this week along with Riccardo Muti around what’s new and what’s coming in Reporting Services. In fact, I might even be demoing some functionality I know many of you are quite interested in. I highly recommend attending this session if you’re a fan of SQL Server Reporting Services and want to hear (and see) more about what’s coming next.
See you at PASS and have a great weekend!