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.

[DataContract(Namespace="https://seroter.com/Contracts")]
   public class NewOrderRequest
   {
       [DataMember]
       public string ProductId { get; set; }
       [DataMember]
       public string CustomerName { get; set; }
   }

   [DataContract(Namespace = "https://seroter.com/Contracts")]
   public class OrderAckResponse
   {
       [DataMember]
       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.