| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MsgId Best Practices When Using Broker |
« View previous topic :: View next topic » |
| Author |
Message
|
| Sandman |
 Posted: Thu Jul 27, 2006 7:55 am Post subject: MsgId Best Practices When Using Broker |
 |
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
Hi,
Our scenario is this:
1. Client sends request to Broker, then waits for reply on correlId.
2. Broker transforms request into server's required format, then sends a "new" (depending upon your view of a transformed message) request message to the server, specifying itself (the Broker) as the replytoQMgr/Q.
3. Server processes and sends reply back to a reply flow in the Broker.
4. Broker transforms server reply into client's required format, then sends a "new" reply to client.
My question is: would you consider the "new" messages sent by the Broker to be new enough to warrant their own unique msgIds? If so, then the information necessary to make it back to the final client app must be cached somewhere (i.e. RFH2/usr or a database table). Or do you still deem these "new" messages "the same message as the original one - albeit in a different format (i.e. XML vs. flat, business model differences, etc.)" - and therefore propogate the original msgId?
Thank you,
Mike |
|
| Back to top |
|
 |
| Prashant_MQ |
| Posted: Thu Jul 27, 2006 11:30 pm Post subject: |
|
|
Apprentice
Joined: 07 Feb 2006
Posts: 28
|
Mike,
I believe you need to store the original message ID of the request message as these kinds of design warrant a confirmation of that the reply message is indeed for the request message that was sent by the sending application.
Thanks
Prashant |
|
| Back to top |
|
|
| Sandman |
| Posted: Fri Jul 28, 2006 3:53 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
Thanks Prashant.
But I think that the Broker could still pass along the original [client's] message ID to the server, then the server would send that ID back in its reply message correlId, then the Broker could also copy that correlId to the correlId of the reply message it sends back to the client.
I'm not saying that's how I'd like to see it done, but it would seem to achieve the same goal.
I guess my question is a principle or best practice one. Should each message put onto the network have its own msgId?
Here's a more drastic example: what if the Broker needed to fan out to several servers in order to satisfy the client's request? Should each of those independent messages use the same msgId? That just doesn't seem right, to me.
Thanks again.
Any other input? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jul 28, 2006 4:27 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| Sandman wrote: |
| Here's a more drastic example: what if the Broker needed to fan out to several servers in order to satisfy the client's request? Should each of those independent messages use the same msgId? That just doesn't seem right, to me. |
You basically need to use new message ids in this case.
In the case of a single outbound request, I tend to be a bit more flexible. If all the broker is doing is enhancing the original message request, then I'd probably keep the original msgId. If the broker is doing anything more complex, I'd tend to use a new msgId.
On the other hand, if you're doing a lot of auditing and tracking of messages across your entire system, and you're using msgId's heavily in this process... then every message should have a unique msgid.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Sandman |
| Posted: Fri Jul 28, 2006 4:33 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
Thanks Jeff.
Where would you draw the line on "enhancing" a message?
-Converting a flat COBOL message in/out of XML?
-Transforming one system's primary keys to another's ("cross-referencing")?
-Transforming one system's codes to another's (i.e. RI -> Rhode Island)?[/list] |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jul 28, 2006 5:44 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'd draw the line when the message stopped being logically "the same" message, and started being "a new message".
In some cases, this may be when the message is completely unchanged - but has crossed a logical system or application or ownership or etc. boundary.
Like if I have a broker flow that's proxying a service, and the input data is the same as the output data - but all the requests coming into the flow come from external parties... I'd always make a new msgid.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
