Workflow / Workflow Service combination? How to use Receive activity on 'normal' workflow?

Question

We are currently trying to implement workflow functionality in our product (.NET 4.5). For this we consider using Microsoft Workflow Foundation 4.5. However in this early stage we bumped into a technical problem of something that seems very doable.

Simply put this is what we want to achieve in our client/server setup:

• Based on a specific event the server starts a workflow
• The workflow executes some actions until it comes to an activity that requires human interaction. It should then wait for a message from a client.
• One client (there are multiple clients) becomes the owner and therefore should send its unique id or address to the workflow
• The workflow sends a message to that client indicating that it requires information to continue (e.g. e-mail parameters like recipient, subject and body)
• After several minutes (could be a few minutes to a few hours) the client sends the information to the workflow so that it can continue (e.g. send the e-mail message)
• If another human interaction is required, the server sends a request message to the client again so that it knows it should ask the user for information and then the client sends a message to the workflow again (like above)

For what I understood a 'normal' workflow does not have an endpoint to receive messages. A workflow service on the other hand does, but with WF services the workflow instances would be created based on the incoming requests rather than having the server be in control of the creation of workflows (right?).

At this moment it appears to me that we need a combination of a workflow and a workflow service.

I've been struggling with this for a while now and searched high and low but cannot find useful information about it.

I think we have two options:

1. Workflow services; If we would use workflow services, we could have a Receive activity at the beginning of the workflow that starts the workflow. However, then how can clients communicatate with that specific workflow? A workflow service has one specific URL.

2. Workflows; A normal workflow that is hosted by a server application seems the most natural path to choose. However, then we need a way to send data to it. So, is it possible to upgrade a normal workflow so that the Receive activity can be used? And if so, how? And how do messages end up in the right workflow instance?

My questions are: Does anybody have some useful guidance or information on how to solve the above problem? Are there interesting alternatives (not using WF?) to accomplish this? Does anybody have documentation about how WCF messages are routed to the correct workflow instance in WF?

PS: We have a WCF service available on the client. A workflow can communicate with that. For short running requests that isn't a problem, but the thing is that requests can take a long time before the client 'answers' them. Also, the client can only request the information if the user clicks on a continue button (the users should not get a popup just in the middle of something because the server wants information)

Answer 1

Yes, the Workflow Service with AppFabric is ideal and should just work out of the box if I understand your problem correctly.

For your question "However, then how can clients communicatate with that specific workflow?" the answer is correlation and you can easily set that up in the first Receive. You just add a CorrelationHandle variable and set the Receive's CorrelatesOn for an incoming parameter (ownerid?) and CorrelatesWith to that handle. Do the same for all other receives and the incoming messages will always be routed to the right instance.

AppFabric will help in that your WF service will be unloaded from memory and persisted when it's idle for too long, woken up when the new receive comes and etc. It will also help in that you can set autostart on your IIS app pool. WAS will activate your workflow service on incoming request.

If you need further specific details just let me know.