Workflows are the fundamental mechanism by which Operations Manager gets things done. Workflows, in essence, are individual pieces of code (modules) that are chained together. For a primer on workflows and modules, I recommend the AuthorMPs site. Workflows remind me of Powershell pipelines or to a lesser extent, linux command piping. Individual commandlets (the equivalent of OpsMgr modules) can be mixed together in different ways to accomplish a more complex task (the equivalent of an OpsMgr workflow) by piping output from one to another. As long as the output from one commandlet can be processed by the next commandlet in the pipeline, you can chain them together.

One big difference between developing pipeline-aware commandlets and developing OpsMgr modules and workflows is the potential for debugging. With Powershell, you can use the full debugging power of Visual Studio (or whatever editor you use) by simply setting breakpoints in your commandlet and attaching to the host running powershell (usually powershell.exe). Workflow debugging is certainly possible but not nearly as easy. There are several reasons for this:

• If you’re not using custom-made modules, the running code is a black box. If the module does not already have the ability to output tracing information, there is no way to add it.
• You can’t just run a workflow from a debugger. OpsMgr is complete control of when it starts and ends, so you must do this indirectly.
• If you are using custom-made modules, you need to find the OpsMgr process that they get loaded into in order to debug them.

One of the most common problems in developing workflows is trying to figure why (or why not) a data item is making it through certain parts of the workflow such as condition detection modules. In order to avoid “trial and error” development, you need some way to debug the workflows. I’ll outline a few options below for troubleshooting this kind of scenario below.

Option 1: Attach a Debugger

If you’ve developed a custom module, you can step through the code by doing the following:

• Get OpsMgr to start running your workflow. For example if you are debugging a monitor, make sure the monitor is enabled and it’s datasource is receiving data.
• Open the code in your debugger (Visual Studio in this example)
• Attach to the OpsMgr process running your workflow. This is the tricky step. The process is MonitoringHost.exe, but there may be several. You want the one that is running managed code (see the Type column in screenshot below) with the credentials of the Operations Manager action account. If it is still not obvious which process to attach to, you’ll have to attach to each one and see if your DLL module is loaded. Use the module window (Ctrl+Alt+U) to list the DLLs once you attach to the process. Once you see your DLL, you’re read to debug!

On a side note, I (or one of our team members) may do a blog post in the future on creating managed code modules.

Option 2: Use the Operations Manager Trace Files

Honestly I would leave this as a last resort, but the trace files can be useful beyond workflow debugging (such as script debugging). See #8 on my top 10 list for instructions and comments on this.

Option 3: Use the F5 Workflow Tracer

Inspired by the workflow tracer that was #6 in my top 10 list, our team has built a debugging module that can be used to trace the output of any module in your workflows. We used the same configuration elements as the workflow tracer and added support for data item batching, robust acknowledgements, and other minor improvements.

The module can be placed after any module in your workflows, and reports on the data item that come out of that module. Here is an example from the F5 Monitoring Log:

Element: F5.PRO.PerformanceMonitorType (note: this tells me which workflow is being traced)
Stage: After COUNTER TYPE detection (note: this tells me which module is being traced)
Target: {4447e45e-9f65-e01d-2c17-24dee61fb1d9}

<?xml version="1.0" encoding="utf-16"?>
<DataItem type="System.Performance.LinkedData" time="2009-11-12T12:32:46Z" sourceHealthServiceId="fa056941-2b22-7d8e-a34d-7604e1347f99">
  <ObjectName>LTM Pool Member</ObjectName>
  <CounterName>Server - Current Connections</CounterName>
  <InstanceName />
  <IsNull>false</IsNull>
  <Value>0</Value>
  <ManagedEntityId>{29c7fc90-0f44-b70c-9f88-5a7ee6d13a40}</ManagedEntityId>
  <RuleId>{0e799c3d-b8d0-bce0-259b-f9025d507996}</RuleId>
</DataItem>

This module can be downloaded here. You’ll need to import the included MP into OpsMgr and place the included DLL in the Operations Manager program files folder. Instructions for installation and configuration are the same as the original workflow tracer, except with our MP and DLL.

Another barrier to debugging OpsMgr becomes apparent if you want to use this module to debug a sealed workflow (one that’s in a sealed MP and is not marked public). There is no way to simply insert a module of your own in such a workflow since you cannot change a sealed MP. The workaround goes like this:

• Create an override for the workflow that disables it
• Export the MP that the workflow is in to XML format (use the #1 tool on my top 10 list).
• Get the XML for the workflow from the exported pack and create a copy of it in your own, new, MP. If the workflow references other elements marked “internal” to the MP, you will have to create copies of those as well.
• Insert the debugging module wherever you’d like in your new workflow.
• Import your new pack

Simple as that ! :)

To help understand this process, I’ve created an override pack for our own F5 PRO-Enabled Management Pack that replaces one of our monitors with one that includes the debugging module between each module in the workflow. I realize the pack looks strange as formatted in our wiki – just copy and paste from the <xml> element on down to </ManagementPack>.

Option 4: Use the Operations Manager Workflow Analyzer

I was both elated and saddened by the brand new workflow analyzer included in the new authoring console. Elated because this tool rocks, and saddened because it really would have helped to have it earlier :). This tool does the following things:

• Shows you all the workflows registered in OpsMgr as well as their state
  • Technical note: Internally this is basically running the “Show Running Rules and Monitors” task that is already available via the UI

• Allows you trace any of the workflows
  • Technical note: Internally this is overriding the TraceEnabled property on the workflow and hooking into OpsMgr’s built in tracing capabilities. I’ve looked for a way to override this property through the UI, and it does not seem possible.

• Allows you do an ‘analysis’ of the workflow. This was not very interesting to me – just shows you some basic properties and running instances.

You can increase the amount of information printed out in the trace if you turn on verbose logging (see Option 2 above).

The main drawback of this tool is that it’s hooking into trace calls made by the OpsMgr modules so you’re not going to get this level of detail if you’re trying to debug a custom-built module. It may be possible to write to the same mechanism, but I have not looked into that yet.

Happy Debugging!

<< Back to Part I