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

Represents an implementation of a data source module type definition.

Schema Hierarchy

ManagementPack
  TypeDefinitions
    ModuleTypes
      DataSourceModuleType
        ModuleImplementation (DataSourceModuleType)
          Composite (DataSourceModuleType)
            MemberModules (DataSourceModuleType)
              DataSource

Syntax

Xml 
<DataSource ID=”ModuleID” Comment=”Comment” TypeID=”ModuleTypeID”>
Custom Schema Defined Parameters
</DataSource>

Attributes and Elements

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

Attributes

Attribute Description

ID

Required attribute. Represents the identity of the element.

Comment

Optional attribute. Represents commentary by the management pack author.

TypeID

Required attribute. Represents DataSource module type definition from which this DataSource module inherits its configuration schema.
ID Attribute Values

Value Description

The format for the ID attribute should be UniqueElementID.

The ID string must contain the following characteristics:

  • The length is less than 255 characters.

  • The ID begins with a letter (a-z) or a number (0-9).

  • The ID contains only letters, numbers, the period character (.), or the underscore (_) character.

  • The ID is unique across all elements within the scope of the DataSource module’s containing workflow.

  • The ID is case-sensitive.

Child Elements

The child element of the DataSource module is defined by the Configuration (DataSourceModuleType) schema of its base type as referenced in the TypeID attribute.

Parent Elements

Element Description

MemberModules (DataSourceModuleType)

Contains all of the modules that are used in the linear workflow of a module type definition.

Remarks

Because a data source module does not take an input stream, it must always be the first module in any workflow. Functioning entirely or partially as a scheduler or functioning as a data provider, the data source module initiates the workflow. As a data provider, the data source can get data from NT performance counters, SNMP triggers, or NT events. The data type of its output data is defined in its OutputType (ConditionDetectionModuleType) element.

A data source module type never alters system state. If you want a module to affect system state, you must use or implement a WriteAction (WriteActionModuleType) module.

A data source module’s base type must always be a descendant of a DataSourceModuleType type.

Example

The first sample illustrates how a DataSourceModuleType encapsulates a data source module named Scheduler. Scheduler is used to initiate a probe action against the registry at a specified frequency. Scheduler is of the data source module type, System.Discovery.Scheduler, which is defined in the System.Library management pack. To see how System.Discovery.Scheduler is defined, see the second sample in this section.

  Copy Code 
<DataSourceModuleType ID="Microsoft.Windows.Discovery.RegistryProvider" Accessibility="Public">
  <Configuration>
	<IncludeSchemaTypes>
	<SchemaType>Microsoft.Windows.RegistryAttributeDefinitionsSchema</SchemaType>
	</IncludeSchemaTypes>
	<xsd:element name="ComputerName" type="xsd:string" />
	<xsd:element name="RegistryAttributeDefinitions" type="RegistryAttributeDefinitionsType" />
	<xsd:element name="Frequency" type="xsd:unsignedInt" />
  </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>$Config/RegistryAttributeDefinitions$</RegistryAttributeDefinitions>
		</ProbeAction>
	</MemberModules>
	<Composition>
		<Node ID="Probe">
		<Node ID="Scheduler" />
		</Node>
	</Composition>
	</Composite>
  </ModuleImplementation>
  <OutputType>Microsoft.Windows.RegistryData</OutputType>
</DataSourceModuleType>

The second sample shows the configuration schema of the data source module type System.Discovery.Scheduler. Notice that it too contains a data source module named DSI. DSI references an internal native module implementation. In this case, System.Discovery.Scheduler is used to provide encapsulation of internal modules.

  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>

See Also