Share via

WriteAction (WriteActionModuleType)

  • Article

Applies To: System Center Service Manager 2010

[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 write action module type definition.

Schema Hierarchy

ManagementPack
  TypeDefinitions
    ModuleTypes
      WriteActionModuleType
        ModuleImplementation (WriteActionModuleType)
          Composite (WriteActionModuleType)
            MemberModules (WriteActionModuleType)
              WriteAction

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

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

MemberModules (WriteActionModuleType)

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

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 may 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 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 three XML samples illustrate how module type definitions contain and use write action modules. All of the samples can be found in the Microsoft.Windows.Library management pack.

In the first XML sample, a write action module type named Microsoft.Windows.ServiceControlManager.StartService wraps the functionality of a write action module named StartService. The StartService module’s configuration elements are defined by its base type System.CommandExecuter. The Microsoft.Windows.ServiceControlManager.StartService module definition specializes the StartService module by providing two additional parameters in its configuration: ComputerName and ServiceName. The Microsoft.Windows.ServiceControlManager.StartService encapsulates the functionality of a more generic module and hard-codes the configuration parameter values for the StartService module.

<WriteActionModuleType ID="Microsoft.Windows.ServiceControlManager.StartService" Accessibility="Public">
  <Configuration>
    <xsd:element name="ComputerName" type="xsd:string" />
    <xsd:element name="ServiceName" type="xsd:string" />
  </Configuration>
  <OverrideableParameters>
    <OverrideableParameter ID="ComputerName" ParameterType="string" Selector="$Config/ComputerName$" />
    <OverrideableParameter ID="ServiceName" ParameterType="string" Selector="$Config/ServiceName$" />
  </OverrideableParameters>
  <ModuleImplementation>
    <Composite>
      <MemberModules>
        <WriteAction ID="StartService" TypeID="System!System.CommandExecuter">
          <ApplicationName><![CDATA[%WinDir%\System32\sc.exe]]></ApplicationName>
          <WorkingDirectory />
          <CommandLine>\\$Config/ComputerName$ start $Config/ServiceName$</CommandLine>
          <TimeoutSeconds>60</TimeoutSeconds>
          <RequireOutput>true</RequireOutput>
        </WriteAction>
      </MemberModules>
      <Composition>
        <Node ID="StartService" />
      </Composition>
    </Composite>
  </ModuleImplementation>
  <OutputType>System!System.CommandOutput</OutputType>
  <InputType>System!System.BaseData</InputType>
</WriteActionModuleType>

In the second XML sample, you will see how the StartService module’s elements follow the configuration schema defined in its base module, System.CommandExecuter, and you will see that System.CommandExecuter is also a composite module. System.CommandExecuter wraps a WriteAction module whose base is defined as a Native (WriteActionModuleType) implementation module type. The sample illustrates how composite modules can wrap composite modules indefinitely. However, the final module will always be either a native or managed module implementation.

System.CommandExecuter wraps a WriteAction module named Command. Command has a base type of System.CommandExecuterBase. The schema for System.CommandExecuter is identical to the schema defined in System.CommandExecuterBase. The reason System.CommandExecuter wraps the Command module is to provide for an override of the TimeoutSeconds parameter. For more information about overrides, see OverrideableParameter (WriteActionModuleType).

<WriteActionModuleType ID="System.CommandExecuter" Accessibility="Public" Batching="false">
  <Configuration>
    <IncludeSchemaTypes>
      <SchemaType>System.CommandExecuterSchema</SchemaType>
    </IncludeSchemaTypes>
    <xsd:element name="ApplicationName" type="xsd:string"/>
    <xsd:element name="WorkingDirectory" type="xsd:string"/>
    <xsd:element name="CommandLine" type="xsd:string"/>
    <xsd:element name="SecureInput" minOccurs="0" maxOccurs="1">
      <xsd:simpleType>
        <xsd:restriction base="xsd:string">
          <xsd:maxLength value="256"/>
        </xsd:restriction>
      </xsd:simpleType>
    </xsd:element>
    <xsd:element name="TimeoutSeconds" type="xsd:integer"/>
    <xsd:element name="RequireOutput" type="xsd:boolean"/>
    <xsd:element minOccurs="0" maxOccurs="1" name="Files" type="CommandExecuterFilesType"/>
    <xsd:element minOccurs="0" maxOccurs="1" name="DefaultEventPolicy" type="CommandExecuterEventPolicyType"/>
    <xsd:element minOccurs="0" maxOccurs="1" name="EventPolicy" type="CommandExecuterEventPolicyType"/>
  </Configuration>
  <OverrideableParameters>
    <OverrideableParameter ID="TimeoutSeconds" Selector="$Config/TimeoutSeconds$" ParameterType="int"/>
  </OverrideableParameters>
  <ModuleImplementation Isolation="Any">
    <Composite>
      <MemberModules>
        <WriteAction TypeID="System.CommandExecuterBase" ID="Command">
          <ApplicationName>$Config/ApplicationName$</ApplicationName>
          <WorkingDirectory>$Config/WorkingDirectory$</WorkingDirectory>
          <CommandLine>$Config/CommandLine$</CommandLine>
          <SecureInput>$Config/SecureInput$</SecureInput>
          <TimeoutSeconds>$Config/TimeoutSeconds$</TimeoutSeconds>
          <RequireOutput>$Config/RequireOutput$</RequireOutput>
          <Files>$Config/Files$</Files>
          <OutputType>System.CommandOutput</OutputType>
          <DefaultEventPolicy>$Config/DefaultEventPolicy$</DefaultEventPolicy>
          <EventPolicy>$Config/EventPolicy$</EventPolicy>
        </WriteAction>
      </MemberModules>
      <Composition>
        <Node ID="Command"/>
      </Composition>
    </Composite>
  </ModuleImplementation>
  <OutputType>System.CommandOutput</OutputType>
  <InputType>System.BaseData</InputType>
</WriteActionModuleType>

Finally, the following XML sample shows how the System.CommandExecuterBase module wraps a native module.

<WriteActionModuleType ID="System.CommandExecuterBase" Accessibility="Internal" Batching="false">
  <Configuration>
    <IncludeSchemaTypes>
      <SchemaType>System.CommandExecuterSchema</SchemaType>
    </IncludeSchemaTypes>
    <xsd:element name="ApplicationName" type="xsd:string"/>
    <xsd:element name="WorkingDirectory" type="xsd:string"/>
    <xsd:element name="CommandLine" type="xsd:string"/>
    <xsd:element name="SecureInput" minOccurs="0" maxOccurs="1">
      <xsd:simpleType>
        <xsd:restriction base="xsd:string">
          <xsd:maxLength value="256"/>
        </xsd:restriction>
      </xsd:simpleType>
    </xsd:element>
    <xsd:element name="TimeoutSeconds" type="xsd:integer"/>
    <xsd:element name="RequireOutput" type="xsd:boolean"/>
    <xsd:element minOccurs="0" maxOccurs="1" name="Files" type="CommandExecuterFilesType"/>
    <xsd:element name="OutputType">
      <xsd:simpleType>
        <xsd:restriction base="xsd:string">
          <xsd:enumeration value="System.CommandOutput"/>
        </xsd:restriction>
      </xsd:simpleType>
    </xsd:element>
    <xsd:element minOccurs="0" maxOccurs="1" name="DefaultEventPolicy" type="CommandExecuterEventPolicyType"/>
    <xsd:element minOccurs="0" maxOccurs="1" name="EventPolicy" type="CommandExecuterEventPolicyType"/>
  </Configuration>
  <ModuleImplementation Isolation="Any">
    <Native>
      <ClassID>9F96E9EF-EA39-4352-AE5B-E6E0AB20E4CA</ClassID>
    </Native>
  </ModuleImplementation>
  <OutputType>System.CommandOutput</OutputType>
  <InputType>System.BaseData</InputType>
</WriteActionModuleType>

See Also

Reference

MemberModules (WriteActionModuleType)
WriteActionModuleType