Parameter replacements (part 1)

  • Article

Management packs contain definitions of rules, monitors or composite module types where those monitoring objects need to be configured. In the configuration of the module type, in addition to providing constant values, you can also provide variable context parameter.

All Context parameters can be used in any part of a text and replaced by the runtime with the actual parameter value before the module is instantiated. Context parameters are specified within “$” delimiter in a text. If you want to escape the delimiter, you can use “$$”.

Config Context Parameters

Syntax

$Config/<relative xpath of the configuration parameter>$

Where Used:

1. In the implementation of composite module types, the configuration of the member modules can use the configuration of the composite module types as a context.

<DataSourceModuleType ID="HealthService.EventProvider" Accessibility="Internal">

  <Configuration>

    <xsd:element name="ComputerName" type="xsd:string" minOccurs="0" maxOccurs="1" />

  </Configuration>

  <ModuleImplementation>

    <Composite>

      <MemberModules>

        <DataSource TypeID="Windows!Microsoft.Windows.EventProvider" ID="DS">

          <ComputerName >$Config/ComputerName$ </ComputerName>

          <LogName>Operations Manager</LogName>

          <Expression>

            <SimpleExpression>

              <ValueExpression>

                <XPathQuery Type="String">PublisherName</XPathQuery>

              </ValueExpression>

              <Operator>Equal</Operator>

              <ValueExpression>

                <Value Type="String">HealthService</Value>

              </ValueExpression>

            </SimpleExpression>

          </Expression>

        </DataSource>

      </MemberModules>

      <Composition>

        <Node ID="DS"/>

      </Composition>

    </Composite>

  </ModuleImplementation>

  <OutputType>Windows!Microsoft.Windows.EventData</OutputType>

</DataSourceModuleType>

2. In the implementation of unit monitor, alert parameter can use the configuration of the monitor as context.

<UnitMonitor ID="SpoolerServiceMonitor" Accessibility="Internal" Target="Windows!Microsoft.Windows.Computer" TypeID="Custom.ServiceMonitor" ParentMonitorID="Health!System.Health.AvailabilityState">

  <Category>AvailabilityHealth</Category>

  <AlertSettings AlertMessage="ServiceMonitor.AlertMessage">

    <AlertOnState>Error</AlertOnState>

    <AutoResolve>1</AutoResolve>

    <AlertPriority>Low</AlertPriority>

    <AlertParameters>

      <AlertParameter1> $Config/ServiceName$ </AlertParameter1>

    </AlertParameters>

  </AlertSettings>

  <OperationalStates>

    <OperationalState HealthState="Success" MonitorTypeStateID="Running" ID="Success"></OperationalState>

    <OperationalState HealthState="Error" MonitorTypeStateID="NotRunning" ID="Error"></OperationalState>

  </OperationalStates>

  <Configuration>

    <ServiceName>Spooler</ServiceName>

  </Configuration>

</UnitMonitor>

This example shows that runtime can replace this context parameter ( $Config/…$ ) as long as relative XPath to configuration parameter exists (and yields a result). Although one could argue there is a chace to simply type “Spooler” twice in this example rather than use context parameter. Using replacement off course makes sense if <ServiceName> is defined as override-able on monitor type (Custom.ServiceMonitor), in which case $Config/ServiceName$ would pick overridden value rather than constant defined during the monitor creation.

Note:

Check back as I will continue describing other context parameters as well ($Target,$Data …)