Windows Workflow Foundation 4.5 Receive Activity Queuing Behavior

Question

I have the following state machine called Task:

Start -> A -> B -> Complete

The transition between B and complete is a one-way receive activity called CompleteTask. It seems that when the workflow instance is in state A, any call to CompleteTask will be queued. The call will then be carried out right away when the state transits to B. If CompleteTask is a two way call, it will have the same behavior except that the client will hang and wait for a response. It will often lead to time out since the work flow is in the wrong state.

It is a bit of unexpected behavior for me. I was hoping the workflow engine will just throw me an exception when user make "out of state" calls.

In terms of correlation, I use a global CorrelationHandle called taskInstanceID. I have a feeling that local correlationHandle might be the key to solve this.

Any thoughts on this? Any way to make "out of state" calls illegal in workflow foundation?

thanks!

Answer 1

I solve the issue by using a localized correlation handle at the state level. By doing so, out of state calls will get a correlation not found exception.

Answer 2

It seems that I misunderstood the behavior of receive msg queuing in WPF.

After creating a series of test projects, here is what I observed:

The receive msg from the client will only be queued when the workflow is in transaction. Once it hits a receive activity, it will toss out any invalid msg in the queue and only process the one that match the receive activity.

For example: Test Workflow

Start -> Delay A (5 seconds) -> Receive A -> Delay B -> ReceiveReply B -> Complete

Immediately after the start of the workflow, the client sends both A and B. Notice that A is one way and B is a two way request. The workflow engine will queue both requests during the Delay A phase. Once it hits Receive A, it will immediate toss out request B. Since B is a two way request, the client will experience a blocking of 5 seconds then will be hit by an exception.

It seems that the scope of the correlation handle has nothing to do with this behavior.

Hope this will help others.