Tuesday, March 20, 2012

Conversation Group

I have not been successfull in getting conversation group to work. My understanding is that I can specify a 'guid' for a conversation group id in the create dialog and when I send a message on this conversation it will have that specific guid for its conversation group. When I do this it does not appear this way in the "target" queue.

I am looking for an example to help me understand how to use a conversation group. The MSDN has not really provided that run able example that I can run and verify and tweak.

The idea that I would like to try is that the initiator must send 5 different XML messages to a target. These 5 messages are all related and must exist together. What I assume is that if I want the target to get all 5 messages together out of the queue all messages must be sent in their own conversation but all linked with the same conversation group Id. I have not been able to get this to work.

The communication is really a one way where the initiator sends the data to the target and does not process or need a message sent back from the target.

Thank you for your time.

Here is how I am going to manage this. I have knowledge and control over the initiator and target. Which means I can make a few "assumptions"

I will define a message for each of the 5 messages to be sent to be used to identify the message in the conversation group. This will cut down on the processing of the data to determine its message type.

The contract is only one way and so the initiator will be listed as publishing each message type in the contract.

When sending to the target service the initiator will create a dialog and send all 5 messages in the same dialog.

The target will process the queue and get the conversation group. The target processing will need to account for undelivered messages and "poll" the queue for delivery. Plus a little more logic to stop polling after so many tries in case all five messages are never sent.

|||

You can also avoid pooling. You can turn on retention on the queue and have an activated procedure that is very simple: if the message is not the last one in the sequence, ignore it (commit the RECEIVE, though). If the message is the last one (5th, if there are 5 messages), the the procedure can use SELECT against the queue to find all the previous messages. When retention is ON, a queue keeps RECEIVEed messages until the conversation is ended.

HTH,
~ Remus

sqlsql

No comments:

Post a Comment