– (Part 1 – Part 2 – Part 3 – Part 4)
I have written a managed code module for tracing the data items moving through a workflow. This is a four-part article that presents the module in the fourth part. If you are familiar with workflows, modules, and data items (the first three posts, respectively), you can go straight to the fourth article. If not, please read on… Even if you are familiar with these topics, you may enjoy this presentation of them and I would certainly welcome and appreciate any feedback.
The heart and soul of OpsMgr 2007 is undoubtedly the workflow engine. This is one of the most basic functions of the Health Service: to implement the policy received from the management group by running the workflows described therein. Discoveries, rules, and monitors are all workflows. They are also therefore each comprised of modules that are run in a particular order to achieve the desired result. Consider an example of each:
- A discovery might be comprised of a timer module that executes a script at some interval. The script, in turn, pulls some WMI data (for example). That “data item” may then be passed to a condition detection module that evaluates it against some condition (e.g. that the WMI data contains certain properties). Provided those conditions are met, the data item may then be passed to another condition detection module that maps the WMI data item to another data item in the specific OpsMgr discovery data format for a particular class (e.g. Windows.Computer). This is essentially the output of the sequence. This sequence effectively results in an instance of some class being created or updated. That’s a workflow.
- Another example would be a monitor. A monitor might consist of timer module that runs a script on a schedule. The script in this case, in turn, pulls some instrumentation data from some interesting data source (e.g. the management software that interfaces with the building environmental monitor system). That data item is then passed to any number of different sequences of modules. This is very well defined: one sequence for each possible state of the object (health, warning, critical, etc.). It is assumed that only one of these sequences will pass all of the conditions and generate output data at any given moment. The sequence that generates output data tells OpsMgr to which state the targeted object should transition (if it is in some other state). This is another workflow.
- The final example is a rule. A rule will usually start in a similar way to the other two examples: some trigger or timer starts a sequence of modules in motion. At some point, some data source or probe will produce some data item. Any number of condition detection modules may manipulate the data item, transform it, or suppress it. In the case of a rule, any number of “write action” modules will then accept the data item and do something with it. For example, just about every rule includes one of the following four write actions: generate alert, set some monitor’s state, write to operational DB, or write to datawarehouse. Rules are not required to use these nor is that by any means an exhaustive list. This is just meant to give you an idea of how a rule is a collection of modules. And it’s also a workflow.
In fact, every major monitoring- and operations-related activity of the Heatlh Service is a workflow. These include all discoveries, monitors, diagnostics, recoveries, rules, and agent tasks.
Understanding workflows is key to understanding OpsMgr 2007. You should understand what they are, that most major functions of OpsMgr are workflows, and that a workflow is essentially a pipeline of modules.
In the part 2 of this series, I will discuss those modules in more detail.