views:

21

answers:

3

I have a WF service that I'm trying to setup receive activities to "Subscribe" and "Unsubscribe". I'm using This WF Durable Duplex Tutorial as a basis because my service performs callbacks to clients. Basically, think of it as a chat service.

I can make client calls to the two receive activities just fine. What happens is the callback address of the client is passed in to Subscribe() on the service. The address is stored as a variable in the WF service and everything looks like it would work as to be expected.

When a client calls Unsubscribe(), my watch I have set on the address var during debugging shows it as null. So what gives?

Here's the basic setup of my WF service layout...

Everything is enveloped in a DoWhile activity. Inside of that is a Pick activity and two Pick branches. The first branch is for subscribing activities. It has a receive-sendreply activity that assigns the string passed by the client to the WF address var. The second branch handles unsubscribing. The trigger is the Request activity and the client address is again passed in.

From there it goes into a sequence, starting with an If. It checks to see if the unsubscribeAddress equals the address already subscribed. If it does, then it sets the address to String.Empty and sends a success message back to the client.

Why would a variable that's scoped to the enveloping DoWhile activity be implicitly assigned to null? I'm trying to get this to work so I can implement multiple client subscribers from there and work on triggers that invoke callbacks to multiple clients.

CONCAT EDIT: I set a breakpoint at the DoWhile level and my var is null once Unsubscribe() is called. When Subscribe() is invoked, the watch shows a value in the var all the way through. Until I Unsubscribe() with a client. Should I be using a While Activity instead?

A: 

try making a class scoped private {get; set;} and see if the problem still rears its head, thats the best I can do without seeing the actual source code as from what you described I cant see any issues.

Gnostus
Sorry Gnostus, this is a .Net Workflow Service and I can't make a class and define the variable as a property. If this were code then it would be easier to tackle and infinitely easier to debug at that.
jlafay
A: 

Wow, ok scary stuff. I had to hand edit the xamlx file earlier and the references I edited for the SendReplyToReceive saved funny when I switched back to the activity designer. It made it look like I had two Unsubscribe()'s and not only that but the correlation handles for each branch were crossing between branches.

I'm all set now. To fix the issue I removed all the messaging activities, dropped in a new ReceiveAndSendReply activity into branch 1's action block. Then I dragged the Receive activity to the Trigger for branch 1 and configured it as I had before. I did the same for branch 2, except I placed the SendReplyToReceive activity below my If activity that validates matching addresses.

jlafay
+1  A: 

Without seeing the workflow I can only make a few guesses but the things I would look for are:

  1. Is the variable scoped to a sequence or something that is inside of the DoWhile activity? BTW there is no benefit ti changing it to a While activity, the only difference is that the condition is tested at the beginning or the end.
  2. Is the variable used somewhere else and cleared that way. Try renaming it and see what gives.
  3. Is there persitence in play and is the type not persisted> I assume its either a string or a Uri and both should be good to go.
  4. Is there a problem with correlation and is your Unsubscribe message being processed by a different workflow? Mare sure the CanCreateInstance is set to false.
Maurice
Yes, if you see my answer above I did discover the issue. The designer scares me because switching between the XAML and activity designer made things very screwy in the code. I removed the messaging activities and started over. Because correlation was so backwards and ReplyToReceive's were swapped, the address string was lost in the fray.By the way, thank you very much for your wonderful blog posts on durable duplex and callbacks in WF services! They have helped me immensely.
jlafay