SCOMNIVORE at myITforum.com

Workflow Tracer 3 of 4: Data Item Primer

(Links to parts: Part 1, Part 2, Part 3, Part 4)

Now that we have discussed how workflows are the heart and soul of OpsMgr and modules are the building blocks of workflows, let’s discuss what runs through all of this plumbing: Data Items.

A data item is defined in a management pack via a DataType definition in the TypeDefinitions section. These DataTypes follow an inheritance model such that all data items eventually derive from System.BaseData. Data types are a little tricky to investigate, as their definition and XML format is tucked away in their implementation, which is always in native or managed code. Outside of that code, however, they are represented as XML document fragments. An example would be:

<DataItem time=”…” sourceHealthServiceId=”…” type=”System.BaseData” />

In fact, this is all that’s needed for the basic Data Item. It is a single node with three required attributes: the time it was created, the source health service id, and the type of data item it is. The remainder of the schema is defined by the specific DataType and is buried inside the native or managed code that defines it. For instance, if we were so inclined, we could create a DataType called “My.Data.Item”. It could possibly look something like this:

<DataItem time=”…” sourceHealthServiceId=”…” type=”My.Data.Item”>
    <MyProps>
        <MyProp1>Value1</MyProp1>
    </MyProps>
</DataItem>

As you can probably guess, all children of the DataItem element are subject to the specific requirements of the DataType set forth in the .DLL that implements the data type. You can see, then, how a data source or probe starts a workflow off: it retrieves some data externally and wraps it in some type of data item. A property bag is a common one for script monitors. A discovery data item is common for discoveries, naturally. A performance data item is common for scripted performance collectors. The list goes on.

Incidentally, you can probably now see where the XPath expressions come from that we use in monitors, etc.: DataItem/Property[@Name="Status"] would correspond to something like this:

<DataItem time=”…” sourceHealthServiceId=”…” type=”System.PropertyBagData”>
    <Property Name=”Status”>SomeStatus</Property>
</DataItem>

…and would resolve to “SomeStatus.” Since these XPath expressions are used so often in monitoring, alerting, scripting, and just about everywhere else, knowledge of the XML representation of a DataItem of any given DataType is extremely helpful.

At this point, we can also return to our discussion of module types and give another clue as to the differentiation between them:

• DataSource modules have only an output type. They do not have an input.
• ProbeAction modules have a single input and a single output. They could just simply be written to manipulate the input to produce the output, but they were intended to access an external resource, based on the input, that will lead to what becomes the output. There are also special types of ProbeAction modules that have their TriggerOnly attribute set to true.  They do not have an input DataItem.
• ConditionDetection modules have multiple inputs and a single output. The inputs are specified as a sequence of InputTypes, but often there is only one in the sequence.
• WriteAction modules always have an input but only optionally have an output. The output is usually the result of the write action, not a continuation of the workflow.

In summary:

• DataItems are the units of work that are processed by modules as part of a workflow.
• They are defined as DataType elements under the TypeDefinitions element of a management pack.
• They follow an inheritance model, deriving eventually from System.BaseData.
• They are implemented in native or managed code, where their format and XML representation are defined.

Understanding the different types of data items involved in a workflow and their respective XML representation is the definitive prerequisite to understanding how to piece modules together to construct workflows for your own management pack.

This essentially brings us to the central point of this series: the Workflow Tracer module that I will present in the last post in this series part 4.

VJD/<><

(Links to parts: Part 1, Part 2, Part 3, Part 4)