Designing Custom Modules and Workflows

Applies To: System Center Operations Manager 2007

Many workflows, such as rules, monitors, and discoveries, can be created using wizards in the Authoring console. When these wizards are used, minimal knowledge of the underlying modules and data stream is required. The Authoring console wizard helps you construct a workflow addressing a specific scenario with minimal input from the user. The wizard does this by selecting from a specific set of modules and by using user-specified information for parameters. Once the workflow is created though, the individual modules can be viewed and changed as if it was created manually.

The Authoring console does provide functionality for manually creating workflows, although some modules may require direct editing of the XML by using an editor. When a custom workflow is created, you have to select the individual modules that will be used and provide values or variables for their parameters. Depending on the kind of workflow you are creating, there may be other considerations also, as identified in the following sections.

When to Create a Custom Workflow

Functionality Not Provided with Wizard

The wizards in the Authoring console create workflows based on a specific set of scenarios. If you must have logic outside these scenarios, you must create a custom workflow. The workflow may use custom modules or the workflow may be composed completely of modules from management pack libraries.

For example, the Authoring console provides a number of complex scenarios for wizards that use events. These include correlating multiple events, detecting missing events, and waiting for multiple occurrences of the same event. These options are not provided for rules however, and those wizards are limited to more basic scenarios. A custom rule would have to be created to use any of this logic. The rule could be created from the identical set of modules used by the monitor types that the wizards are based on.

Custom Modules

Wizards in the Authoring console use specific modules that are defined in management pack libraries. If a workflow requires a custom module, you have to create a custom workflow. Those reasons why you might create a custom module are detailed in Custom Module Types.

A common scenario for a custom workflow is to share a script between a monitor and a rule with the monitor measuring health state and the rule collecting data for reporting and analysis. This scenario is achieved by creating a custom data source module or probe module to contain the script and then creating a custom rule, custom monitor type, and custom monitor to use the new module.

Windows PowerShell

Operations Manager 2007 R2 includes modules for running Windows PowerShell scripts. There are no wizards in the Authoring console that will take advantage of these modules, so they may only be accessed by creating a custom workflow.

When to Create Custom Modules

If an existing module will achieve the requirements for a particular workflow, it can typically be used without creating a custom module. A custom composite module may be useful to address the conditions described here.

Share Common Logic between Different Workflows

A single module can be used by multiple workflows. If a script or some other complex logic has to be shared by multiple workflows, a custom module can be created to encapsulate the logic. Instead of implementing the logic separately in each workflow, the custom module can be shared by each.

For example, consider a script that is used to collect performance data for a particular application. A monitor could be used to set the health state of a monitored object according to the collected data’s comparison with a particular threshold. In addition, a rule could be used to collect the performance data for analysis and reporting. Without a custom module, the script would have to be individually provided as a parameter to an existing module in both the rule and the monitor. If that script were included in a custom module however, it might be shared by both the monitor and the rule. The script would only have to be created and maintained in one location in the management pack.

Implement Complex Logic Not Possible with Existing Modules

Custom workflows can be created to implement complex logic with existing modules. However, different kinds of workflows have specific requirements as to the types and number of modules that they contain. If the logic cannot be created within these restrictions, custom modules can be created to encapsulate this logic and make it valid for the particular workflow.

For example, a particular discovery might require a data source module in addition to a condition detection module. However, a discovery is allowed only a single data source module. A custom module could be created that contains the required data source and condition detection modules. The discovery would use the custom data source module without exposure to the modules that it contained.

Improve Override Experience

Custom modules can define parameters that accept values from the workflow. These are exposed to the end-user of the management pack through overrides where they can be changed. If a particular module has a complex parameter that may not be intuitive to the user, the module may be wrapped in a composite module that provides more intuitive parameters. The values are then passed on to the required parameters through $Config variables.

For example, the modules to run a script will typically have a parameter called Arguments that contains a space- delimited list of arguments to be provided to the script. If the user needed to override one or more of these values, they would have to be exposed to the complete Arguments parameter and determine which particular part of it needed to be modified. For a script that uses multiple arguments, the required formatting will most likely not be intuitive to the end-user. An alternative strategy would be to create a custom module with parameters by using descriptive names. This module would contain the module running the script that would build the Argument parameter through the appropriate combination of $Config variables.