I have been working with Windows Workflow Foundation (WF) for a while and the first thing that I realized with it was that I have to change the way I visualize programming. Workflows are a lot different from the way we do traditional programing.
That being said, I had couple of interesting scenarios with Workflows.
Scenario#1: I wanted to expose my business logic workflow as webservice. When I hit the publish as webservice option, it automatically generates a webservice with a predetermined name and a DLL. I had absolutely no control! WTF!! Then I figured out a way in these two posts: Paul Andrew’s post and KeyvanNayyeri’s post. These posts give an idea of how to create a webservice interface for Workflow. But the problem is, I wanted expose my workflow to my clients but don’t want to shove workflow related implementation requirements on the client such as requiring the client to pass the workflow instance id as a cookie. To encapsulate my workflow and at the same time expose as webservice, I got the hint from this MSDN page.
It says:
Although Windows Workflow Foundation provides this default routing mechanism, you can implement your own custom routing. For example, in cases where enabling cookies in the client is not an option, the client could be configured to create the workflow instance with a specific Id and pass the Id on every Web service request. The request pipeline could be configured with SOAP or HTTP handlers to intercept the call, retrieving the workflow instance Id from the header information, and then set the HttpContext.Current.Items.Add("__WorkflowInstanceId__", workflowInstanceId) to the incoming ID.
So, after a lot of research, I found that I can write SoapHeaders for my webservice’s webmethod and thereby get hold of the request. So I created a mapping table in the database with WorkflowInstanceID and then my application specific ID (such as OrderID). Then Whenever a new request comes (such as with OrderID), I could pull the workflow instance id from the database and then set it to the HttpContext.
Scenario #2: The other scenario was, I need to have more than one activating method for my workflow. I was using a StateMachine Workflow and it was throwing error that the “IsActivating” property can only be set to the initial startup activity. Also I needed to have additional methods in the Webservice for other purposes without affecting the workflow. After a lot of research I figured out that if I derive another webservice from the Workflow webservice that satisfies all my requirement. That is after publishing my Workflow webservice, I write a second webservice that derives from my published workflow webservice class. This second webservice can call its base class method easily (I mark all my workflow webservice methods as protected for hiding them). The second webservice has different method but those that I want to activate the workflow would call the single Activating method in the parent workflow webservice class.
These are all quick implementation specific details - may not make much sense to you, but if you do understand and want more information just let me know, I would gladly share the implementation details. As I dont have much time, I am not posting any sample or such for now.
