how can I obtain message_id?

Hi all!

How can I obtain message_id when I SEND the message, before I execute RECEIVE statement?

Thanks a lot for the help!

Are you sending to a service and then wanting to recieve from it straight after in the same code?
What are you trying to achieve with this code?

|||

Hi, SimonS_! Thank you for fast response.

I'm send the message in one procedure:

create procedure [dbo].[proc_Client]

as

begin

set nocount on;

declare @.conversation_handle uniqueidentifier

begin dialog conversation @.conversation_handle

FROM SERVICE [My Service1]

TO SERVICE [My Service2]

ON CONTRACT [Custom Comtract]

send on conversation @.conversation_handle message type [//Messaging/CustomMsg]('message data');

and here I want to save the Service Broker message_ID in the my table

end conversation @.conversation_handle;

end

Then I have an Activation Procedure:

CREATE Procedure [proc_ms_Activation]

AS

BEGIN

SET NOCOUNT ON

WAITFOR (RECEIVE TOP(1) @.internal_SB_message_id = message_id, @.message_type_name = message_type_name, @.message_body = message_body, @.conversation_handle = conversation_handle FROM Queue1);

END

mesage_id I receive only in [proc_ms_Activation], but I need save this message_id in [proc_Client] procedure. Could you please help me?

|||

I still don't know why you need the message Id.

Are you trying to manage state ?

|||Yes, I'm try to manage message state, keep messages in database and found it, and I have additional logic - gathering statistics, track poison messages and etc|||

Two points,

Messages that come back to your initiator service use the same conversation group. This means that if you specify a conversation group you can use that to correlate messages you send to messages you receive.

In this situation generate a guid (newid()) and then use that for the conversation_group_id. Then you can store it in a table, If you want the target service to know this id then you will need to include it in the message.

|||

We didn't see a need to expose message_ids at the system level since apps that require tracking state at a per-message level would have primitives within the app itself for doing so. You could for example stick some cookie into the message sent by the initiator and relay it back with the response so that your app can corelate the response to the request. Depending on the app this may be a 'request ID', an 'order number', a 'service request ticket', etc.

Rushi

|||

The other way to refactor the app would be to think of a conversation as being the primitive for identifying a request. So each request would be sent on its own unique conversation. That way the app can store state with the conversation itself (and you could use conversation_handle or conversation_group_id* as the primary key in that case). Responses for a particular request would only come back on the same conversation and hence you can easily correlate them. In fact we provide locking at the conversation level to prevent multiple queue readers from accessing the same conversation at the same time.

Rushi

*: You WILL need to use conversation_groups if you want to relate multiple conversations together. Even if today you don't do that, conversation_group_id is a better way to key state than handles.

|||

Rushi, thanks a lot for the detailed explanation.

The best decision for me will use one-message-per-dialog conversation and send one message per conversation, then trace application logic on conversation_id.

Thank you,

Sveta.

|||You don't have to have one message per dialog for this to work. I would say you want 1 Dialog per business transaction, that way any responses to any messages are on the same conversation group. You might want to send two messages rather than having to combine data from different sources in one message