Scripts Supporting Cookdown

Applies To: System Center Operations Manager 2007

Note

This exercise has been updated to include a procedure for Visual Studio Authoring Extensions in the latest version of the Management Pack Authoring Guide on the TechNet Wiki.

Frequently, a script in a data source module will require the value of a property from the target object. The most straightforward method of providing this value would be to use a $Target variable in a parameter to the module, but then cookdown cannot be performed. The method for supporting this type of scenario is to have the script collect information for all instances of the target class and return a property bag for each. Because the script itself becomes responsible for identifying the values of the individual properties, you do not have to provide them through parameters to the module. Because there are no $Target variables in the parameters, cookdown is preserved.

Multiple Property Bags

For the script to perform cookdown, it will frequently re-create some basic logic used in a discovery script for the target class. The discovery script is typically responsible for identifying the different instances and collecting values for the different properties. Whereas adding this logic makes the script itself more complex and requires more overhead than a script written for only a single instance, the script has the advantage of supporting cookdown. One copy of the script running for all instances of the target class typically generates significantly less overhead than multiple copies of a script running for each single instance.

A script can return multiple property bags by using the ReturnItems method on the MOM.ScriptAPI object instead of Return. This returns a single property bag. When a script returns multiple property bags, each one is collected and processed by the next module in the workflow. If a method of filtering is not used, each workflow will incorrectly complete for each instance. This can result in unwanted situations such as all monitors going to an error state when an error condition is detected on a single instance or collecting multiple duplicate performance values for each instance.

To have a workflow filter for the property bag matching its target instance, a condition detection module is used after the data source module or probe action module running the script. This condition detection module uses a $Target variable for the key property of the target instance. The property bag itself must include the same value in one of its properties. The condition detection is then able to match the value from the property bag to the value of the $Target property to let each copy of the workflow to select the property bag specific to its particular instance. This concept is illustrated in the following diagram.

Workflow supporting cookdown

The module Microsoft.SQLServer.2008.DBSizeRawPerfProvider described in Module Implementations provides an example of a script creating multiple property bags to support cookdown. The DatabaseName of the target instance is sent to the module; the name is not passed to the Microsoft.Windows.TimedScript.PerformanceProvider module which runs the actual script. This module can cookdown to a single instance, although the modulecreates a separate property bag for each database. Each property bag includes a value for the name of the database. The value of the DatabaseName parameter is sent to the System.Expression module that compares it to the value in the property bag. Using this method, all instances of a workflow on a particular agent that uses this module will be able to share a single copy of the data source module yet will be able to select only the property bag specific to the particular instance.

The following is a simplified view of the Microsoft.SQLServer.2008.DBSizeRawPerfProvider module showing this concept.

SQL Database Raw Performance module using cookdown