Module and Workflow Basics

Applies To: System Center Operations Manager 2007

A workflow in Operations Manager 2007 refers to a running process that is defined in a management pack and run by the Operations Manager agent. Examples of different kinds of workflows are monitors, rules, and discoveries. The primary job of the Operations Manager agent is to load and run workflows defined by the management packs relevant to the applications installed on the agent.

Workflows are composed of one or more modules. A module in Operations Manager performs a discrete function based on information that is provided to the module through parameters. For example, a module may detect an event, collects a particular performance counter, runs a script, or generates an alert. A workflow can achieve complex functionality by piecing together different modules that perform different required actions.

Wizards in the Authoring console let workflows such as monitors and rules be created without direct knowledge of the modules that they will use. These wizards address a limited set of specific scenarios, but with knowledge of the underlying structures, custom workflows can be made up from any valid combination of available modules to achieve specific functionality.

Modules

Management pack libraries contain many modules that are individually documented in the Module Types Reference section of the Operations Manager 2007 Management Pack Development Kit (MPDK). These modules may be used to compose custom workflows or to create custom modules required for specific functionality in a management pack.

A sample module is illustrated in the following diagram. The module is included in the Microsoft Windows Library management pack and has the name Microsoft.Windows.TimedScript.PropertyBagProvider. The function of this module is to run a script according to a specified schedule and return the output in the form of a property bag.

Module

The module can be inspected by opening the Windows Core Library management pack in the Authoring console. Detailed documentation for the module is provided in the MPDK under Microsoft.Windows.ScriptProbeAction. The reason that the module does not have its own topic is that it and other modules make use of the Microsoft.Windows.ScriptProbeAction module. Instead of providing separate documentation for each module, the MPDK groups similar modules under a common topic.

To perform its required function, the module requires a set of parameters that specify such information as the script itself and how frequently the script should be run. Any output from the script is formatted as a particular data type and sent into the data stream, where the output is retrieved by the next module in the workflow. These concepts are detailed in the following sections.

Module Parameters

Most modules will require one or more parameters. These parameters are values that the module requires in order to perform its required functionality. Explicit values may be provided for these parameters, or they may be $Target or $Data variables that are determined at run time. A parameter can be defined to be required or optional. Any workflow or composite module that uses a module must provide values for each of its required parameters.

The following table lists the parameters for the previous sample module:

The list of parameters for a particular module is available by viewing its management pack in the Operations console or an XML editor. When a module is used in the Authoring console, its list of required parameters will be automatically populated. If optional parameters are used, they must be added manually.

Data Stream

Modules in a workflow exchange data through a data stream. Data sent from one module is accepted by the next module in the workflow. The receiving module is expected to perform some function by using the received data and then potentially sending its own data as output where it may be accepted by another module.

Each workflow has its own data stream that is created when the workflow runs. If there are multiple copies of a particular workflow running on an agent, each will have its own data stream.

Data Types

Data output from a module will match a particular data type, and modules that accept data will require a particular type of data for input. When composing a workflow, you must make sure that the output data type of one module matches the required input data type of the next module. If they do not match, another module can be used to translate from one type to another.

The previous example module above sends output data in a property bag. Any module receiving this data in a workflow would be required to accept property bag data as input. If a module requiring another data type were used, for example, performance data, another module would be required in the workflow to map the property bag to the required data type.

Workflows

The following diagram shows a sample workflow. This particular sample represents a rule that runs a script and collects performance data in the Operations Manager database. It uses three modules to perform this function. The following diagram shows the parameters that are required for each module and the data type for the output and input of each.

Workflow

The first module is Microsoft.Windows.TimedScript.PropertyBagProvider that was introduced in the previous module example. This module requires values for the listed parameters, which include how frequently the script should run, the name and body of the script, and a set of arguments that will be sent to the script. The values for these parameters would be provided by the configuration of the workflow itself.

The final module Microsoft.SystemCenter.CollectPerformanceData accepts performance data from the data stream and stores it in the Operations Manager database. Because the output from the first module is a property bag, a separate module is required to map data from a property bag to performance data.

The second module in the workflow System.Performance.DataGenericMapper provides the required mapping between data types. This module can accept any input data type and output performance data. In order to perform this function, it requires the parameters that are shown in the diagram. The object name and counter name would presumably be static values, although the instance, if provided, would probably come from a value in the property bag or from a $Target variable using the value of a property on the target object to uniquely identify the instance. The value for the data would most likely come from a value from the property bag that was calculated during execution of the script.

The final module Microsoft.SystemCenter.CollectPerformanceData requires no parameters. As long as the data is provided to the module from the data stream, the module has all the information that it requires to save that data to the Operations Manager database.

Workflow Targets

Every workflow requires a target class which defines the agents the workflow will run on and how many copies of the workflow will be run.

A separate copy of a workflow is loaded by an agent for each instance of the target class managed by the agent. If an agent has no instances of the target class, the workflow is not loaded. If the agent has multiple instances of the target class, multiple copies of the workflow are loaded. Each copy of the workflow runs independently of the others and will have its own data stream and its own set of property values.

Explicit values that are provided for parameters that are passed to modules in the workflow are common for all copies of the workflows. $Target variables will resolve to different values depending on the values of the properties for the individual target instances.