Printed reports were the norm for decades. When a user wanted to get some important information, they would use their software to print a report and then read it from the page. Today online reports are used to give user access to important information without the need to put ink or toner on paper.
Aside from saving the forests, one of the many advantages of using a report displayed on the screen is that user can interact with reports to get as little or as much information as they need.
Reports with multi-level groups and drill-down actions
Multi-level grouped reports are one of the most fundamental report designs. A natural extension of this style of report has each subgroup collapsed with the ability to click a toggle item to expand or collapse each group to view detail at a lower level.
Using Reporting Services, this is a straight-forward design pattern but it?s not well documented for the novice report designer.
There are also a number of options and decision points when designing multi-level drill-down reports:
Multi-level Grouped Report with Subtotals
Drill-down Report on a Single Dataset
Drill-down Report with Dynamic Details
Embedded Drill-through Targets
I spend a good deal of time answering questions and moderating the Microsoft Developer Network (MSDN) forum for Reporting Services. New SSRS users tend to use different terms inconsistently to describe report design elements and concepts. For example ?I wan to click a drill-down link to open a subreport in a new window to view the details for the item I clicked on.? Although this probably makes sense to the user who wrote it, it may not make sense to those familiar with standard Reporting Services concepts. Before we can discuss these design concepts, it?s important that we?re on the same page, using the same words a phrases to describe the same concepts. Our discussion in this article is limited to designing reports using a table data region.
A table data region can have one or more row groups. A group may be created by dragging a field into the Row Groups list in the lower-left area of the report designer while the table is selected. A group may optionally have numeric subtotals in the group header (above the details) or the group footer (below the details.) Each group has one or more group field expressions. A tables with two nested groups might have sales records grouped first by the Year and then subgrouped by the Month.
This example uses a table data region with grouped rows. The drill-down functionality in the next section will work just as well with a matrix style reports with column groups.
The levels or details within a group may be hidden from view until the user clicks on a drill-down icon next to a toggle item. Using the prior example, the aggregated sales for each Year are visible until the user clicks the [+] before a specific year value. This expands details for that year and shows a row for each Month. Likewise, each month shows a [+] which can be used to expand the details for that month and to show individual detail rows. The year is expanded to show related months and then the month is expanded to show sales details for each product category.
Beyond the basic drill-down report design, where a multi-level grouped table has group header rows which may be expanded and collapsed using a toggle item, certain details could also be hidden and shown using a toggle item as well. For example, a product name could be displayed in the detail row with a toggle item used to show a description or order details.
The name of a report item existing in a row at a level above the current group. In typical reports, a toggle item is a textbox in the header of a parent group used to expand (show all) or collapse (or hide) a set of rows. By default a plus or minus icon is displayed to the left of the toggle item to indicate the expanded or collapsed state. When a user clicks this icon, the plus icon [+] is used to expand the level and the minus icon [-] is used to collapse and hide details in the lower-level group for that parent value.
A type of report action that navigates from a specific report item to a different report. Optionally, one or more field values in the context of the current row are passed to parameters in the target report to filter records related to the row or item in the source report. By default, the target report is displayed in the same browser or viewer window as the source report. Optionally, the drill-through target report can be displayed in a secondary window. In HTML report rendering, drill-through is implemented using a hyperlink and anchor tag to navigate to the target report. A drill-through report may be implemented using a Report action or a URL action; using an expression to specify the server path, folder name, report name, parameters and optional query string commands.
The report containing one or more report items having a Report or URL action. A user navigates from a source report to a drill-through target report.
The report that a user navigates to in a drill-through Report or URL action. Any report on the report server may be used as a drill-through target using a relative folder path. When using Business Intelligence Development Studio to design a Report action for a textbox or other report item, all reports in the same project (which are deployed to the same folder) are listed as available target reports.
In Figure 3, a target source report contains a table data region. The textbox for the Year field has a drillthrough action that opens a drillthorugh target report. The corresponding Year field value is passed to a parameter on the target report that filters data in the query for the specified year. In this example, product category sales for 2004.
A subreport is a report embedded inside another report. Subreports can simply be independent reports or master/detail reports that show detail records related to a group header or master record. Independent subreports are often used to display standardized header and footer information, such as legal statements and disclaimers. To filter and correlate master/detail records, the subreport should be designed with parameters used to filter records in each instance of the subreport related to the master record in the parent report. The parent report in the report designer which shows a dark gray placeholder labeled with the path and name of the child subreport.
The second instance of the subreport is called-out, which displays subcategory sales details related to the Bikes category.
One of the advantages of using a subreport to display master/detail records is that each report is based on a separate data source and dataset query. As such, this technique may be used to federate and correlate related data from two different data sources. Even the database platforms and query languages can be different. Conversely, one of the disadvantages of this technique is that by opening multiple data connections and running separate queries, report processing may be slower and less-efficient. However, if the data truly resides in different locations and in different database platforms, this may be the best method to bring it into a single view. Subreports are also one of the more challenging report elements to render or export into different formats with the same fidelity as a single table or matrix.
If you have created multiple drill-through reports, you know that the report navigation works in one direction and that some users struggle to find the best method to navigate back to a previous report. The report toolbar contains navigation controls including a Back button for the previous report in a chain of linked reports but many users don’t find this intuitive. A common user experience paradigm in many well-designed web applications places a series of hyperlinks at the top of a page indicating both the path that brought the user to the page they’re viewing and a path for navigating back to any page along that path. This is a breadcrumb trail of hyperlinks. Reporting Service provides a means to navigate to any other report deployed to the server but it does not have any type of HTML report item that would allow you to build a series of embedded hyperlinks or anchor tags.
This technique shows you how to build a series of breadcrumb hyperlinks that will allow your users to see where they’ve been and to navigate back to any report along the trail.
Reporting Services 2000
Reporting Services 2005
Reporting Services 2008
*The example used in this recipe is based on SSRS 2008 but this technique will work in earlier versions.
What You’ll Need
Series of reports with report navigation actions
Report parameter used to track the breadcrumb trail
Custom code function to build an ad-hoc query
Dataset used to provide the breadcrumb data
Matrix data region containing textbox report actions
Figure XX-1 shows an example of a breadcrumb trail in the report header of a detail report. Note the progressive drill-through path of reports the user opened en route to the current report.
In the production implementation of this technique, report actions could be implemented using any of the compatible report items, including textboxes, images, a grouped table, matrix, list or chart data points as the report action source object. The purpose of this recipe is to demonstrate the breadcrumb technique and not the complexities of embedded report actions. As such, we will be using a simple textbox on the report body to navigate between sample reports. These reports will not have any data sources or datasets other than the one required for this technique.
Designing the Report
In the end, you will have four almost identical reports designed to demonstrate the technique. You will start by designing one report with the base functionality for all reports and then create three copies of this report, rename them and make the necessary modifications.
1. Create a new report named Breadcrumb Report 1.
2. Drag and drop the report name from the Built-in Fields to create a title textbox and style the report header as you typically would with a large, bold font, horizontal line, etc, as you see in Figure 1.
3. In the report body, about an inch or three centimeters below the line, add a textbox to use as the report action source object. The user will click this text to navigate to the next report. Add some appropriate text to this textbox to indicate that it’s a link to the second report.
In a more sophisticate production report, this textbox would be replaced with other report items or data regions with appropriate report actions.
A report parameter is used to pass the report navigation history to the target report. With each new report in the navigation chain, the name of that target report will be added to a comma-separated string passed in the parameter. This parameter will only be used internally and not shown to the user.
4. Add a report parameter named CallingReports.
5. Set the parameter to accept a Null value and set the visibility to be Hidden.
A dataset query will be used to drive a matrix data region to contain the report links. This query will be built using an expression and custom code function. Before we put this part into place, we must create a static query to generate the metadata for the dataset. This dataset will not actually consume any real data but a dataset must have a valid data source, And of course a data source must have a valid connection string to satisfy this requirement.
6. Create a new dataset and name it LinksQuery.
7. Any valid shared or embedded data source may be used for this dataset because data will not actually be read from a database. Create or select a data source and select any local or remote server and any valid database. I’ve used the localhost server and the Master database in this example.
8. For the query, type:
SELECT Null As Link
This is only a temporary placeholder to generate a field object named Link. The actual query string will be generated in a custom code function and expression.
A Matrix will be used to display each of the report links, each separated by a right angle bracket, >. Only the column header cells will be used in the Matrix.
9. Add a matrix data region to header area of the report body.
10. Drag the Link field to the Column Groups list to create a new group and group header.
11. Add a new column to the right, inside the group.
13. Right-click in the header cell for this column and add the following expression:
If you are using BIDS, the easiest way to add copies of a report to the project is to select the first report in the Solution Explorer and then use Ctrl-C and Ctrl-V to copy and paste a new file, then rename it. In Report Builder 2.0, use the Save As? feature to save copies of the file to the same folder as the original.
31. Modify each reports so that the report action targets the next report in the sequence and the last report back to the first.
The Breadcrumbs Report 2 report action should navigate to Breadcrumbs Report 3. Breadcrumbs Report 3 should navigate to Breadcrumbs Report 4, and Breadcrumbs Report 4 should navigate back to Breadcrumbs Report 1.
Preview the first report and click the link to navigate to the second report. Continue to follow the links on each subsequent report and note the accumulated breadcrumb links in the report header. Click any of the links to navigate to any of the reports in the series.
Several variations are possible. This technique will display one link per distinct report. If the user were to navigate from Report 1 to Report 2 and then back to Report 1, A link for Report 1 would be displayed only once. Adding another parameter to capture the current date and time for each drill-through would provide a mechanism to group on each duplicate report and to sort the list in the order of navigation.