Linked reports
In SCOM 2007 we tried to make out of the box reports as generic and as configurable as possible. The result of these efforts is more possibilities with actually much less work from your side to customize reports to needs of your organization or your custom application. The customization is done though linked reports. Linked reports are widely used in management packs for specific products like SQL Server or Windows Server. If you look at most management packs besides “Microsoft Generic Report Library” they mostly contain linked reports or in a lot of cases only linked reports.
What is the linked report anyway? In short, it is a shortcut to a report. You can read more about SQL Server Reporting Services linked reports concept here. The best part of the linked report concept that makes linked reports so useful in SCOM 2007 is that you can specify different default report parameter values and define a different way parameters are presented to the user. For instance you can create a linked performance report with a set of hardcoded performance rules. If you’ve done that you would never need to think about which rules to pick to check your application performance.
So, how do I create a linked report? The best way to do that is again in a management pack. Here is an example:
<Reporting>
<LinkedReports>
<LinkedReport ID="Demo.MyApplicationHealth"
Accessibility="Public" Visible="true" Base="Reporting!Microsoft.SystemCenter.DataWarehouse.Report.Availability">
<Parameters>
<Parameter Name="DataAggregation">
<Value>1</Value>
</Parameter>
<Parameter Name="DownTime">
<Value>2</Value>
<Value>3</Value>
</Parameter>
<Parameter Name="MonitorName">
<Value>System.Health.EntityState</Value>
</Parameter>
</Parameters>
</LinkedReport>
</LinkedReports>
</Reporting>
Linked report ID, Accessibility and Visible attributes have the same meaning as with regular report (see "Reports in Management Packs" post). The new attribute here is Base. Base tells which report this is a shortcut to. In our case it is a generic availability report. You can use any publicly defined report here from any MP. Just don’t forget to include a reference to that MP if this is not the same one you are putting the linked report into. In our case the required reference would be:
<Reference Alias="Reporting">
<ID>Microsoft.SystemCenter.DataWarehouse.Report.Library</ID>
<Version>MANAGEMENTPACK_VERSION</Version>
<PublicKeyToken>MANAGEMENTPACK_PUBLIC_KEY_TOKEN</PublicKeyToken>
</Reference>
Parameters section is the next thing that defines linked report. This is the section where we specify which parameter values we like to override in the original report. In our case we are saying that health of you application is defined by System.State.EntityHealth monitor and we consider Warning (2) and Unmonitored (3) states as downtime. We also say that we like to use “Houtly” (1) aggregations for our report to speed up report query execution.
As in case with custom report we probably want to provide a display name for this linked report so it is displayed nicely in the console.
<LanguagePacks>
<LanguagePack ID="ENU" IsDefault="true">
<DisplayStrings>
<DisplayString ElementID="Demo.MyReport">
<Name>My Report</Name>
<Description>My First SCOM 2007 Report</Description>
</DisplayString>
</DisplayStrings>
</LanguagePack>
</LanguagePacks>
That is pretty much all you need to do to define a new linked report. One thing I didn’t tell you about is report parameters presentation. If base report defines custom parameter presentation settings (all SCOM 2007 generic reports do by the way) you most likely would need to define it for the linked report as well. If you would, for example, create a linked report using exact XML I provided in this example you would see that your report has some odd parameters when you open it in the console. That would happen exactly because we didn’t defined any parameter block settings and SCOM generated a default ones for us.
Parameter block definition is a subject for a separate discussion I am planning to shed some light on next. Stay tuned...