ProbeAction (DataSourceModuleType)

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

Represents an implementation of a probe action module type definition.

Schema Hierarchy

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

Syntax

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

Attributes and Elements

The following sections describe attributes, child elements, and the parent element of the ProbeAction 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 the ProbeAction module type definition from which this ProbeAction 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 ProbeAction module’s containing workflow. The ID is case-sensitive.

Child Elements

The child element of the ProbeAction module is defined by the Configuration (ProbeActionModuleType) 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

A ProbeAction module takes a single input stream and outputs data. The data types of its input and output data are defined in its InputType (ProbeActionModuleType) and OutputType (ProbeActionModuleType) elements, respectively. Like a DataSource (DataSourceModuleType) module, the probe action module runs a process or script to gather data from a source, processes it, and finally returns the data. However, unlike a DataSource (DataSourceModuleType) module, a probe action module can receive input data and therefore does not have to be the first element in the workflow.

A probe action module type never alters system state. If you want your module to affect system state, you must instead use or implement a WriteAction (WriteActionModuleType) module.

Typically, a probe action module type is preceded in a workflow by a DataSource scheduler module so that its action can occur at an interval at some frequency.

A probe action module’s base type must always be a descendant of a ProbeActionModuleType type.

Example

The following two samples illustrate how a module type definition can contain and use a probe action module. All of the samples can be found in the Microsoft.Windows.Library management pack.

In the first sample, a DataSourceModuleType named Microsoft.Windows.RegistryProvider wraps the functionality of Probe, a probe action module. The Probe module’s configuration elements are defined by its base type System.Scheduler. The function of Microsoft.Windows.RegistryProvider is to provide registry data at the specified frequency.

<DataSourceModuleType ID="Microsoft.Windows.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.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 contains the definition of Probe’s base module type, Microsoft.Windows.RegistryProbe. The module implementation of this probe action module type is written in native code. The top of an ancestry chain that contains composite modules always ends with either a native or managed module implementation.

<ProbeActionModuleType ID="Microsoft.Windows.RegistryProbe" Accessibility="Public">
  <Configuration>
    <IncludeSchemaTypes>
      <SchemaType>Microsoft.Windows.RegistryAttributeDefinitionsSchema</SchemaType>
    </IncludeSchemaTypes>
    <xsd:element name="ComputerName" type="xsd:string" />
    <xsd:element name="RegistryAttributeDefinitions" type="RegistryAttributeDefinitionsType" />
  </Configuration>
  <ModuleImplementation>
    <Native>
      <ClassID>472364F2-A1F0-41C0-9A8F-E00C92C2AB31</ClassID>
    </Native>
  </ModuleImplementation>
  <OutputType>Microsoft.Windows.RegistryData</OutputType>
  <InputType>System!System.BaseData</InputType>
</ProbeActionModuleType>

See Also

Reference

MemberModules (DataSourceModuleType)
ProbeAction (ProbeActionModuleType)
ProbeActionModuleType