Dynamically Selecting and Filtering Reports with Blazor and the Telerik ReportViewer Control

The Telerik Report Viewer makes it easy to let your user select the report they want to see and filter the data in that report to get the information they need. Here’s how to make that happen in a Blazor app.

The Report Viewer in Telerik Reporting makes it easy to let your users get the information they need both by selecting the report they want and by filtering the data in that report. Here’s how to make that happen in a Blazor app.

While the Telerik ReportViewer control makes it easy to display reports either embedded in your application/Web Service or fetched from the Telerik Report Server, that’s just the start of the story. Out of the box, the ReportViewer gives users the ability to zoom in/zoom out, download the report in a variety of formats (PDF, Excel, PowerPoint, etc.), and control the page display. But, if you’re willing to add about six lines of code, you can also let the user switch between reports and alter the report’s parameters that control the data being displayed, all without leaving the page.

One of the beauties of the ReportViewer is that it supports identical functionality in all the .NET frameworks (Web Forms, MVC, .NET Core). In this post, I’ll cover the code you’ll use in a Blazor application where the report is kept in a Web Service you’ve created.

Blazor: Selecting Reports

Using the ReportViewer in a Blazor app requires UI markup like the following (this markup displays a report called ContactList.trdp, fetched from a Web Service in the same web project as the report viewer’s page at the relative URL api/reports). As far as this post is concerned, the key point in this markup is the @ref attribute that ties the ReportViewer to a variable called reportViewer in my Blazor code:

<ReportViewer ViewerId="rv1"
    @ref="reportViewer"
    ServiceUrl="/api/reports"
    PageMode="@PageMode.SinglePage"
    ReportSource="@(new ReportSourceOptions()
                {
                    Report = "ContactList.trdp"
               })"
    ScaleMode="@ScaleMode.Specific"
    Scale="1.2" />

In my Blazor code I must declare (as ReportViewer) the reportViewer variable that allows me to access the viewer from my code:

ReportViewer reportViewer;

To support the user selecting a different report from the same service, I load a dropdown on the page with a list of available reports, putting the name of the report in the value attribute of each option element. I also tie the dropdown’s onchange event to a method called changeReport, passing the associated event argument object to the method:

<select @onchange="(args) => changeReport(args)">
    <option value="ContactList.trdp">Contact List</option>
    <option value="ContactListModified.trdp">Contact List by City</option>
    …more reports…
</select>

In that changeReport method, I extract the name of the report from the event argument object’s Value property and use that value to change the report being displayed. To display a new report, I just need to change the name of the report held in the viewer’s ReportSourceOptions object. I can do that by creating a new ReportSourceOptions object and setting its Report property to the name of my report. This code creates a ReportSourceOptions object, changes the name of the report, and then sets the viewer’s ReportSource to that new ReportSourceOptions object using the viewer’s SetReportAsync method:

void changeReport(ChangeEventArgs e)
{
   ReportSourceOptions rso = new ReportSourceOptions();       
   rso.Report = e.Value.ToString();
   reportViewer.SetReportSourceAsync(rso);
}

Now, when the user selects a new report, the ReportViwer will display the new report. As part of displaying the report, the ReportViewer also updates the ReportSourceOptions with the new report’s options.

Blazor: Setting Parameters

Updating the ReportSourceOptions matters because it’s not just the report name that’s held in the options object—any report parameters are also held in the options object. Report parameters can be used in a variety of ways in Telerik reports, but if you’re using those parameters to filter the data in the report then you can support letting the user control the data in the report. All you need is some code like the method that let the user select the report.

For example, I have a report that uses a parameter called City that controls the data displayed in the report. To filter the data in the report I just need to change the City value in the report. However, rather than create a new ReportSourceOptions object as I did when changing the report, I use the viewer’s GetReportSourceAsync method to retrieve the ReportSourceOptions object and then update the parameters held in the object.

As with selecting reports, I first provide the user with a dropdown list of cities to pick from. The markup to do that looks like this (and also ties this dropdown to a method called changeCity):

<select @onchange="(args) => changeCity(args)">
    <option value="Minneapolis">Minneapolis</option>
    <option value="Redmond">Redmond</option>
    …more cities…
</select>

In the changeCity event, I retrieve the viewer’s ReportSourceOptions (which now contains both the report name and parameters), set the City parameter to the value passed in the event argument, and update the report options. Because I’m now retrieving a value from an asynchronous method, I have to use the await keyword on my method calls and flag the method with the async keyword. The changeCity method ends up looking like this:

async void changeCity(ChangeEventArgs e)
{
   ReportSourceOptions rso = await reportViewer.GetReportSourceAsync();
   rso.Parameters["City"] = e.Value;
   await reportViewer.SetReportSourceAsync(rso);
}

In a real application, of course, I’d need more than just these six lines of code—I’d need, for example, to make sure that I only displayed my dropdown list of cities when the report supported filtering by city. But, even so, with these six lines of code, I’ve given the user a lot of control. And that’s always a good thing.