WriteAction (Rule)

Article
05/16/2012

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

Represents an implementation of a write action module type definition.

Schema Hierarchy

ManagementPack
  Monitoring
    Rules
      Rule
        WriteActions
          WriteAction (Rule)

Syntax

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

Attributes and Elements

The following sections describe attributes, child elements, and the parent element of the WriteAction 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 WriteAction module type definition from which this WriteAction module inherits its configuration schema.

ID Attribute Values

Value Description

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 WriteAction module’s containing workflow. The ID is case-sensitive.

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 WriteAction module’s containing workflow.
The ID is case-sensitive.

Child Elements

The child element of the WriteAction module is defined by the configuration schema of its base type as referenced in the TypeID attribute.

Parent Elements

Element	Description
WriteActions	Contains one or more write action modules.

Remarks

A WriteAction module takes a single input data stream. It uses this data stream, perhaps in conjunction with some kind of condition detection, to affect system state in some way. This change could be in the monitored system or in Operations Manager itself. For example, a write action module might run a script that changes something, writes data into the Operations Manager database, or generates an alert.

A write action module’s base type must always be a descendant of a WriteActionModuleType type. Write action modules are used only at the end of a workflow because they do not return a data for processing to another module. When they do return data, they do so only so that it can be sent to the Operations database or sent to standard output.

Example

The following sample illustrates a rule that runs wmiadap.exe once a day. This workflow consists of a data source module and a write action module.

<Rule ID="Microsoft.Windows.Server.2008.Computer.RunWMIAdap" Enabled="false" Target="Server2008!Microsoft.Windows.Server.2008.Computer">
  <Category>Maintenance</Category>
  <DataSources>
    <DataSource ID="Scheduler" TypeID="System!System.Scheduler">
      <Scheduler>
        <SimpleReccuringSchedule>
          <Interval Unit="Days">1</Interval>
        </SimpleReccuringSchedule>
        <ExcludeDates />
      </Scheduler>
    </DataSource>
  </DataSources>
  <WriteActions>
    <WriteAction TypeID="System!System.CommandExecuter" ID="DS1">
      <ApplicationName><![CDATA[%windir%\system32\cmd.exe]]></ApplicationName>
      <WorkingDirectory />
      <CommandLine>/c wmiadap.exe /F</CommandLine>
      <TimeoutSeconds>300</TimeoutSeconds>
      <RequireOutput>true</RequireOutput>
      <Files />
    </WriteAction>
  </WriteActions>
</Rule>

The second sample demonstrates a rule whose workflow runs a counter on the target’s host (a Windows-based computer) either when five minutes have elapsed and the counter has a change delta of 1 or when an hour has elapsed with no change to the counter. If data is retrieved by the data source module, the performance data is then committed both to the Data Warehouse and to the Operations Manager database.

For more information about the data source module in this sample, see System.Performance.OptimizedDataProvider.

The data source module uses $Target/Host and $Target/Property notation to retrieve contextual data from the rule’s target, Microsoft.Windows.Server.2008.LogicalDisk. For more information, see $Target.

<Rule ID="Microsoft.Windows.Server.2008.LogicalDisk.AvgDiskQueueLength.Collection" Enabled="onStandardMonitoring" Target="Server2008!Microsoft.Windows.Server.2008.LogicalDisk">
  <Category>PerformanceCollection</Category>
  <DataSources>
    <DataSource ID="PerformanceDS" TypeID="SystemPerf!System.Performance.OptimizedDataProvider">
      <ComputerName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
      <CounterName>Avg. Disk Queue Length</CounterName>
      <ObjectName>LogicalDisk</ObjectName>
      <InstanceName>$Target/Property[Type="Windows!Microsoft.Windows.LogicalDevice"]/DeviceID$</InstanceName>
      <AllInstances>false</AllInstances>
      <Frequency>300</Frequency>
      <Tolerance>1</Tolerance>
      <ToleranceType>Absolute</ToleranceType>
      <MaximumSampleSeparation>12</MaximumSampleSeparation>
    </DataSource>
  </DataSources>
  <WriteActions>
    <WriteAction ID="WriteToDB" TypeID="SC!Microsoft.SystemCenter.CollectPerformanceData" />
    <WriteAction ID="WriteToDW" TypeID="SCDW!Microsoft.SystemCenter.DataWarehouse.PublishPerformanceData" />
  </WriteActions>
</Rule>

Share via