*Moved to: http://fluentbytes.com/added-functionality-to-work-with-correlated-workflows/
This evening I implemented the rudimentary way of doing workflow correlation in the WCFInputActivity
You can now create a workflow that has multiple WCFInputActivities and have the next calls correlated to the same workflow instance. The way it works is based on the use of a custom SOAP header you can add before you call the WCF service implementation.
To give you an idea how it works:
// Instantiate the generated proxy
wcfTest.WCFInputActivity_wcfContractImplClient client = new WCFTestClient.wcfTest.WCFInputActivity_wcfContractImplClient();
using (OperationContextScope scope = new OperationContextScope(client.InnerChannel))
{
Guid WorkflowID =
client.EchoMessageSendToWorkflow("Hello workflow with WCF");
// now do the call again and add a message header to corelate the workflow
MessageHeader<Guid> mhg = new MessageHeader<Guid>(WorkflowID);
MessageHeader untyped = mhg.GetUntypedHeader("WorkflowInstanceID",
"WCFInputActivity");
OperationContext.Current.OutgoingMessageHeaders.Add(untyped);
string msg = client.GetOriginalMessageBackFromWorkflow();
MessageBox.Show(msg);
client.Close();
}
On the server side I now implemented the method to get the instance from the header
Guid workflowInstanceID = OperationContext.Current.IncomingMessageHeaders.GetHeader<Guid>("WorkflowInstanceID", "WCFInputActivity");
return workflowRuntime.GetWorkflow(workflowInstanceID);
For future extension it is now possible to add a custom behavior that injects the custom header based on e.g. a database lookup in your tracking store or some other mechanism to retrieve the workflowID based on input parameters.
During this work I ran into some subtle bugs regarding handling parameter less methods as well, so that is fixed right away. The test workflow I use now looks as follows:
After a few more little things I will create a 0.5 release, so you don’t have to download the changesets separately anymore. Hope I have enough time to do this before the end of the week.
Go to codeplex and get the latest change sets I just checked in. (http://www.codeplex.com/WCFWorkflow/SourceControl/DownloadSourceCode.aspx?changeSetId=286)
Follow my new blog on http://fluentbytes.com
3 comments
I know you’re the expert, but today I’ve learned an important lesson that I would like to share with you and the rest of the WF-community:
When writing unittests for your own workflow solutions, make sure you configure your workflow runtime to use the ManualSchedulerService!!!
I didn’t configure a scheduler in my unittests, which makes the workflow runtime use the default scheduler. My tests worked fine, but the deployed application that uses my custom WF-activities did not. After spending several hours to find the problem, I realized that my deployment environment used the ManualSchedulerService (my workflows are hosted by a WCF-service which is hosted by IIS). When I used the manual scheduler in my unittests, they broke as well, which made it possible to reproduce the problem and quickly find and solve it.
robertka
Great to see that this need is being addressed. I don’t quite understand why Microsoft released web service activities but not activities for WCF… Anyway a big thumbs up to you for tackling it.
One thing that would also be useful on the input activity would be if it also implemented IEventActivity, so it can be neatly incorporated into state machine workflows too…
Phil Degenhardt
That is a very good point. I will add it to the todo list and hope to fix this the comming week. I also found some other issues already that need to be addressed. I have been working on it for some nights now, so expect to see an update soon.
Thank you for this feedback!
marcelv