ModuleTypes

Article
02/02/2012

Applies To: System Center Service Manager 2010

Contains module type definitions in a management pack.

Schema Hierarchy

ManagementPack
TypeDefinitions
ModuleTypes

Syntax

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

Attributes and Elements

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.

Remarks

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

Share via