| Author |
Message
|
| kt76 |
 Posted: Thu Mar 11, 2004 11:29 pm Post subject: Aggregation question |
 |
|
Acolyte
Joined: 18 Jan 2004
Posts: 52
|
I have a front end sending em a request with message id - 123.
I hit a backend service and get a reply back with message id- 456 and corel id- 123
I now need to hit 3 backend services and need 3 replies, aggregate this and finally send this reply to my calling application with corelation id - 123
How can i achieve this?? |
|
| Back to top |
|
 |
| scaryjase |
| Posted: Fri Mar 12, 2004 1:52 am Post subject: |
|
|
Novice
Joined: 17 Jul 2003
Posts: 22
|
are your requirements any different from the usual aggregation processing? i don't think so...
There is an aggregation example in one of the red books - have a look at this.
_________________
scary |
|
| Back to top |
|
|
| fjcarretero |
| Posted: Fri Mar 12, 2004 8:12 am Post subject: |
|
|
Voyager
Joined: 13 Oct 2003
Posts: 88
|
Hi,
What you can do is store the original message id (the one comming from the front end application) generate new ones for the messages that go to the backend (MQOutput, generate new message id), and after aggregating all the messages copy the original message id to the correl id.
If the backends can cope with RFH2 you can store the information in the message. If not probably you will need a database or a queue.
Hope this helps.
Felipe |
|
| Back to top |
|
|
| kt76 |
| Posted: Mon Mar 22, 2004 8:28 pm Post subject: |
|
|
Acolyte
Joined: 18 Jan 2004
Posts: 52
|
Hi,
When the replies come back, how do I know that the reply is for the original message id- 123 even if i store it in say a database.
Is there a way where I can store that
msg id= 123, msg id sent are 345, 567, 890
Hence when replies come back, add final corelation as 123 |
|
| Back to top |
|
|
| fjcarretero |
| Posted: Tue Mar 23, 2004 1:50 am Post subject: |
|
|
Voyager
Joined: 13 Oct 2003
Posts: 88
|
Hi,
You can this 2 ways:
1) You store the original message id in the RFH2. When the requests are fan out copy the RFH2 to all the request messages. Then the replies will have the RHF2. So, after aggregating the replies you can restore the original message id from the RFH2.
If the backends do not support RFH2, you will have to create a mechanism to store this RFH2 when you send the request to the backend and restore it when the reply arrives.
2) On the fan out, you can create a datagram with the information of the original message id (could be the original request) and make it part of the aggregation. So you will have this information available after the aggregation takes place.
With this approach you do not need RFH2. Take because the aggregation nodes only deal with request/reply messages (you'll have to copy the message id to the correl id if the message type is datagram to correct this behaviour).
Hope this helps
Felipe |
|
| Back to top |
|
|
| kt76 |
| Posted: Tue Mar 23, 2004 6:06 am Post subject: |
|
|
Acolyte
Joined: 18 Jan 2004
Posts: 52
|
| Can you please laborate on the datagram. Im not sure i understand it well |
|
| Back to top |
|
|
| fjcarretero |
| Posted: Tue Mar 23, 2004 6:32 am Post subject: |
|
|
Voyager
Joined: 13 Oct 2003
Posts: 88
|
Hi,
What I meant was that you can make the original message part of the aggregation. The only thing is that this message, in the fan out, is sent directly from the flow with aggregate request node to the one with the aggregate reply node. Thats why I have called it datagram.
As the aggregation nodes expects that every message in the fan out behaves like a request-reply (correl id of the reply = message id of the request) you need to do this manually.
Hope this helps
Felipe |
|
| Back to top |
|
|
|
|
