– (Part 1 – Part 2 – Part 3 – Part 4)
Now that I’ve given a primer on workflows, it is important to discuss modules a bit. The following discussion is generalized. Modules are nothing if not powerful, flexible, and completely open-ended. Therefore, while I am confident that this discussion will be conceptually helpful, understand that there can be deviations from these generalizations.
First, it’s worth noting that there are four basic module types: Data Source, Probe Action, Condition Detection, and Write Action.
- Data Source and Probe Action modules essentially do some work to collect some attributes of some entity and produce a Data Item. These modules can be thought of as operating on entities extenal to OpsMgr itself in a manner that does not change them (i.e. read only) for the expressed purpose of brining the “facts” about their current state of configuration or operation into OpsMgr’s universe. A Data Item produced by a Data Source or Probe is the unit of information that starts that process.
- Condition Detection modules are essentially filters that consume a Data Item as input and either manipulate it or check it against some conditions. Condition Detection modules are always defined with an output type, but depending on their purpose and the contents of the input, they may or may not output a data item on any given occasion. When a Condition Detection module produces a data item, it will be passed on to the next module in the workflow, either unchanged (e.g. as is the case with the expression filters) or transformed (e.g. as is the case with the discovery mappers). When a Condition Detection module does not produce a data item, the workflow ends (e.g. as is the case when a test condition is not met). These modules can be thought of as operating on the Data Item produced by the Data Source or Probe. They are usually internal to the workflow, meaning that they only consider the input and their purpose and configuration. They do not usually use data external to the data flowing through the workflow. I reiterate, though, that they do not strictly need to be simple filters that can only see the Data Item passed in or only affect the Data Item passed out. Some do quite a bit more than that. Good examples of this are the condition detection modules involved in calculating delta values and baselines. They do operate on incoming Data Items and produce outgoing Data Items, but they also hold state themselves.
- Write Action modules receive a Data Item and do something active with it, like write it to the database, generate an alert, or otherwise use its contents to affect some other entity. These are formally defined as the only modules that will change something external to OpsMgr. This is one reason why you don’t normally see a Write Action module in a discovery or monitor. Write Action modules optionally can produce output.
See the following diagram for a visual treatment of the four module types.
This, therefore, gives a lifecycle of a workflow: from the creation of a data item, though manipulations, to the final action a data item causes. Of course, to continue painting a picture of how these modules are used, I would also note that discoveries and monitors do not usually contain write actions. The nature of a discovery or monitor infers that their end state will be internal to OpsMgr: a new or updated instance or a change in state. In those cases, then, it is OpsMgr itself that consumes the final output of the workflow.
The next two paragraphs contain very rich information. Based on feedback, I have added a few diagrams to help understand these concepts. I suggest an initial read of these two paragraphs, followed by a review of the diagrams, and then a quick re-read.
To make matters even more intersting, the definition/implementation of any given module can be one of three forms: native code (implemented as a COM .DLL), managed code (implemented as a .NET assembly .DLL), or a composite module. A composite module is itself a pre-defined sequence of other modules. Composite modules are the most interesting to research, since a composite can be defined as the sequence of several modules, each of which may be a composite itself, each of which yet again may be a composite, etc. Eventually, all module implementations will end at native or managed code, but it can be quite a ride getting there. Since any given module will be of one of four module types implemented in one of three possible ways, how truly open-ended a module’s functionality can be should be self-evident.
This also skews the clean definitions and characterizations of the four module types I discussed above. Consider this: a data source module may be defined as a composite of a data source, a probe, and a condition detection module. Another data source module may use that data source module in its own definition of a composite that includes another probe and another condition detection module. That would make the final data source module a data source, probe, condition detection, probe, and finally condition detection. That final data data source module might then be used in a workflow for a discovery. Although only certain combinations are allowed for each composite type (i.e. a condition detection module may not come between a data source and probe in a composite data source module), it’s otherwise completely flexible.
The following diagrams help to present this material more visually.
Obviously, it can get fairly complicated. On the other hand, it is very conducive to good design habits: making small, focused bits of functionality that are then re-used where they are needed.
Next in part 3, we will examine these Data Items a bit more closely.