| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Correlating Messages in Aggregate schema |
« View previous topic :: View next topic » |
| Author |
Message
|
| nelson |
 Posted: Fri Mar 20, 2015 8:20 am Post subject: Correlating Messages in Aggregate schema |
 |
|
Partisan
Joined: 02 Oct 2012
Posts: 313
|
Hi All,
I have two questions:
1) The documentation is not very clear to me when it states the following :
| Quote: |
| Store some correlation information in one of the requests sent out as part of the aggregation. |
Specifically what is "Store some correlation information"? I know this work pretty straightforward under the MQ protocol, as showed in the Aggregation sample, when it is used the MsgId/CorrelId pair to do the correlation. But how could one specify this reply identifier manually? The KC says that one could use ReplyIdentifier in the Properties folder, but when the broker chooses ReplyIdentifier and when CorrelId for example? What happens under other protocols such HTTP?
2) Is it possible to use Aggregate Reply within the same flow where the Aggregate requests are done (within the same thread, for example, if I wouldn't want to do a series of tasks sequentially and would't like to store responses in the Environment)? Since this is a transaction and the broker internally uses queues to store and handle aggregation processing...
Any of you have run into this issue?
Thanks in advance for your help. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Mar 20, 2015 9:01 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Understand following scenario:
Fan out flow
supplier of information flows ->
-> Fan in flow => reply to (SOAP, HTTP, MQ...)
So how is the fan in flow going to get the correlation information to allow it to perform the reply after the aggregation?
Consider creating a "dummy" provider to add to the aggregation. The dummy provider keeps the content and flips msgid to correlid. The content of that message would then be the information needed for the reply to. (correlation id, qmgr, queue, SOAP or HTTP reply token, etc...).
Hope that answers your question 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| nelson |
| Posted: Fri Mar 20, 2015 9:16 am Post subject: |
|
|
Partisan
Joined: 02 Oct 2012
Posts: 313
|
| fjb_saper wrote: |
Understand following scenario:
Fan out flow
supplier of information flows ->
-> Fan in flow => reply to (SOAP, HTTP, MQ...)
So how is the fan in flow going to get the correlation information to allow it to perform the reply after the aggregation?
Consider creating a "dummy" provider to add to the aggregation. The dummy provider keeps the content and flips msgid to correlid. The content of that message would then be the information needed for the reply to. (correlation id, qmgr, queue, SOAP or HTTP reply token, etc...).
Hope that answers your question |
fjb_saper thanks for your reply.
This scenario is assuming you're using MQ... since you need to flip the MsgId to CorrelId. I understand that Aggregate Reply works fine in this scenario. What I'm wondering is how this works for other protocols, and how the Aggregate Reply node reads the input message and do the task of correlating messages that has no MQMD. The documentation does not refers to this point (or I haven't search good enough )  Only says this:
| Quote: |
| Store some correlation information in one of the requests sent out as part of the aggregation. |
That for me is very vague an imprecise. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Mar 20, 2015 10:36 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| nelson wrote: |
This scenario is assuming you're using MQ... since you need to flip the MsgId to CorrelId. I understand that Aggregate Reply works fine in this scenario. What I'm wondering is how this works for other protocols, and how the Aggregate Reply node reads the input message and do the task of correlating messages that has no MQMD. The documentation does not refers to this point (or I haven't search good enough ) Only says this:
| Quote: |
| Store some correlation information in one of the requests sent out as part of the aggregation. |
That for me is very vague an imprecise. |
You've only scratched my scenario. You may have noticed me using terms like SOAP / and HTTP....
The thing is that the aggregation requests will all be MQ. as well as the replies to the Fan in. So the correlation there is easy.
The point you seem to be missing is that when the fan out and the fan in are separate flows, you need some way to match the reply at the end of the fan in with the request at the beginning of the fan out.
This is where the extra aggregation request comes in. It will carry the replyto information. (Token for SOAP or HTTP, msgid, correlid. replyto qmgr and replyto queue for MQ). This way that information will be available to the fan-in as a member / part of the aggreation.
If your aggregation information providers are not MQ based, nothing prevents you from doing a quick flow with MQ input --> call aggregation info provider --> MQ Reply... and that reply gets put on the aggregation fan it queue...
Hope this clears it up.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| nelson |
| Posted: Fri Mar 20, 2015 12:35 pm Post subject: |
|
|
Partisan
Joined: 02 Oct 2012
Posts: 313
|
| fjb_saper wrote: |
| The thing is that the aggregation requests will all be MQ. as well as the replies to the Fan in. So the correlation there is easy. |
I'm sorry, but I'm not following you. 
For instance, we have this:
Flow 1:
| Code: |
| HTTPInput -> Aggregate Control -> SOAPAsyncRequest -> AggregateRequest |
Flow 2:
| Code: |
| SOAPAsyncResponse -> AggregateReply -> HTTPReply |
I don't see here any MQ intervention, unless the internal processing of aggregation, of which we don't have visibility.
That's my point, because the documentation clearly states:
| Quote: |
The aggregation nodes work correctly only for transports that use a request/reply model; for example, WebSphere® MQ Enterprise Transport.
|
And only says:
| Quote: |
| Store some correlation information in one of the requests sent out as part of the aggregation. |
And also says that you could use ReplyIdentifier in the Properties folder. But anywhere says you need to use MQMD.
Could you please give me some advise here?  |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Mar 20, 2015 5:52 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You got me there. So far I've only done aggregation with MQ. It simplifies things somewhat because you can make all the parallel branches start at the same time, when the fan out flow commits... Makes the timeout more precise....
Whenever I had a request for information on the aggregation that went HTTP or SOAP, I used to front it with an MQ based flow...
_________________
MQ & Broker admin |
|
| 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
|
|
|
|
