Module Implementations

Applies To: System Center Operations Manager 2007

All modules are implemented in one of the following three ways:

• Native code

• Managed code

• Composite

As their names imply, managed code modules and native code modules represent managed code and native code installed on the agent computer. These modules are defined in management packs but must be installed separately on the agent computer. Modules that are defined in library management packs are installed automatically with the Operations Manager agent. The definition of a native module in the management pack just includes its Class ID. Managed modules include the details of their assembly. Creation or modification of native modules and managed modules is not supported, but those included in library management packs are available that can be used by modules and workflows in other management packs.

Composite modules are composed of one or more other modules. Composite modules are included in library management packs, and custom composite modules may be defined by management pack authors for performing custom logic. Composite modules require no installation on the agent computer and are completely defined in a particular management pack. They may include native code modules, managed code modules, other composite modules, or any combination of such modules.

There is no difference between using modules with different implementations in a workflow or composite module. In fact, any workflow using a particular module is unaware how it is implemented or the details of how its functionality is performed. The workflow just has to know what function the module performs, its input data type requirement (if any), its output data type (if any), and its required parameters.

If you inspect the modules in a composite module and then continue to inspect any one of those modules that are composite, you will eventually drill down to a native or managed code module. These are the modules that perform core functionality on the agent whereas composite modules provide different variations on this functionality.

Composite Module Example

To explain the concept of composite modules, the following diagram shows an example of a module included in the Microsoft Windows Library management pack. This is a common data source module named Microsoft.Windows.TimedScript.PropertyBagProvider. The function of this module is to run a script on a regular timed basis and return the results as a property bag. If you create a rule or monitor based on a script that uses a wizard in the Authoring console, this is the data source module that will be used in the resulting workflow.

Windows Timed Script Property Bag module

This module is a composite module that is actually composed of two other modules as follows:

The System.SimpleScheduler module is a data source module that sends a trigger at set intervals. It requires parameters specifying the schedule that will be followed.

Microsoft.Windows.ScriptPropertyBagProbe is a probe action module that runs a specified script returning the output as a property bag. Because it is a probe action, it requires a trigger to start. That trigger is provided by the System.SimpleScheduler data source module. This module needs parameters for such information as the name of the script, the script body, and its arguments.

Both of the modules included in this composite module are composite modules themselves. However, this knowledge is not required in order to use them. The composite module that contains them just has to know what function the module will perform, what parameters it requires to perform that function, what input data type it requires, and what output data type it will generate. The internal details of how it performs this functionality are not relevant.

Another module in the same management pack library Microsoft.Windows.TimedScript.PerformanceProvider uses Microsoft.Windows.TimedScript.PropertyBagProvider but then maps its output from a property bag to performance data. This is performed by adding a condition detection module System.Performance.DataGenericMapper.

Windows Timed Script Performance module

The advantage of this strategy is that the management pack author can select the module with the type of data output that is required. Instead of duplicate functionality in the management pack libraries, one module can just build on another. This same strategy can be leveraged in creating custom modules and workflows.

Sample Workflow with Composite Modules

To additionally explain this concept of composite modules and how they can all be traced back to native or managed code modules, the following diagram shows a sample workflow from the SQL Server 2008 management pack. This is a rule named Microsoft.SQLServer.2008.Database.DBSpaceFree.Collection that runs a script to collect the free space for databases on a SQL Server 2008 instance.

The workflow has a single data source module named Microsoft.SQLServer.2008.DBSizeOptimizedPerfProvider that runs the required script, formats it into performance data, and optimizes it for efficient collection. Then it stores the collected data into the Operations Manager database and the data warehouse using two write action modules.

SQL DB Size Optimized Performance rule

Each of the write action modules are native modules. Neither requires any input parameters but can just work with performance data output from the previous module. The data source module is a custom composite module in the same management pack. That module is shown in the following diagram. It uses another data source module named Microsoft.SQLServer.2008.DBSizeRawPerfProvider that collects the free space data and outputs it as performance data. This data is sent to a native condition detection module System.Performance.OptimizedCollectionFilter that optimizes the collected performance data. Its function is to determine whether the collected value has deviated sufficiently from the previously collected value in order to pass it along for collection.

SQL Server Database Size Optimized module

Microsoft.SQLServer.2008.DBSizeRawPerfProvider is another composite module made up of three modules. The first is a data source module that runs the script on a regular schedule and sends output as a property bag. This is followed by a condition detection module that maps the property bag data to performance data. A second condition detection module filters the property bag according to the database name. This is required because the script returns multiple property bags, one for each database on the SQL instance. This strategy is used to support Cookdown, which is discussed in a separate section. The two condition detection modules are native modules, and the data source module is the same composite module discussed previously.