If you've spent any time with Windows Workflow Foundation, you probably know that every possible thing you can do to enable logging and tracing of your workflows at runtime (Tracking, logging, Tracing) can save your butt when you just can't seem to find out why the heck your workflow is sitting idle after you've just thrown a few hundred concurrent requests at it.
Tracking is pretty well documented, and I would highly recommend it, along with a Monitoring tool that gives you a view into tracking results without needing to write queries against the tracking DB (I'll cover some minor enhancements I made to this tool in another post). Not that it's really that difficult, it's just not worth your time to figure out the ins and outs of the Tracking DB schema when Microsoft plans to greatly enhance it in .NET 4.0. (along with providing Tracking data views in IIS, which will be fantastic.)
Logging, whether via Enterprise Library or another tool like Log4Net, is also pretty well documented. If you're using Workflow Services, you'd also be wise to use Service logging as another source for Workflow forensics. This is also well documented.
Tracing, on the other hand -- which I consider to be the last line of defense when WF Runtime seems fine, Tracking data is clean, but the WF isn't completing as expected and/ or you're seeing intermittent socket exceptions in the svclogs -- is not so well documented. Perhaps this is because it need not be documented as it is simple and I am daft.
In any case, I thought it might be helpful to expound upon a few of the entries I have seen regarding Workflow Tracing.
When I first looked into adding tracing to my Workflow Host, I found several articles that recommended the following code in config:
1: <configuration>
2: <system.diagnostics>
3: <switches>
4: <add name="System.Workflow LogToTraceListeners" value="1" />
5: <add name="System.Workflow.Runtime.Hosting" value="Verbose" />
6: <add name="System.Workflow.Runtime" value="Verbose" />
7: <add name="System.Workflow.Runtime.Tracking" value="Verbose" />
8: <add name="System.Workflow.Activities" value="Verbose" />
9: <add name="System.Workflow.Activities.Rules" value="Verbose" />
10: </switches>
11: </system.diagnostics>
12: </configuration>
I found one example of this on MSDN. The guidance is spot on, but it is missing a few lines that I think would be helpful for a developer at his or her wits end with WF who is just trying to get logging up and running. It goes without saying that "LogToTraceListeners" assumes that one or more trace listeners already exist in your config. They don't exactly tell you that, do they? What's more, the self-contained config above would lead one to believe that you're all set this with this block of code.
Not so. At bare minimum, you'll need to add at least one of the listeners below (unless you wanted to use the EventLog listener, but you get the idea):
1: <system.diagnostics>
2: <switches>
3: <add name="System.Workflow LogToTraceListeners" value="1" />
4: <add name="System.Workflow.Runtime" value="Error"/>
5: <add name="System.Workflow.Runtime.Hosting" value="Error"/>
6: <add name="System.Workflow.Runtime.Tracking" value="Error"/>
7: <add name="System.Workflow.Activities" value="Error"/>
8: <add name="System.Workflow.Activities.Rules" value="Off"/>
9: </switches>
10: <trace autoflush="true">
11: <listeners>
12: <add name="ConsoleTraceListener"
type="System.Diagnostics.ConsoleTraceListener" />
13: <add name="TextWriterTraceListener"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="System.Workflow.Trace.log"
traceOutputOptions="DateTime" />
14: </listeners>
15: </trace>
16: </system.diagnostics>
Obvious? Maybe, but it's easy to miss in a rush. If that's you, I hope this helped.
You might find that adding those two lines did nothing to fix your issue, in which case I might have something else for you to try. I' have seen in some cases where listeners are already set up for other parts of the system (WCF logging, for example) that the code above still won't work. If that's you, try this:
3: <sources>
4: <source name="System.Workflow">
5: <listeners>
6: <add name="System.Workflow" />
7: </listeners>
8: </source>
9: <source name="System.Workflow.Runtime">
10: <listeners>
11: <add name="System.Workflow" />
12: </listeners>
13: </source>
14: <source name="System.Workflow.Runtime.Hosting">
15: <listeners>
16: <add name="System.Workflow" />
17: </listeners>
18: </source>
19: <source name="System.Workflow.Runtime.Tracking">
20: <listeners>
21: <add name="System.Workflow" />
22: </listeners>
23: </source>
24: <source name="System.Workflow.Activities">
25: <listeners>
26: <add name="System.Workflow" />
27: </listeners>
28: </source>
29: </sources>
30: <sharedListeners>
31: <add name="System.Workflow"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="c:\logs\System.Workflow.trace.log"
traceOutputOptions="DateTime" />
32: </sharedListeners>
33: <switches>
34: <add name="System.Workflow.Runtime" value="Error" />
35: <add name="System.Workflow.Runtime.Hosting" value="Error" />
36: <add name="System.Workflow.Runtime.Tracking" value="Error" />
37: <add name="System.Workflow.Activities" value="Error" />
38: <add name="System.Workflow.Activities.Rules" value="Off" />
39: </switches>
Notice that live 4 in the first example is nowhere to be found here. I found I didn't need it. You'll also note that I had to add a source and listener for each Namespace in System.Workflow that I wanted to trace. I can't say why this works in cases where existing sources cause the "LogToTraceListeners" switch to hit the fritz, but I thought it was worth sharing. If it gets you our of a jam, then I'm happy to have shared it.