Kinds of Workflows

Applies To: System Center Operations Manager 2007

Each kind of workflow in an Operations Manager 2007 management pack must follow specific criteria according to the modules types they can contain. The following sections provide details on each kind of workflow.

Discoveries

Discoveries are a special type of rule that are used for the sole purpose of collecting discovery data to be inserted into the Operations Manager database.

A discovery has only a single data source module that must output discovery data. If more complex logic is required that uses other modules, such as a condition detection, a composite data source module must be created and used by the discovery.

Discovery workflow

Rules

Rules are typically used for one of the following purposes:

• Collect and store data in either the Operations Manager database, the data warehouse, or both.

• Generate an alert based on collected data.

• Run a script or command according to a regular schedule.

A rule is defined by the following:

• One or more data source modules.

• Zero or one condition detection modules.

  A condition detection module is required if more than one data source module is used. In this case, the condition detection module would collect data from the different data source modules in order to produce a single output.

• One or more write action modules.

  Each write action module accepts the same data output from the data source module or the condition detection module if present.

Rule workflow

Tasks

Tasks are workflows that are not loaded by the agent until they are run by an operator.

A task is defined by using a single module. If the task is only collecting information, a probe action module should be used. If the task is modifying the system, a write action module should be used.

Task workflow

Monitors

Monitors are workflows used to determine the state of monitored objects. Each monitor has either two or three potential states and is in a single state at any particular time. Aggregate monitors and dependency monitors derive their states from one or more unit monitors. They are workflows, but their details are not exposed to the management pack author. Unit monitors are the only type of monitor that the management pack author will compose.

Monitor Types

Monitors are based on monitor types. Monitor types define the modules and logic that are used in the workflow. They have parameters like modules so that a single monitor type can be shared by multiple modules with each monitor providing values specific to the particular scenario. Each monitor represents the actual workflow that targets a particular class and provides values to the monitor type parameters.

Monitor and monitor type

A single monitor type can detect state using both regular detection and the optional on-demand detection. Regular detection is the normal operation of the monitor as it continuously polls for information to determine the state of the monitored object. On-demand detection occurs when the monitor is first initialized on an agent, when the monitored object returns from maintenance mode, and when the operator selects Reset Health for the monitor in the Operations console. If on-demand detection is not defined for a monitor type, the state is not immediately set from these events but is defined the next time that regular detection occurs.

Each health state of the monitor has its own workflow. For example, if a particular monitor type has three states and defines both regular detection and on-demand detection, that monitor type will have six different workflows. While the end result of each workflow is to set the state of the same monitor, each workflow operates completely independently of the others. Each one is working to determine whether it should set the state of the monitor to the workflow’s specific state. Because of this, the management pack author must ensure that workflows for different states can never resolve to true at the same time. If this situation does occur, the results on the health state of the monitor are unpredictable.

The workflow for each health state for regular detection for a monitor type is defined by the following:

• Must begin with one or more data source modules.

• May include probe action modules and condition detection modules in any order.

• Only a single data stream can be output. A condition detection module is required if more than one data source module or probe action module is used. In this case, the condition detection module would collect data from the different modules in order to produce a single output.

• May not include a write action module. The only result of a workflow in a monitor type is to set the health state of the monitored object, so there is no purpose for a write action module.

Monitor type regular detection

The workflow for each health state for regular detection for a monitor type is defined by the following:

• Must begin with a probe action module that requires no input data.

• May include probe action modules and condition detection modules in any order.

• Only a single data stream can be output. A condition detection module is required if more than one data source module or probe action module is used. In this case, the condition detection module would collect data from the different modules in order to produce a single output.

• May not include a data source module. Data source modules are not able to operate on demand.

• May not include a write action module. The only result of a workflow in a monitor type is to set the health state of the monitored object, so there is no purpose for a write action module.

Monitor type on demand detection

Diagnostics

Diagnostics are special kinds of tasks that collect information about a particular monitor. Diagnostics can be run automatically when the monitor changes state, or manually by an operator when the monitor is in a given state. It is not intended to make any changes to the system.

A diagnostic is defined by the following:

• Zero or one condition detection module.

• One probe action module.

Diagnostic workflow

Recoveries

Recoveries, just as diagnostics, are special tasks that are triggered by a state change in a monitor. Recoveries can be run automatically when the monitor changes state, or manually by an operator when the monitor is in a given state. Whereas a diagnostic is intended to collect information, the function of a recovery is to try to resolve the problem detected by the particular monitor. Or, a recovery may run only after a particular diagnostic runs and returns data matching specific criteria.

A recovery is defined by the following:

• Zero or one condition detection module.

• One write action module.

Recovery workflow