– (Part 1 – Part 2 – Part 3 – Part 4)
In the previous three posts, I discussed workflows, modules, and data items. I also stated that understanding the data items involved in various module interactions and their respective XML representations is sorely needed. You can accomplish this by digging though the system MPs and then through the disassembly of managed code, but that’s not a recommended course of action or a reasonable requirement. Also, beyond the general structure of the various types of data items, it is also important to see the actual contents on occasion. If you have a workflow that never produces output even though it appears as if the conditions, etc. in the workflow should result in something, a window into the values that are being processed by a particular module at a particular time would also be very helpful. This is standard fare for a solid debugging process supported by the platform’s tools. OpsMgr, unfortunately, does not yet have a good MP/workflow debugging facility.
I have written a managed code module and an associated management pack that helps with this issue. The theory of operation of the module is simple enough: it is a condition detection module that receives a data item and then passes it on to the next module in the workflow unchanged. The only action it takes is to log the data item passed to it to the Application Event Log.
Using this module is simple.
It must first be installed. First, copy the .dll to the OpsMgr installation directory on the computer(s) on which you intend to run the trace. This will likely be C:\Program Files\System Center Operations Manager 2007\. Then, import the sealed MP downloadable below. Also, I’m assuming this will be done in a test lab. That’s my recommendation, anyway…
Second, it must be incorporated into the management pack in which the module you are tracing lives. It must be inserted into the module sequence of the composite module you are attempting to trace.
First, add a reference to it in your management pack:
Next, add its required elements to your composite module’s configuration section:
…(your other stuff)…
<xsd:element xmlns:xsd=”http://www.w3.org/2001/XMLSchema” name=”TraceElement” type=”xsd:string” />
<xsd:element xmlns:xsd=”http://www.w3.org/2001/XMLSchema” name=”TraceTarget” type=”xsd:string” />
There is one more configuration element that we need, but it will not be in the <Configuration> node of your module. Instead, this will be specified directly when we add it to the <MemberModules> section. This is because you may want to insert the module into the workflow multiple times, to trace the DataItems through different stages of the workflow.
Therefore, next, add it any number of times to the <MemberModules> section, with the corresponding ordering in the <Composition> section:
<DataSource ID=”DS1″ …>
…your data source…
<ConditionDetection ID=”Trace1″ TypeID=”f24!com.focus24.Scom.Modules.WorkflowTracer”>
<TraceStage>Text to Identify Stage, like “Data Source to Exp Filter”</TraceStage>
<ConditionDetection ID=”Filter1″ …>
…your expression filter…
<ConditionDetection ID=”Trace2″ TypeID=”f24!com.focus24.Scom.Modules.WorkflowTracer”>
<TraceStage>Exp Filter to Discovery Mapper</TraceStage>
<ConditionDetection ID=”Mapper1″ …>
…your discovery mapper…
<ConditionDetection ID=”Trace3″ TypeID=”f24!com.focus24.Scom.Modules.WorkflowTracer”>
<TraceStage>Discovery Mapper to Final Output</TraceStage>
…and that’s about it. When the management pack is next imported, the new workflow will begin running. Check the Operations Manager log for any module errors first. Then, check the Application log for the workflow trace events. Here is a sample:
I sincerely hope you find this module useful. Please let me know if you encounter any issues or have any other feedback on this module or this series.
USE THIS IN A TEST ENVIRONMENT ONLY.