Customizing Report Parameters – SQL Reports

In a previous post I described how to customize the parameters in reports that ship with TFS 2010. That post, however, applies to most, but not all of the reports. Most of the reports use the cube, but some of the reports use the warehouse instead, which means two things:

• The queries are written in SQL instead of MDX
• The parameter values will be integer ID values instead of the long MDX names.

In this post I’ll describe how to get the values you need for areas and iterations in your team project so you can customize your reports.

First, here is an easy way to identify that a report uses the warehouse instead of the cube.

Determining if a report uses the warehouse

The instructions here are for SQL Server 2008. The process is slightly different if you’re using SQL Server 2008 R2.

1. Open Report Manager (right click the Reports node in the Team Explorer in Visual Studio and click Show Report Site…)
2. Navigate to and click your report
3. Click the Properties tab
4. Click the Parameters link

At this point you’ll see the list of parameters. The report will be a SQL report if you see a “*” for the default value of IterationParam or AreaParam, as shown here:

The single character “*” in the parameter means that it should not filter, which is displayed as All (No Filter) in the parameter bar.

Finding the Area/Iteration ID

Now that you’ve identified that a report uses the warehouse instead of the cube, you’ll need to find the ID value to use for the area/iteration. This will require some knowledge of the TSQL query language and a tool like SQL Server Management Studio (SSMS) that you can use to run queries.

1. Open SSMS and connect to the SQL Server machine that hosts the warehouse
2. Expand the Databases folder in Object Explorer and click Tfs_Warehouse (this is the default name, but your TFS administrator might have chosen a different name)
3. Click the New Query button

You can then use the following query to find the iteration paths and their corresponding ID values for your team project (just substitute the name of your team project for ‘project name’ in the query):

SELECT IterationSK, IterationPath, ProjectPath, ProjectNodeName
  FROM DimIteration a
INNER JOIN DimTeamProject tp
  ON a.ProjectGUID = CAST(tp.ProjectNodeGUID AS NVARCHAR(256))
 WHERE ProjectNodeName = 'project name'
ORDER BY IterationPath

This query will produce output that looks something like this:

Simply find your iteration path in the second column, and then use the value in the first column.

Note: I included the ProjectPath to handle the case where you have the same project name used in different Team Project Collections. When this happens, you’ll need to make sure you use areas/iterations from the project path that matches your project.

To find areas instead of iterations, simply change “Iteration” to “Area” wherever it appears in the query.

You can now copy this number into the parameter text box in Report Manager.

Colors in the Build Success over Time Report

The Build Success over Time report shows a color that depends on a number of things. Since you have to dig in and look at the source of the report to find out where all the colors come from, I thought I’d provide a high-level overview. The following table provides the rules that are applied in order. The first rule that matches controls the color:

Color	Conditions
Light Red	Build status is partially succeeded
Empty	There were no builds
Red	At least one build failed
Amber	At least one test failed
Light Green	At least one test passed, and the code coverage is below the threshold (explained below)
Dark Green	At least one test passed and code coverage is above or equal to the threshold (explained below)
Yellow	Builds had no errors, but there are no tests run in the build

Code Coverage Threshold

The code coverage threshold is controlled by a parameter in the report called CodeCoverageThreshold, which has a default value of 0.7 (70%). The following blog posts provide two ways to change this value:

• Customizing Report Parameters for Team Foundation Server 2010
• Report Parameters in Dashboards via URL Parameters

Using TfsRedirect to Display Reports in TFS 2010 Dashboards

You may have seen some reports show up in the TFS 2010 dashboards and wondered how we did a few things:

• How does the dashboard locate the report?
• How did we hide the parameter bar?
• How did we hide the report’s head and footer?
• How did we make the reports smaller?

I’ll answer each of these questions in sections below.

What I won’t do here is provide a walkthrough of setting up web parts to show reports. My friend Chris Adams already wrote a nice blog on this: Enhancing TFS 2010 Dashboards – Project Mgmt, Bugs, Builds, etc.

What is TfsRedirect?

Here’s the scenario. You had TFS create a dashboard site in SharePoint when you created your team project (or you added it later as described here). There are several items on this dashboard that point to other locations that are potentially on other servers:

• Team Web Access
• Process Guidance
• Reports shown on the dashboard pages

TFS itself know where to find these assets. And the locations can change if, for example, the TFS administrator moves the reports to a different server.

Rather than hard-code the locations of these assets into the dashboard, the TFS team created a web page called TfsRedirect.aspx that knows where these different assets are located, and will redirect to that page.

This is what the URL looks like on the Agile dashboard that shows the Burndown graph:

/sites/DefaultCollection/wss/_layouts/TfsRedirect.aspx?tf:Type=Report&tf:ReportName=Dashboards/Burndown&tf:ShowToolbar=0&Width=381pt&Height=180pt

Yikes, you say! It’s actually not that bad once you break this into the different parts. The first part is basically the path to the TfsRedirect.aspx file. This is a relative path that is used to get to various pages on your site, followed by “_layouts/TfsRedirect.aspx” that refers to the actual location of this file.

After the question mark are a set of parameters. The parameters that begin with tf: are parameters to TfsRedirect itself. All other parameters will be passed on unchanged to the final URL that TfsRedirect builds, which in this case will be a URL to the report on Reporting Services.

TfsRedirect Parameters

The first parameter, tf:Type, determines the destination for the redirection, such as reports or process guidance. Here are the values support for tf:Type, which is a required parameter:

tf:Type Value	Meaning
Report	Displays a single report. See below for additional parameters.
ReportList	Displays a list of reports, using SQL Reporting Services’ Report Manager page. This values is used by the Reports quick launch link on the dashboards to take you to Report Manager.
ProcessGuidance	Display the process guidance defined for this team project. This is used by the Process Guidance quick launch link in the dashboards.
WebAccess	Redirect to the Team Web Access web application. This is used by the Team Web Access link on the dashboards.

There are some other parameters that can be used in unusual cases:

Parameter	Meaning
tf:ClearCache=1	(optional) You should never include this parameter in a web part. Instead, this is a parameter that a TFS administrator might after changing TFS settings, such as the location of reporting services, in order to have the web site retrieve the latest value right away.
tf:Test=1	(optional) You can add this parameter onto an existing TfsRedirect URL to display “debugging” information that can help a TFS administrator. This will display information such as the connected team project. It will also display the URL that TfsRedirect will use as the destination of the redirect.
tf:ProjectID	(optional) Allows you to specify a team project that is different from the team project connected to the dashboard. This is the project’s GUID, and looks something like this:      ProjectId={74893-374983-73489-473894237}

tf:Type=Report Parameters

Most of the extra parameters supported by TfsRedirect are used for the Report redirection type. Here are the parameters supported:

Parameter	Meaning
tf:ReportName	(required) The name of the report. If the report is inside a folder, you’ll need to put that folder in front of the name. For example, “Dashboards/Burndown.” In some cases you’ll see “%2f” substituted for the “/” character, but you don’t need to do this when calling TfsRedirect.
tf:ShowToolbar	(optional) Set to 0 if you want to hide the report parameters bar and the toolbar. Setting this to 1, or leaving it out, will show both. The Agile and CMMI dashboards always set this to 0 for reports shown on the dashboard.

tf:Type=ProcessGuidance Parameters

There is only one optional parameter for process guidance:

Parameter	Meaning
DocumentPath	(optional) A file name or relative path that will be appended to the normal guidance URL. If you have problems getting this to work, you can use the tf:Test=1 parameter described above to see the full URL that TfsRedirect builds.

Reports that Support IsDashboard

We did some extra work to make some of the reports work on dashboards. This was done by adding some parameters to the report (you can set

OK, the final two questions are about how to display “dashboard” versions of the reports. We added “dashboard” support to some, but not all of the reports. Basically, if the dashboard has a parameter called IsDashboard, it has some support. Here are the parameters related to dashboard support:

Parameter	Meaning
IsDashboard	Set this to True to hide the header and footer of the report. For example, IsDashboard=true. In some cases, we have special dashboard versions of the report that don’t need this parameter, located in the Dashboards report folder.
Width	If present, you can use this to set the width of a chart. For example, Width=381pt. The measure is important here, and Reporting services can be a little picky. Points (pt) are usually a good measure to use.
Height	If present, sets the height of the chart in the report. The same rules apply as for Width.

Here are some of my previous blog posts that will help you with setting report parameters:

• Customizing Report Parameters for Team Foundation Server 2010
• Report Parameters in Dashboards via URL Parameters

New Whitepapers for Team Foundation Server 2010 Reports

Several years ago I wrote a whitepaper called Creating and Customizing TFS Reports that covered reports in Team Foundation Server 2008.

I’ve updated this whitepaper, and split it in two, for the new Team Foundation Server 2010. You can find them here:

• Creating Reports for Team Foundation Server 2010 – shows how to create new reports using Excel, and Report Builder 2.0.
• Customizing Reports for Team Foundation Server 2010 – covers using SQL Report Designer to create and customize reports, and also provides an introduction to the MDX query language used in the shipping reports.