Passing data with parameters

Applies To: System Center Operations Manager 2007

Most modules and monitor types will have parameters in order to accept information from the defined workflow and from other modules in the data stream. Workflows and composite modules must provide values for the required parameters of the modules that they contain and may provide values for optional parameters.

Values and Variables

Values that are provided to parameters will be a combination of explicit values, $Config variables, $Target variables, and $Data variables. Each of these is discussed in the following sections with recommendations on when each should be used.

Explicit Values

Explicit values for parameters are just values that do not change regardless of the target object or incoming data. Examples include the threshold value for a monitor, an event number that indicate a particular error, or the interval that a script should run.

Explicit values are typically provided by workflows to monitor types and modules. For example, a module running a timed script will require a parameter defining how frequently it should run. A rule that uses this module would have to provide an explicit value such as 900 seconds. This means that the module would run every 15 minutes. In this context, a variable wouldn’t make any sense, and all copies of the workflow would be run on the same 15-minute schedule.

The definition of modules and monitor types will also use explicit values for parameters where a particular value will not change. For example, a composite module might be created in order to share a particular script between rules and monitors. One of the modules that is contained by this composite module would be responsible for running the script. Values for parameters that are required by this module, such as the name of the script and the body of the script, would not vary between different target objects and would be explicitly defined in the definition of the module.

$Target Variables

$Target variables refer to the value of a property on the target object or one of the target object’s hosting parents. These values are collected by the discovery process for the target class and will not be known when the workflow is defined. The workflow will also run against all instances of the target object, and each may have a different value for the particular property.

$Target variables are most frequently used by workflows sending values to monitor types and modules that accept the value that uses a $Config variable. For example, a rule collecting a performance counter might be targeted at a class where multiple instances are expected on each agent. To distinguish each collected value, the instance name of the performance data could be populated with the name or some other key property of each object. This value would be provided through a $Target variable that would provide a unique value for each target object.

$Data Variables

$Data variables refer to some value from the data incoming from the previous module. The format of the variable will depend on the type of data being used. Example uses of $Data variables are in expressions that inspect the incoming data to determine whether some action should be taken, in the mapping of data from one type to another, and in write action modules generating alerts where incoming data values are used in the alert description.

For example, a common scenario is a monitor that runs a script and uses the resulting data to determine the health state of the target object. The workflow for each state (of the possible health states) would use a condition detection module with an expression comparing the resulting data to different specified values. These expressions would use a $Data variable to access the required value.

$Config Variables

$Config variables are used to reference the value that is provided to the module or monitor type that contains the particular module. Values for parameters of a module inside a composite module will typically be either explicit values or $Config variables. This is a means of having the workflow provide the value for a parameter that is then passed to a module inside the composite module.

Although parameters that are passed through to contained modules typically map directly between parameters, this is not a requirement. $Config parameters can actually be used to hide the complexity of underlying parameters from the workflow. This can be valuable in providing users with more straightforward parameters exposed to overrides. For example, consider a composite module that contains the data source module Microsoft.TimedScriptPropertyBagProvider. That module has a parameter called Arguments that requires the arguments line that is provided to the script when it is run. The script may require several parameters, not all of which should be overridden by the end-user. Instead of defining a parameter called Arguments on the composite module, a separate parameter could be provided for individual arguments. The Arguments parameter on the module would be composed of multiple $Config variables.

Overrideable Parameters

Users of a management pack can change the values being passed to modules in the workflow by using overrides. Only parameters that are specified as overrideable are available to be overridden. The user may not change the value of any other variables. The definition of parameters that can be overridden is not made on the workflow itself but is made on the module or monitor type that the workflow is based on. In the Authoring console, parameters that can be overridden are specified on the Overrideable Parameters tab of the module properties.

Some parameters are always available to be overridden and do not have to be specified. These are available to the user as parameters that can be overridden but are not specified as parameters on the module or monitor type.

The following table shows workflows that have the following parameters that can be overridden.

Any monitor or rule that creates an alert has several parameters specific to the alert that can be overridden. The following parameters on rules that generate alerts can be overridden:

As shown in the following table, monitors that generate alerts will have these parameters:

Sample Workflow

The following sample workflow shows the different values and variables provided to the parameters of different modules. This represents a rule based on a script collecting performance data. The script requires two arguments for the name of the computer and the name of the component that the module is running against. The script itself is included in a probe action module. This module is used in a data source module that adds a scheduler in order to run the script on a timed basis. This data source module is then included in another data source module that maps the property bag from the script to performance data.

Although this may seem to be a complex strategy that uses three different modules for functionality that might be completed by using a wizard in the Authoring console, it is actually a common strategy to support multiple scenarios sharing the same script. The probe action module could be used in a task or in on-demand detection for a monitor. The two data source modules could be used in a rule or regular detection for a monitor. Each provides a different kind of output that depends on the requirements for the particular workflow.

The custom probe action module uses Microsoft.Windows.ScriptPropertyBagProbe (alias Script) to run the actual script, as is shown here.

Custom probe action module

The following table lists the values that are provided for the parameters to the module:

The first data source module uses System.Scheduler (alias Schedule) followed by the custom probe module (alias Probe). This is shown here:

Custom data source module outputting property bag

The values that are provided for the parameters to the modules are shown on the following table:

The second data source module uses the first data source module (alias Script) followed by the condition detection module System.Performance.DataGenericMapper (alias MapToPerf), as illustrated here.

Custom data source module outputting property bag

The following table shows the values that are provided for the parameters to the modules:

The rule uses the second data source module (alias DS) followed by two write action modules to store the data in the Operations Manager database and the data warehouse. There is no requirement for a condition detection module in the rule because the required modules for filtering and mapping to a different data type were included with composite modules. The write action modules do not require any parameters. This is shown here:

Custom rule

The values that are provided for the parameters to the module are shown in the following table: