Building WCF Workflow Services and Hosting in AppFabric

Yesterday I showed how to deploy the new WCF 4.0 Routing Service within IIS 7.  Today, I’m looking at how to take one of those underlying services we built and consume it from a WCF Workflow Service hosted in AppFabric.


In the previous post, I created a simple WCF service called “HelloServiceMan” which takes a name and spits back a greeting.  In this post, I will use this service completely illogically and only to prove a point.  Yes, I’m too lazy right now to create a new service which creates a more realistic scenario.  What I DO want is to call into my workflow, immediately send a response back, and then go about calling my existing web service.  I’m doing this to show that if my downstream service was down, my workflow (hosted with AppFabric) can be suspended, and then resume once my downstream service comes back online.  Got it?  Cool.

First, we need a WCF Workflow Service app.  In VS 2010, I pick this from the “Workflow” section.


I then added a single class file to this project which holds data contracts for the input and output message of the workflow service.

   public class NewOrderRequest
       public string ProductId { get; set; }
       public string CustomerName { get; set; }

   [DataContract(Namespace = "")]
   public class OrderAckResponse
       public string OrderId { get; set; }

Next I added a Service Reference to my existing WCF service.  This is the one that I plan to call from within the workflow service.  Once I have my reference defined, and build my project, a custom Workflow Activity should get added to my Toolbox.

If you’re familiar with building BizTalk orchestrations, then working with the Windows Workflow design interface is fairly intuitive.  Much like an orchestration, the first thing I do here is define my variables.  This includes the default “correlation handle” object which was already there, and then variables representing the input/output of my workflow service, and the request/response messages of my service reference.


Notice that for variables which aren’t explicitly instantiated by receiving messages into the workflow (i.e. initial received message, response from service call) have explicit instantiation in the “Default” column.

Next I sketched out the first part of the workflow which receives the inbound “order request” (defined in the above data contract), sets a tracking number and returns that value to the caller.  Think of when you order a package from an online merchant and they immediately ship you a tracking code while starting their order processing behind the scenes.


Next I call my referenced service by first setting the input variable attribute value, and then using the custom Workflow Activity shape which encapsulates the service request and response (once again, realize that this content of this solution makes no sense, but the principles do).


After building the solution successfully, we can get this deployed to IIS 7 and running in the AppFabric.  After creating an IIS web application which points to this solution, we can right click our new application and choose .NET 4 WCF and WF and then Configure.


On the Workflow Persistence tab, I clicked the Advanced button and made sure that on unhandled errors that I abandon and suspended.


If you are particularly astute, you may notice at the top of the previous image that there’s an error complaining about the net.pipe protocol missing from my Enabled Protocols.  HOWEVER, there is a bug/feature in this current release where you should ignore this and ONLY add net.pipe to the Enabled Protocols at the root web site.  If you put it down at the application level, you get bad things.

So, now I can browse to my workflow service and see a valid service endpoint.


I can call this service from the WCF Test Client, and hopefully I not only get back the immediate response, but also see a successfully completed workflow in the AppFabric console. Note that if you don’t see things showing up in your AppFabric console, check your list of Windows Services and make the sure the Application Server Event Collector is started.


Now, let’s turn off the WCF service application so that our workflow service can’t complete successfully.  After calling the service again, I should still get an immediate response back from my workflow since the response to the caller happens BEFORE the call to the downstream service.  If I check the AppFabric console now, I see this:


What the what??  The workflow didn’t suspend, and it’s in a non-recoverable state.  That’s not good for anybody.  What’s missing is that I never injected a persistence point into my workflow, so it doesn’t have a place to pick up and resume.  The quickest way to fix this is to go back to my workflow, and on the response to the initial request, set the PersistBeforeSend flag so that the workflow forces a persistence point.


After rebuilding the service, and once again shutting down the downstream service, I called my workflow service and got this in my AppFabric console:


Score!  I now have a suspended instance.  After starting my downstream service back up, I can select my suspended instance and resume it.


After resuming the instance, it disappears and goes under the “Completed Instances” bucket.

There you go.  For some reason, I just couldn’t find many examples at all of someone building/hosting/suspending WF 4.0 workflow services.  I know it’s new stuff, but I would have thought there was more out there.  Either way, I learned a few things and now that I’ve done it, it seems simple.  A few days ago, not so much.

Author: Richard Seroter

Richard Seroter is Director of Developer Relations and Outbound Product Management at Google Cloud. He’s also an instructor at Pluralsight, a frequent public speaker, the author of multiple books on software design and development, and a former editor plus former 12-time Microsoft MVP for cloud. As Director of Developer Relations and Outbound Product Management, Richard leads an organization of Google Cloud developer advocates, engineers, platform builders, and outbound product managers that help customers find success in their cloud journey. Richard maintains a regularly updated blog on topics of architecture and solution design and can be found on Twitter as @rseroter.

10 thoughts

  1. Well done. Have you performed any benchmarks to see what the performance looks like when WF resumes a suspended workflow?

  2. Hi serotor,

    Building WCF Workflow Services and Hosting in AppFabric —nice article, but article images are not displaying in browser.—please be fix it.

    waiting for reply ……

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.