Share via

Visual Studio Authoring Extensions - Simple Templates

  • Article

When you select any of the templates in the XML section of the Add New Item dialog box, also known as simple templates, an XML editing window opens with an XML skeleton for that element already in place. To see how this works, select the Class item to create a class. In the Name field at the bottom of the dialog box, enter a name for the class (TestClass), and click the Add button. The main editing pane appears in the center of the interface, and a new item (TestClass.mpx) has been added to the Solution Explorer on the right. Notice that the item has an .mpx extension, indicating that it’s a fragment.

An XML code skeleton for a class is provided for you, along with comments indicating what you need to fill in to make this fragment functional. Each simple template has a different skeleton:

  • Class

  • Folder & Folder Item

  • Group

  • Linked Report

  • Monitor Diagnostic

  • Monitor Recovery

  • Relationship

  • Schema Type

These are discussed in more detail in the following sections.

Class

The skeleton code Visual Studio generates for a new class item looks like this:

<ManagementPackFragment SchemaVersion="1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<TypeDefinitions>
<EntityTypes>
<ClassTypes>

<!-- In this section, modify the attributes based on your needs. Ensure the
Base attribute matches the application you are modeling.
More information can be found in the Management Pack Development Kit: 
http://msdn.microsoft.com/en-us/library/ee533867.aspx -->
<ClassType ID="MPAuthor.SampleManagementPack.TestClass" Base="Windows!Microsoft.Windows.ApplicationComponent" Accessibility="Internal" Abstract="false" Hosted="false" Singleton="false">

<!-- Inside this section, you can add and remove properties as needed.
More information can be found in the Management Pack Development Kit: 
http://msdn.microsoft.com/en-us/library/ee533714.aspx -->
<!--
<Property ID="Property1" Key="false" Type="string" />
-->
</ClassType>

</ClassTypes>
</EntityTypes>
</TypeDefinitions>
<LanguagePacks>
<LanguagePack ID="ENU" IsDefault="true">
<DisplayStrings>

<!-- This is the string users of the Operations Console and Web Console will see. 
Descriptions are also helpful when the user is doing a search in the Console. -->
<DisplayString ElementID="MPAuthor.SampleManagementPack.TestClass">
<Name>TestClass Class</Name>
<Description></Description>
</DisplayString>

<!-- Uncomment the below section if you need to add a user friendly string for each property. -->
<!--
<DisplayString ElementID="MPAuthor.SampleManagementPack.TestClass" SubElementID="Property1">
<Name>Property1 Property</Name>
<Description></Description>
</DisplayString>
-->
</DisplayStrings>
</LanguagePack>
</LanguagePacks>
</ManagementPackFragment>

In the opening <Class> element, provide the following:

  • An ID for the class
  • The base class that it derives from
  • The accessibility level
  • Whether the class is abstract
  • Whether the class is hosted
  • Whether the class is a singleton

Within the <Class> element, you can then provide the key properties for the class as needed. You can find out more about the attributes and properties of classes here.

Within the <DisplayStrings> section, provide a name and description for the class, which will appear in the Operations Console. You may also add names and descriptions for the properties of the class.

For more information about classes, see Classes.

Folder & Folder Item

The VSAE provides a template for folders and folder items to use with views. Here’s the code:

<ManagementPackFragment SchemaVersion="1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Presentation>
<Folders>

<!-- In this section, you can create more folders. Edit the DisplayString for this folder 
to change the name the user sees in the console. More information can be found in 
the Management Pack Development Kit: http://msdn.microsoft.com/en-us/library/ee533810.aspx -->
<Folder ID="MPAuthor.SampleManagementPack.Folder1" Accessibility="Internal" ParentFolder="SC!Microsoft.SystemCenter.Monitoring.ViewFolder.Root" />

</Folders>

<FolderItems>

<!-- In this section, uncomment and edit the ElementID to reference a View or Folder
you've created to place that item into the Folder referenced by the Folder attribute.
FolderItems do not need display strings; The referenced ElementID's DisplayString
is used and shown to the user. More information can be found in the Management 
Pack Development Kit: http://msdn.microsoft.com/en-us/library/ee533579.aspx -->
<!--
<FolderItem ID="MPAuthor.SampleManagementPack.FolderItem1" ElementID="" Folder="MPAuthor.SampleManagementPack.Folder1" />
-->
</FolderItems>

</Presentation>
<LanguagePacks>
<LanguagePack ID="ENU" IsDefault="true">
<DisplayStrings>

<DisplayString ElementID="MPAuthor.SampleManagementPack.Folder1">
<Name>Folder1 Folder</Name>
<Description></Description>
</DisplayString>

</DisplayStrings>
</LanguagePack>
</LanguagePacks>
</ManagementPackFragment>

There isn’t much for you to edit here. You can change the folder ID, accessibility level, or the parent folder in the <Folder> element definition. You can also add more folders if you need them. The <FolderItem> element is optional, so you need to remove the comment tags if you want to use that.

In the <DisplayStrings> section, you should provide name and description strings for the folder; folder items do not require display strings.

For more information about folders, see Folders.

Group

VSAE allows you to define a group of class types in XML. The group is defined similarly to a class, except that the default base class for a group is System!System.Group, instead of Windows!Microsoft.Windows.ApplicationComponent. The following is the XML skeleton for a group entity:

<ManagementPackFragment SchemaVersion="1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<TypeDefinitions>
<EntityTypes>
<ClassTypes>

<!-- In this section, you can edit the Base attribute to derive from other non-generic
group types. Depending on your requirements and how you or your users will use this
group, you may need to populate this group with instances by creating a Discovery
that uses a script or the GroupPopulator module: http://msdn.microsoft.com/en-us/library/ff472328.aspx -->
<ClassType ID="MPAuthor.SampleManagementPack.Group1" Accessibility="Internal" Base="System!System.Group" Abstract="false" Hosted="false" Singleton="false">

</ClassType>

</ClassTypes>
</EntityTypes>
</TypeDefinitions>
<LanguagePacks>
<LanguagePack ID="ENU" IsDefault="true">
<DisplayStrings>

<!-- The name of the group that will appear to users in the console. -->
<DisplayString ElementID="MPAuthor.SampleManagementPack.Group1">
<Name>Group1 Group</Name>
<Description></Description>
</DisplayString>

</DisplayStrings>
</LanguagePack>
</LanguagePacks>
</ManagementPackFragment>

For each <ClassType> element within the group, provide the following:

  • An ID for the class
  • The base class that it derives from
  • The accessibility level
  • Whether the class is abstract
  • Whether the class is hosted
  • Whether the class is a singleton

In the <DisplayStrings> section, you should provide name and description strings for the group; these will appear in the Operations console.

For more information about groups, see How to Create a Group.

Linked Report

Linked reports require more specialized configuration, so the skeleton is general, only outlining the basic sections. The following is the code skeleton for a linked report:

<ManagementPackFragment SchemaVersion="1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Reporting>
<LinkedReports>

<!-- 
In this section, you'll need to:
1) Derive from a Generic Report (Base attribute) - http://technet.microsoft.com/en-us/library/ff832981.aspx
2) Set your Target Class
3) Define the Parameter Blocks (i.e. Controls like Date picker controls)
4) Configure the Parameter Blocks with Parameters (i.e. Hardcoded or default config)

For a video walk through, view: http://technet.microsoft.com/en-US/systemcenter/ff959235.aspx
Use the following resources for additional examples for all the sections below:
- Linked Report Reference docs here: http://technet.microsoft.com/en-us/library/ff832987.aspx
- How to's with ParameterBlock & Parameter XML examples: http://technet.microsoft.com/en-us/library/ff833019.aspx
-->
<LinkedReport ID="MPAuthor.SampleManagementPack.LinkedReport1" Accessibility="Internal" Base="" Target="" Visible="true">
<!-- Please fill in the dependencies of your linked report. -->
<Dependencies>

</Dependencies>
<!-- Please fill in the parameter block. -->
<ParameterBlock xmlns="http://schemas.microsoft.com/mom/reporting/2007/ReportParameterSettings">

</ParameterBlock>

<!-- Please fill in the linked report parameters. -->
<Parameters>

</Parameters>

<!-- Please use this section for any report text that needs to be localized. -->
<ReportStrings>

</ReportStrings>
</LinkedReport>

</LinkedReports>
</Reporting>
</ManagementPackFragment>

The comments in the skeleton outline the basic procedure for creating a linked report. Further detail can be found in Linked Reports.

Monitor Diagnostic

Although the various types of monitor are defined with advanced templates, both diagnostic and recovery items are simple templates. Here is the XML skeleton for the Monitor Diagnostic entity:

<ManagementPackFragment SchemaVersion="1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Monitoring>
<Diagnostics>

<!-- In this section, you must edit the Target and Monitor attributes to 
configure this Diagnostic to run on a particular Monitor running on
that Target. More information can be found in the Management Pack Development Kit: 
http://msdn.microsoft.com/en-us/library/ee533473.aspx -->
<Diagnostic ID="MPAuthor.SampleManagementPack.Diagnostic1" Target="" Accessibility="Public" Enabled="true" Monitor="" ExecuteOnState="Error" Remotable="true" Timeout="300">
<Category>Maintenance</Category>

<!-- Please fill in the type of the condition detection module 
or remove the ConditionDetection section. This can be used to
inspect the Monitor State and Data Item that caused the State Change.
If this Condition Detection does not "pass" the ProbeAction will not
be executed. -->
<ConditionDetection ID="CD" TypeID="">
<!-- Provide ConditionDetection module configuration here. -->
</ConditionDetection>

<!-- Please fill in the type of the probe action module.
Without a ConditionDetection, the ProbeAction always executes.
The output of the probe action will be shown in the 
Health Explorer detail pane. -->
<ProbeAction ID="PA" TypeID="">
<!-- Provide ProbeAction module configuration here. -->
</ProbeAction>
</Diagnostic>
</Diagnostics>
</Monitoring>
<LanguagePacks>
<LanguagePack ID="ENU" IsDefault="true">
<DisplayStrings>

<!-- The name of the Diagnostic will appear in the Health Explorer
detail pane. The user can manually click the Diagnostic to run
it again. -->
<DisplayString ElementID="MPAuthor.SampleManagementPack.Diagnostic1">
<Name>Diagnostic1 Diagnostic</Name>
<Description></Description>
</DisplayString>

</DisplayStrings>
</LanguagePack>
</LanguagePacks>
</ManagementPackFragment>

To configure a diagnostic, you need to know the monitor that you want to trigger the diagnostic, and the target class that monitor that uses. Both of these are defined in the <Diagnostic> element. You also need to set a few other parameters in the <Diagnostic> element:

  • Accessibility: Set to Public or Internal
  • Enabled: Set to true or false
  • Execute on state: Possible values are Uninitialized, Success, Warning, or Error
  • Remotable: Set to true or false
  • Timeout: The time in seconds that the script may run before it is terminated.

You must also provide an optional condition detection module and a probe action module. If you do not provide a condition detection module, the probe action module will always run. You can use any existing module type from any management pack that you have a reference to, or you may define your own custom module type, either in the current management pack, or any management pack that you have a reference to. If you define a custom module type, use the Empty Management Pack Fragment template to define the custom module in a separate .mpx file within your project.

Provide the type ID for the condition detection and probe action modules, and then provide the configuration parameters for the module within the respective element.

In the <DisplayStrings> section, you should provide name and description strings for the diagnostic; these will appear in the Operations console.

For more information about diagnostics, see Diagnostics and Recoveries.

Monitor Recovery

The recovery template has a similar format to the diagnostic template. Here is the XML skeleton for the monitor recovery entity:

<ManagementPackFragment SchemaVersion="1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Monitoring>
<Recoveries>

<!-- In this section, you must edit the Target and Monitor attributes to 
configure this Recovery to run. Optionally, you can change the recovery 
to execute on a diagnostic instead of a particular monitor state. 
More information can be found in the Management Pack Development Kit: 
http://msdn.microsoft.com/en-us/library/ee533697.aspx -&#61664;
<Recovery ID="Demo.ManagementPack.Recovery1" Target="" Monitor="" Accessibility="Public" Enabled="false" ExecuteOnState="Error" Remotable="true" ResetMonitor="false" Timeout="300">
<Category>Maintenance</Category>

<!-- Please fill in the type of the condition detection module 
or remove the ConditionDetection section. This can be used to
inspect the Monitor State, Data Item that caused the State Change,
or the Diagnostic ProbeAction Output (if the ExecuteOnDiagnostic
attribute is present). If this Condition Detection does not "pass"
the WriteAction will not be executed. -&#61664;
<ConditionDetection ID="CD" TypeID="">
<!-- Provide ConditionDetection module configuration here. -&#61664;
</ConditionDetection>

<!-- Please fill in the type of the write action module.
Without a ConditionDetection, the WriteAction always executes.
The output of the write action will be shown in the 
Health Explorer detail pane. -&#61664;
<WriteAction ID="WA" TypeID="">
<!-- Provide WriteAction module configuration here. -&#61664;
</WriteAction>
</Recovery>

</Recoveries>
</Monitoring>
<LanguagePacks>
<LanguagePack ID="ENU" IsDefault="true">
<DisplayStrings>

<!-- The name of the Recovery will appear in the Health Explorer
detail pane. The user can manually click the Diagnostic to run
it again. -&#61664;
<DisplayString ElementID="Demo.ManagementPack.Recovery1">
<Name>Recovery1 Recovery</Name>
<Description></Description>
</DisplayString>

</DisplayStrings>
</LanguagePack>
</LanguagePacks>
</ManagementPackFragment>

As with the diagnostic, to configure a recovery, you need to know the monitor that you want to trigger the recovery, and the target class that monitor that uses. Both of these are defined in the <Diagnostic> element. You also need to set a few other parameters in the <Diagnostic> element:

  • Accessibility: Set to Public or Internal
  • Enabled: Set to true or false
  • Execute on state: Possible values are Uninitialized, Success, Warning, or Error
  • Remotable: Set to true or false
  • Reset monitor: Set to true or false; indicates whether running the recovery should reset the alert state of the monitor
  • Timeout: The time in seconds that the script may run before it is terminated

You must also provide an optional condition detection module and a write action module. If you do not provide a condition detection module, the write action module will always run. You can use any existing module type from any management pack that you have a reference to, or you may define your own custom module type, either in the current management pack, or any management pack that you have a reference to. If you define a custom module type, use the Empty Management Pack Fragment template to define the custom module in a separate .mpx file within your project.

Provide the type ID for the condition detection and write action modules, and then provide the configuration parameters for the module within the respective element.

In the <DisplayStrings> section, you should provide name and description strings for the recovery; these will appear in the Operations console.

For more information about recoveries, see Diagnostics and Recoveries.

Relationship

Although discovery elements are generated with advanced templates, a relationship is defined with a simple template. Here is the XML skeleton for a Relationship entity:

<ManagementPackFragment SchemaVersion="1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<TypeDefinitions>
<EntityTypes>
<RelationshipTypes>

<!-- In this section, provide the Source (i.e. Parent) and Target (i.e. Child)
for this relationship. Also, review and update the Base attribute. 
More information can be found in the Management Pack Development Kit: 
http://msdn.microsoft.com/en-us/library/ee533533.aspx -->
<RelationshipType ID="MPAuthor.SampleManagementPack.Relationship1" Base="System!System.Containment" Abstract="false" Accessibility="Internal">
<Source ID="Source" Type=""/>
<Target ID="Source" Type=""/>
</RelationshipType>

</RelationshipTypes>
</EntityTypes>
</TypeDefinitions>
<LanguagePacks>
<LanguagePack ID="ENU" IsDefault="true">
<DisplayStrings>

<!-- This is the string users of the Operations Console and Web Console will see. 
Descriptions are also helpful when the user is doing a search in the Console. -->
<DisplayString ElementID="MPAuthor.SampleManagementPack.Relationship1">
<Name>Relationship1 Relationship</Name>
<Description></Description>
</DisplayString>

</DisplayStrings>
</LanguagePack>
</LanguagePacks>
</ManagementPackFragment>

In the <RelationshipType> element, provide an ID for the relationship. The Base attribute is set to System!System.Containment by default, but can be changed to System!System.Hosting or System!System.Relationship if desired. Also define the accessibility; the Abstract property must always be set to false.

The schema for the source and target elements has changed from the Operations Manager 2007 schema to the Operations Manager 2012 schema. The ID element is simply an identifier for the source or target element. The Type element is the class of the source or the target.

In the <DisplayStrings> section, you should provide name and description strings for the relationship; these will appear in the Operations console.

For more information about relationships, see Relationships

Schema Type

Use the schema type template to define a schema definition that you use elsewhere in the management pack. Because this element is flexible, the skeleton in this case is more of an example than a template. Here is the XML skeleton:

<ManagementPackFragment SchemaVersion="1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<TypeDefinitions>
<SchemaTypes>

<!-- In this section, you can use standard XSD notation to define your 
own schema that can be used in ModuleType configuration, DataItem 
type definitions, and for other uses in Operations Manager. 
More information can be found in the Management Pack Development Kit: 
http://msdn.microsoft.com/en-us/library/ee533587.aspx -->
<SchemaType ID="MPAuthor.SampleManagementPack.SchemaType1" Accessibility="Internal">
<!-- Please customize the schema definition to match your needs. -->
<xsd:complexType name="ComplexType1">
<xsd:sequence>
<xsd:element name="Element1" type="xsd:string" />
<xsd:element name="Collection1" type="xsd:string">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Collection1Member" type="xsd:string" minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</SchemaType>

</SchemaTypes>
</TypeDefinitions>
</ManagementPackFragment>

Your element may or may not have complex types or collections; you should edit the XML as appropriate to the schema definition that you need.

For more information about schema types, see Schema Types Reference.

Additional Resources

[[Visual Studio Authoring Extensions for System Center 2012 - Operations Manager]]
[[Visual Studio Authoring Extensions - Visual Studio Features]]
 [[Visual Studio Authoring Extensions - Advanced Templates]]
[[Visual Studio Authoring Extensions - Example Management Pack]]