MemberModules (ProbeActionModuleType)

아티클
05/16/2012

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

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

Schema Hierarchy

ManagementPack
  TypeDefinitions
    ModuleTypes
      ProbeActionModuleType
        ModuleImplementation (ProbeActionModuleType)
          Composite (ProbeActionModuleType)
            MemberModules (ProbeActionModuleType)

Syntax

<MemberModules>
   <ProbeAction>…</ProbeAction>
   <ConditionDetection>…</ConditionDetection>
</MemberModules>

Attributes and Elements

The following sections describe attributes, children, and the parent element of the MemberModules element.

Attributes

None.

Child Elements

Element	Description
ConditionDetection (ProbeActionModuleType)	Optional element. The implementation of a predefined ConditionDetectionModuleType module. A probe action type’s internal workflow can end with any number of ConditionDetection (ProbeActionModuleType) modules.
ProbeAction (DataSourceModuleType)	Required element. Must be the first element in the internal workflow. The implementation of a predefined ProbeActionModuleType module.

Parent Elements

Element	Description
Composite (ProbeActionModuleType)	Contains the module implementations and linear workflow composition in a module type definition.

Remarks

The MemberModules element of a ProbeActionModuleType module contains the modules that are used to structure its internal workflow. A workflow that comprises a probe action module type must take input in order to trigger the probe action. If the TriggerOnly element is true, the probe action module type does not use the input data and will not include an OutputType (DataSourceModuleType) element.

The probe action module type must output data of the type defined in the OutputType (ProbeActionModuleType) element. Because a probe action module type definition must always return data for use by the next module in the external workflow, its MemberModules element does not include modules that are of the WriteActionModuleType definition. Write action module type definitions never return any data and must always be the last module in a workflow. The last module in a probe action module type workflow must either be a ProbeAction (DataSourceModuleType) or a ConditionDetection (ProbeActionModuleType) module. The first module in a probe action module type must be a ProbeAction (ProbeActionModuleType) module.

The ID attribute of each member module must be unique only in the scope of the module type, not the management pack.

Example

In the following sample, a composite probe action module modularizes the functionality of a ProbeAction module and a ConditionDetection module. In this case, the Microsoft.Windows.ProductInstallationProbe module contains a probe that is used to query WMI at a certain interval. The condition detection module filters on the ProductCode value that was passed in through the configuration parameter. The module will return System.PropertyBagData if the filter the condition detection satisfies the filter.

<ProbeActionModuleType ID="Microsoft.Windows.ProductInstallationProbe" Accessibility="Public">
  <Configuration>
    <xsd:element name="ComputerName" type="xsd:string" />
    <xsd:element name="ProductCode" type="xsd:string" />
  </Configuration>
  <OverrideableParameters>
    <OverrideableParameter ID="ComputerName" ParameterType="string" Selector="$Config/ComputerName$" />
    <OverrideableParameter ID="ProductCode" ParameterType="string" Selector="$Config/ProductCode$" />
  </OverrideableParameters>
  <ModuleImplementation>
    <Composite>
      <MemberModules>
        <ProbeAction ID="WmiProbe" TypeID="Microsoft.Windows.WmiTriggerProbe">
          <NameSpace>\\$Config/ComputerName$\Root\CIMv2</NameSpace>
          <Query>SELECT * FROM Win32_Product</Query>
        </ProbeAction>
        <ConditionDetection ID="FilterOnProductCode" TypeID="System!System.ExpressionFilter">
          <Expression>
            <SimpleExpression>
              <ValueExpression>
                <XPathQuery Type="String">Property[@Name='IdentifyingNumber']</XPathQuery>
              </ValueExpression>
              <Operator>Equal</Operator>
              <ValueExpression>
                <Value Type="String">$Config/ProductCode$</Value>
              </ValueExpression>
            </SimpleExpression>
          </Expression>
        </ConditionDetection>
      </MemberModules>
      <Composition>
        <Node ID="FilterOnProductCode">
          <Node ID="WmiProbe" />
        </Node>
      </Composition>
    </Composite>
  </ModuleImplementation>
  <OutputType>System!System.PropertyBagData</OutputType>
  <TriggerOnly>true</TriggerOnly>
</ProbeActionModuleType>

Each module referenced in the MemberModules element has access to the composite module’s configuration parameter values. In this case, the ComputerName and ProductCode parameter values are used to fulfill the parameter requirements of the member module configuration parameters. To retrieve the value of a module’s encapsulating parent parameter, use the $Config variable notation. For more information about the $Config variable notation, see $Config.

For a composite probe action module type, the output type will be the same as the output type of the last module type in the composition workflow. If you are defining a new probe action module type for use in discovery, your composition must output discovery data (System.Discovery.Data type defined in the System.Library management pack).

다음을 통해 공유