Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All

ModuleTypes

System Center

Updated: August 10, 2011

Applies To: Operations Manager 2007 R2, System Center Operations Manager 2007

Contains module type definitions in a management pack.


<ModuleTypes>
   <DataSourceModuleType></DataSourceModuleType>   <ProbeActionModuleType></ProbeActionModuleType>   <ConditionDetectionModuleType></ConditionDetectionModuleType>
   <WriteActionModuleType></WriteActionModuleType>
</ModuleTypes>

The following sections describe attributes, child elements, and the parent element of the ModuleTypes element.

Attributes

None.

Child Elements

 

Element Description

DataSourceModuleType

Optional element. Represents a data source module type definition in a management pack. Implemented when the module is to be used to output workflow data for either notification or information purposes. The DataSourceModuleType module type does not take any input data.

ProbeActionModuleType

Optional element. Represents a probe action module type definition in a management pack. Implemented when the module is used to output workflow data. Unlike the DataSourceModuleType module type, the ProbeActionModuleType module type takes input data.

ConditionDetectionModuleType

Optional element. Represents a condition detection module type definition in a management pack. Implemented when the module is used to provide some kind of data filtering or condition reasoning within a workflow.

WriteActionModuleType

Optional element. Represents a write action module type definition in a management pack. Implemented when the module is used to write to or change the system in some way.

Parent Elements

 

Element Description

TypeDefinitions

Contains all types defined in the management pack.

Module types define the building blocks of workflows. They are used in rules, tasks, monitors, diagnostics, recoveries and discoveries. A module type can be one of the following kinds:

  • Native code implementation

  • Managed code implementation

  • Composite

Currently, the creation of custom native and managed code modules is not supported. Instead, composite modules can be created by wrapping core modules in custom module type definitions. The following are reasons why you want to define your own custom module type:

  • Modularization

    For example, to build your workflows, you might find that you are using a sequence of two modules: a DataSource (DataSourceModuleType) module that is a scheduler and a ProbeAction (DataSourceModuleType) module that retrieves data from an OleDB database. Instead of having to insert these modules into various workflows, you can create a DataSourceModuleType definition in your management pack that contains both of the modules as a MemberModules (DataSourceModuleType) module type.

    
    <DataSourceModuleType ID="Microsoft.Windows.Discovery.RegistryProviderSingle" Accessibility="Public">
      <Configuration>
        <IncludeSchemaTypes>
          <SchemaType>Microsoft.Windows.RegistryAttributeDefinitionsSchema</SchemaType>
        </IncludeSchemaTypes>
        <xsd:element name="ComputerName" type="xsd:string" />
        <xsd:element name="AttributeName" type="xsd:ID" />
        <xsd:element name="Path" type="xsd:string" />
        <xsd:element name="PathType" type="xsd:integer" />
        <xsd:element name="AttributeType" type="xsd:integer" />
        <xsd:element name="Frequency" type="xsd:unsignedInt" />
        <xsd:element name="RegistryView" minOccurs="0" maxOccurs="1" type="RegistryViewType" />
      </Configuration>
      <OverrideableParameters>
        <OverrideableParameter ID="Frequency" Selector="$Config/Frequency$" ParameterType="int" />
      </OverrideableParameters>
      <ModuleImplementation>
        <Composite>
          <MemberModules>
            <DataSource TypeID="System!System.Discovery.Scheduler" ID="Scheduler">
              <Scheduler>
                <SimpleReccuringSchedule>
                  <Interval Unit="Seconds">$Config/Frequency$</Interval>
                </SimpleReccuringSchedule>
                <ExcludeDates />
              </Scheduler>
            </DataSource>
            <ProbeAction TypeID="Microsoft.Windows.RegistryProbe" ID="Probe">
              <ComputerName>$Config/ComputerName$</ComputerName>
              <RegistryAttributeDefinitions>
                <RegistryAttributeDefinition>
                  <AttributeName>$Config/AttributeName$</AttributeName>
                  <Path>$Config/Path$</Path>
                  <PathType>$Config/PathType$</PathType>
                  <AttributeType>$Config/AttributeType$</AttributeType>
                  <RegistryView>$Config/RegistryView$</RegistryView>
                </RegistryAttributeDefinition>
              </RegistryAttributeDefinitions>
            </ProbeAction>
          </MemberModules>
          <Composition>
            <Node ID="Probe">
              <Node ID="Scheduler" />
            </Node>
          </Composition>
        </Composite>
      </ModuleImplementation>
      <OutputType>Microsoft.Windows.RegistryData</OutputType>
    </DataSourceModuleType>
    
    
  • Encapsulation

    If you define publically accessible module types, you might consider implementing an encapsulation module in your management pack. To do this, you create pairs of module types where one would be public and the other would be internal. If later you must change internal module functionality, it will not affect current clients of your management pack. With encapsulation, you are essentially delivering your management pack as an interface.

    
    <DataSourceModuleType ID="System.Discovery.Scheduler" Accessibility="Public" Batching="false">
      <Configuration>
        <IncludeSchemaTypes>
          <SchemaType>System.ExpressionEvaluatorSchema</SchemaType>
        </IncludeSchemaTypes>
        <xsd:element name="Scheduler" type="PublicSchedulerType"/>
      </Configuration>
      <ModuleImplementation Isolation="Any">
        <Composite>
          <MemberModules>
            <DataSource TypeID="System.Discovery.Scheduler.Internal" ID="DS1">
              <Scheduler>$Config/Scheduler$</Scheduler>
              <ManagedEntityId>$Target/Id$</ManagedEntityId>
              <RuleId>$MPElement$</RuleId>
            </DataSource>
          </MemberModules>
          <Composition>
            <Node ID="DS1"/>
          </Composition>
        </Composite>
      </ModuleImplementation>
      <OutputType>System.TriggerData</OutputType>
    </DataSourceModuleType>
    
    
    
  • Specialization

    You might find that a module type requires configuration parameters that, for your management pack, always have the same value. In that case, you might want to create your own module type that wraps the functionality of the first module and hides the hard-coded parameter values within the first module’s configuration parameter XML.

    
    <WriteActionModuleType ID="Microsoft.Windows.ServiceControlManager.StartService" Accessibility="Public">
      <Configuration>
        <xsd:element name="ComputerName" type="xsd:string" />
        <xsd:element name="ServiceName" type="xsd:string" />
      </Configuration>
      <OverrideableParameters>
        <OverrideableParameter ID="ComputerName" ParameterType="string" Selector="$Config/ComputerName$" />
        <OverrideableParameter ID="ServiceName" ParameterType="string" Selector="$Config/ServiceName$" />
      </OverrideableParameters>
      <ModuleImplementation>
        <Composite>
          <MemberModules>
            <WriteAction ID="StartService" TypeID="System!System.CommandExecuter">
              <ApplicationName><![CDATA[%WinDir%\System32\sc.exe]]></ApplicationName>
              <WorkingDirectory />
              <CommandLine>\\$Config/ComputerName$ start $Config/ServiceName$</CommandLine>
              <TimeoutSeconds>60</TimeoutSeconds>
              <RequireOutput>true</RequireOutput>
            </WriteAction>
          </MemberModules>
          <Composition>
            <Node ID="StartService" />
          </Composition>
        </Composite>
      </ModuleImplementation>
      <OutputType>System!System.CommandOutput</OutputType>
      <InputType>System!System.BaseData</InputType>
    </WriteActionModuleType>
    
 
Show:
© 2015 Microsoft