Eugene Bykov : Sample

Opening views and executing tasks from reports

eugenebykov — Fri, 14 Aug 2009 23:20:00 GMT

SCOM 2007 reporting infrastructure has an ability to invoke a view or execute a task defined in a Management Pack from a report. This functionally helps bringing context from the report "back" to the operation console. Most of the out-of-the-box SCOM 2007 reports leverage this feature to open various typed of monitoring or in certain cases even authoring views.

Reference to a view or a task is a regular RDL Hyperlink that points to a specially formatted URI. This formatting lets SCOM console to treat it as an execute a view or a task command rather than a report drill-down. There is a ConsoleIntegration class that helps in formatting console links correctly. This class is defined in the SCOM reporting code extension library (Microsoft.EnterpriseManagement.Reporting.Code.dll) that is shipped with the product and installed into Report Server Bin directory during setup. You need to reference this library to make it available for the report code to call.

<CodeModules>
<CodeModule>Microsoft.EnterpriseManagement.Reporting.Code, Version=6.0.0.0, Culture=neutral</CodeModule>
</CodeModules>

After the library is referenced you can start using it. Here is an example that references State view from a report:

<Textbox Name="textbox">
    ...
        <Action>
            <Hyperlink>= Microsoft.EnterpriseManagement.Reporting.ConsoleIntegration.CreateConsoleViewLink(
                                    Fields!ManagementGroupGuid.Value,
                                    "Microsoft.SystemCenter.StateView",
                                    Fields!ManagedEntityGuid.Value)
            </Hyperlink>
        </Action>
    ...
</Textbox>

ConsoleIntegration class defines a set of overloads for links. Here is the list:

string CreateConsoleViewLink(
Guid managementGroupId,
string viewName,
Guid viewTarget)

string CreateConsoleViewLink(
string managementGroupId,
string viewName,
string viewTarget)

string CreateConsoleTaskLink(
Guid managementGroupId,
string taskName,
Guid taskTarget)

string CreateConsoleTaskLink(
string managementGroupId,
string taskName,
string taskTarget)

Since data warehouse can collect data for multiple management groups "managementGroupId" is a required parameter for all calls.

The important thing to remember is that these links make sense only in a context of SCOM console. They will fail to execute in case you try to clink on them in default SQL Report Manager interface. To avoid these failures you need to make sure you declare Interactive parameter in your report. SCOM console always sets this parameter to True when the report is executed in the console.

<ReportParameter Name="Interactive">
    <DataType>Boolean</DataType>
    <Nullable>true</Nullable>
    <DefaultValue>
        <Values>
            <Value>=False</Value>
        </Values>
    </DefaultValue>
    <Prompt>Interactive</Prompt>
    <Hidden>true</Hidden>
</ReportParameter>

The last step is to make sure you use the parameter to hide hyperlinks in the report.

<Visibility>
<Hidden>=Parameters!Interactive.Value <> True</Hidden>
</Visibility>

Performance "Top" linked reports

eugenebykov — Tue, 16 Oct 2007 08:10:00 GMT

Generic performance reports are ones of the most powerful generic reports in SCOM 2007. I like to start from "Performance Top Objects" and "Performance Top Instances" reports. They are the easiest and creating linked reports for them could be quite useful in case where you like to simplify customer experience in searching for objects or instances that are "on top" for a specific performance rule. In most cases the way to simplify the experience is to hard-code the rule in the linked report so the customers won't need to search for it.

If you haven't done this already I highly recommend reading "Linked availability reports" and "Linked reports" posts before continue. They cover some theory behind linked reports authoring. Reading "Report parameters block" and "Report parameter controls" could also be useful in understanding RPDL part of the story.

RuleId, SortOrder and TopCount are parameters that are customizable for "Performance Top" reports. "Performance Top Objects" report also has an additional RuleInstance parameter. This parameter is not valid for "Performance Top Instance" report since the rule instance is the result of the report rather then a filter.

RuleId

This parameter defines the rule report operates on. If you look at the actual report code (RDL file) you find that this parameter is in fact GUID of a performance rule in SCOM management group installation. You may ask me how could I know a GUID of the rule in a particular management group at the time of management pack authoring? The answer is you can't. Instead you should use a special $MPElement syntax which allows referencing of management pack elements by a system name at authoring time. $MPElement reference is resolved and converted to GUID automatically at the time of report deployment. Here is an example:

<Parameter Name="RuleId">
<Value>$MPElement[Name="SQL!Microsoft.SQLServer.2005.NumberDeadlocksPerSecond"]$</Value>
</Parameter>

SortOrder

This parameter switches report algorithm. Here is the list of possible values:

Top N	-1
Bottom N	1

TopCount

This is "N" value for the SortOrder parameter. Specify any positive number here but be reasonable. Setting the value too high can make the report chart unreadable.

RuleInstance

As I said before this parameter only valid for "Performance Top Objects report". It is used in cases where you know an instance or a set of rule instances you like to include in the report filter criteria.

Now when we know all these parameters it is a snap to define the lined report. As usually you should not forget about parameter definition for the new report. To simplify the process just copy and paste context of the Microsoft.SystemCenter.DataWarehouse.Report.PerformanceTop.rpdl or Microsoft.SystemCenter.DataWarehouse.Report.PerformanceTopInstance.rpdl. In most cases however you can choose to remove some parameter controls from the block to disallow users changing the parameters you specified. The most common control to disable is the rule picker, but you can choose to remove TopCount and/or SortOrder as well. Here is the complete example:

<LinkedReport ID="Demo.Bottom10DeadlockedDatabases"

Accessibility="Public" Visible="true" Base="Reporting!Microsoft.SystemCenter.DataWarehouse.Report.PerformanceTop">

   <ParameterBlock columns="2" xmlns="http://schemas.microsoft.com/mom/reporting/2007/ReportParameterSettings">
      <Controls>
        <Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.RelativeDateTimePicker">
          <ReportParameters>
            <ReportParameter name="TimeZone" binding="TimeZone">
              <Prompt>
Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.TimeZone
              </Prompt>
            </ReportParameter>
            <ReportParameter name="TimeZoneName" binding="TimeZoneName" />
            <ReportParameter name="StartDate_BaseType"
                             binding="StartDate_BaseType" />
            <ReportParameter name="StartDate_BaseValue"
                             binding="StartDate_BaseValue">
              <Prompt>
Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.StartDateTime
              </Prompt>
            </ReportParameter>
            <ReportParameter name="StartDate_OffsetType"
                             binding="StartDate_OffsetType" />
            <ReportParameter name="StartDate_OffsetValue"
                             binding="StartDate_OffsetValue" />
            <ReportParameter name="EndDate_BaseType"
                             binding="EndDate_BaseType" />
            <ReportParameter name="EndDate_BaseValue"
                             binding="EndDate_BaseValue">
              <Prompt>
Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.EndDateTime
              </Prompt>
            </ReportParameter>
            <ReportParameter name="EndDate_OffsetType"
                             binding="EndDate_OffsetType" />
            <ReportParameter name="EndDate_OffsetValue"
                             binding="EndDate_OffsetValue" />
          </ReportParameters>
        </Control>
        <Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.ComboBox">
          <ReportParameters>
            <ReportParameter name="ManagementGroupId">
              <Prompt>
Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.ManagementGroup
              </Prompt>
            </ReportParameter>
           </ReportParameters>
         </Control>
     </Controls>
   </ParameterBlock>

<Value>$MPElement[Name="SQL!Microsoft.SQLServer.2005.NumberDeadlocksPerSecond"]$</Value>

</Parameter>

</Parameter>

</Parameter>

</Parameters>

</LinkedReport>

Linked availability reports

eugenebykov — Fri, 14 Sep 2007 04:15:00 GMT

Availability report is one of the easiest reports to create links to. The report is based on the monitor state changes. There are not that many parameters to control besides list of monitoring objects, monitor states considered to be downtime and essentially the monitor.

One important thing to understand in linked report authoring is that objects should never be used as a hard-coded parameters to your reports. Monitoring objects are specific to a particular SCOM management group installation and could not be known at the time the management pack is created.

Monitor and downtime states on the other hand are things that are well known at the authoring time. Hard-coding them could be quite useful in cases where you either want to look at the particular monitor or when your organization has some specific rules around downtime definition.

Let's say we like to create an availability report based on ping status assuming that device is not available when the monitor is in down or warning states. Here is a definition of such report:

<LinkedReport ID="Demo.ComputerPingHealth"

Accessibility="Public" Visible="true" Base="Reporting! Microsoft.SystemCenter.DataWarehouse.Report.Availability">

<Value>Microsoft.SystemCenter.Ping</Value>

</Parameter>

</Parameter>

</Parameters>

</LinkedReport>

Notice that we put only value 2 for DownTime parameter even though I said we will consider both monitor down (red) and warning (yellow) states as downtime. This is because "monitor down" state is always considered as downtime regardless of what we specified it in the DownTime parameter.

Here is the list of all possible values for the DownTime parameter:

Warning	2
Planned Maintenance	6
Unplanned Maintenance	5
Monitor disabled	4
Unmonitored	3

The last thing to do is to create parameter definition for the new report. To simplify the process just copy context of the Microsoft.SystemCenter.DataWarehouse.Report.Availability.rpdl there. Here is the result:

<LinkedReport ID="Demo.ComputerPingHealth"

Accessibility="Public" Visible="true" Base="Reporting!Microsoft.SystemCenter.DataWarehouse.Report.Availability">

   <ParameterBlock columns="4" xmlns="http://schemas.microsoft.com/mom/reporting/2007/ReportParameterSettings">
      <Controls>
        <Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.ComboBox">
          <ReportParameters>
            <ReportParameter name="DataAggregation">
              <Prompt>
Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.DataAggregation
              </Prompt>
            </ReportParameter>
           </ReportParameters>
         </Control>
         <Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.MonitoringObjectXmlPicker" columnSpan="2" rowSpan="2">
          <ReportParameters>
            <ReportParameter name="ObjectList">
              <Prompt>
Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.ObjectList
              </Prompt>
            </ReportParameter>
            <ReportParameter name="ManagementGroupId" binding="GroupList"/>
          </ReportParameters>
         </Control>
         <Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.CheckedListBox" rowSpan="2">
          <ReportParameters>
            <ReportParameter name="DownTime">
              <Prompt>
Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.AvailabilityDownTime
              </Prompt>
           </ReportParameter>
         </ReportParameters>
        </Control>
        <Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.BusinessRelativeDateTimePicker">
          <ReportParameters>
            <ReportParameter name="TimeZone" binding="TimeZone">
              <Prompt>
Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.TimeZone
              </Prompt>
            </ReportParameter>
            <ReportParameter name="TimeZoneName" binding="TimeZoneName" />
            <ReportParameter name="StartDate_BaseType"
                             binding="StartDate_BaseType" />
            <ReportParameter name="StartDate_BaseValue"
                             binding="StartDate_BaseValue">
              <Prompt>
Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.StartDateTime
              </Prompt>
            </ReportParameter>
            <ReportParameter name="StartDate_OffsetType"
                             binding="StartDate_OffsetType" />
            <ReportParameter name="StartDate_OffsetValue"
                             binding="StartDate_OffsetValue" />
            <ReportParameter name="EndDate_BaseType"
                             binding="EndDate_BaseType" />
            <ReportParameter name="EndDate_BaseValue"
                             binding="EndDate_BaseValue">
              <Prompt>
Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.EndDateTime
              </Prompt>
            </ReportParameter>
            <ReportParameter name="EndDate_OffsetType"
                             binding="EndDate_OffsetType" />
            <ReportParameter name="EndDate_OffsetValue"
                             binding="EndDate_OffsetValue" />
            <ReportParameter name="TimeType" binding="TimeType" />
            <ReportParameter name="TimeWeekMap"
                             binding="TimeWeekMap" />
          </ReportParameters>
        </Control>
     </Controls>
   </ParameterBlock>

<Value>Microsoft.SystemCenter.Ping</Value>

</Parameter>

</Parameter>

</Parameters>

</LinkedReport>

Report parameters block

eugenebykov — Fri, 15 Jun 2007 02:35:00 GMT

It is not a secret that standard way of presenting report parameters in SQL Server Reporting Services does not give you much flexibility. Designing reporting solution for SCOM 2007 we wanted to change that and enable a way reach controls could be used for report parameter selection. Imagine yourself scrolling though a list of all computers in your organization trying to pick a particular one. We didn’t want that to happen…

As you know report parameters are traditionally defined in the RDL file. The RDL file parameter definition contains name, type, list of valid values, default value etc. It also contains parameter presentation attributes like display name and hidden flag. Standard SSRS parameter block layout logic is very simple: visible parameters are rendered in two columns (from left to right then from top to bottom) based on the order of parameters in the RDL file.

In SCOM 2007 we introduced report parameter definition block which provides additional layout and parameter presentation logic. The parameter block definition is stored in the RPDL (Report Parameter Definition Language) file. This file has to be stored in the same folder with the repot and have report name with ".rpdl" extension.

RPDL file is optional. SCOM 2007 will render parameters similarly to standard SSRS parameter block if you do not specify one.

What is inside RPDL file? Let’s take a look. Here is an example:

As you can see the parameter block XML has a list of parameter controls. This is similar to parameters definition in RDL file. The difference however is that RDL defines parameters while RPDL defines controls to edit the parameter values. Control can manage or use one or more parameters in the underlying report. Controls are defined in a management pack and can have different implementation depending on what platform they are running.

RPDL still uses left to right / top to bottom layout model but you can control how many columns you have and define if you like controls to span several rows or columns to achieve desired parameters layout.

Linked reports

eugenebykov — Mon, 21 May 2007 21:54:00 GMT

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:

<LinkedReport ID="Demo.MyApplicationHealth"

Accessibility="Public" Visible="true" Base="Reporting!Microsoft.SystemCenter.DataWarehouse.Report.Availability">

</Parameter>

</Parameter>

<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:

<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.

<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...

Reports in Management Packs.

eugenebykov — Fri, 18 May 2007 02:08:00 GMT

In my previous post “Authoring reports for SCOM 2007” I said that there are basically tree ways to author new reports for SCOM 2007. Create a linked report, use Report Builder or create a custom report using Visual Studio. The best way to introduce a new report in the system is to include it in a Management Pack (read “SCOM 2007 Report Catalog” post for details).

Any Management Pack (MP) can contain reports. If you have RDL file you can simply paste it content under Reporting/Report/Definition node in the MP.

Here is an example:

[Paste content of the RDL file here...]

</Definition>

</Report>

</Reports>

</Reporting>

ID is the name your report is deployed under to the SSRS. ID is also a reference for your report inside the Operations Manager. It has to be unique inside the MP and if you specify Accessibility="Public" other management packs could reference your report if they like to use it as a drill-down or as a sub-report.

Your report is going to be visible inside the catalog if you set Visible to "true". Specify "false" if you author a sub-report or a drill down report that you don’t like to be a part of the list of reports users can run directly.

That’s it! Your report is ready to go. To complete the picture however you probably want to give you report a friendly name. That name is displayed in the console when user clicks on your management pack inside the Reporting navigation tree.

To give your report a friendly name you need to define a display string inside the management pack and target it to your report ID.

<Name>My Report</Name>

<Description>My First SCOM 2007 Report</Description>

</DisplayString>

</DisplayStrings>

</LanguagePack>

</LanguagePacks>