Debugging Workflows and HttpContext

This technical article was first published over 2 years ago and may discuss features and approaches that are no longer relevant for the current version of the platform.

I stumbled across one of those ‘frustrating’ bugs last week whilst setting up some simple chained out-of-the-box EPiServer workflows.

The EPiServer UI reported that the workflow instance has successfully started, but no tasks or notifications were ever received and an immediate search for any running workflow instances reported that there were none in progress.

I wasn’t really sure where to start looking. I fired up SQL Profiler and could see that there were some workflow queries being passed, but no data was stored at the end of the request so something, somewhere along the line, was causing the transaction to be rolled back.

Debugging Workflows

The workflow module in EPiServer is built upon the .NET 3.0 workflow functionality and allows custom workflows to be developed which handle typical EPiServer events.

Workflows are managed under their own runtime, which itself is hosted by a .NET application – in this case EPiServer. The runtime is configured in the web.config file, along with the persistence mechanism (SQL Server).

&lt;workflowRuntime EnablePerformanceCounters="false"&gt;
    &lt;Services&gt;
        &lt;add type="System.Workflow.Runtime.Hosting.DefaultWorkflowSchedulerService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" maxSimultaneousWorkflows="5" /&gt;
        &lt;add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService, System.Workflow.Runtime, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" UnloadOnIdle="true" /&gt;
    &lt;/Services&gt;
&lt;/workflowRuntime&gt;

Debugging can be enable by adding in and adjusting the following keys (which are commented out towards the bottom of the EPiServer web.config file).

&lt;!--OPTIONAL Workflow Diagnostics - used for logging useful information for debugging purposes--&gt;
  &lt;system.diagnostics&gt;
    &lt;switches&gt;
      &lt;add name="System.Workflow.Runtime" value="Off" /&gt;
      &lt;add name="System.Workflow.Runtime.Hosting" value="Off" /&gt;
      &lt;add name="System.Workflow.Runtime.Tracking" value="Off" /&gt;
      &lt;add name="System.Workflow.Activities" value="Off" /&gt;
      &lt;add name="System.Workflow.Activities.Rules" value="Off" /&gt;
      &lt;add name="System.Workflow LogToTraceListeners" value="1" /&gt;
      &lt;add name="System.Workflow LogToFile" value="0" /&gt;
    &lt;/switches&gt;
  &lt;/system.diagnostics&gt;

There are two choices of where to log any workflows messages, to file or to a TraceListener (aka the output window in Visual Studio). Full details of the configuration settings can be on found on MSDN.

HttpContext?

Setting up the workflow logging – quickly highlighted my issue. One of the methods in the workflow was throwing an exception which the EPiServer UI wasn’t reporting. The exact stack trace pointed to the application’s custom ProfileProvider which was explicitly trying to store items in the HttpContext.Current.Cache.

Remember that workflows are executed using their own runtime, which means they operate on a thread outside of the current web request. So trying to resolve the HttpContext will always return null. Problem identified!

In summary:

Debugging workflows can be enabled in web.config.
Workflows operate under their own runtime.
Never assume an HttpContext – be careful when rolling your own providers. Certain EPiServer services (scheduled jobs, workflows operate on a background thread).
The EPiServer UI does not always tell you the full story…. Happy workflowing!</ol>