The other day, I realized I'd never tried to publish a state machine workflow as as web service. These are more interesting than your standard sequential workflows, as you can have multiple service operations that interact with the workflow over an extended period of time.

I added my web service inputs and outputs, and then published the state machine as a service.

It worked... eventually. I ran into two gotchas one tied to the delay activity the other with IIS7 and proxy servers. After some research, I resolved both.  A colleague suggested I write them up for my blog, so here we go...

I wont get into the details of the workflow itself, but here are the high level pieces of information you'd need to know:

The workflow has multiple states, State A is the only state that activates the workflow.
Upon receipt of a web service request, the workflow returns a response and transitions to State B
StateB is triggered by a delay/timer, and pulls down an XML document from a URL.

Handling Delays in IIS

First, if you want to use state machines in IIS7 and use delay objects, you’ll need to modify web.config to use the ManualWorkflowSchedulerService and the element for that should set the attribute useActiveTimers to true.

The DefaultWorkflowSchedulerService creates threads for every instance. This is not a desirable situation on ASP.NET. Instead, you use the ManualWorkflowSchedulerService allows the thread that is processing the HTTP request to execute a workflow instance. The ManualWorkflowSchedulerService creates a background thread that can monitor delays/timers. Setting useActiveTimers to true enabled this functionality.

<WorkflowRuntime Name="WorkflowServiceContainer">

            <Services>

                  <!--<add type="System.Workflow.Runtime.Hosting.ManualWorkflowSchedulerService, System.Workflow.Runtime, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>-->

          <add type="System.Workflow.Runtime.Hosting.ManualWorkflowSchedulerService, System.Workflow.Runtime, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" useActiveTimers="true"/>

      <add type="System.Workflow.Runtime.Hosting.DefaultWorkflowCommitWorkBatchService, System.Workflow.Runtime, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>

            </Services>

      </WorkflowRuntime>

 Handling Delays in IIS

Make this change, and your delays will trigger just fine.  What came up next was a bit more interesting. Running a workflow inside the debugging web server that ships with Visual Studio (the one that runs when you hit F5), my workflow retrieved the XmlDocument from the web just fine. 

Putting it into IIS7, and it came back with nothing. After adding some logging, I was seeing that the remote servers domain name could not be resolved. So I both pinged it and tried it again in my VS web server. Both worked fine.  Switched to the IP address, and 'remote server could not be found'. As it turns out, it was a proxy issue. 

Why? IIS7 is not running as a user (the VS Web Server is), so it doesn’t automatically connect with the proxy.  You need to add a reference in web.config that points to the proxy.  Add the following:

<system.net>

    <defaultProxy>

      <proxy

           usesystemdefault = "False"

           proxyaddress="http://yourproxyserver.com:80"

           bypassonlocal="True"

     />

    </defaultProxy>

  </system.net>

Once done, your calls will now work.