[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]

Contains module type definitions in a management pack.

Schema Hierarchy

ManagementPack
  TypeDefinitions
    ModuleTypes

Syntax

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

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

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

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

See Also

Reference

TypeDefinitions