| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Aggregation & DistributionList |
« View previous topic :: View next topic » |
| Author |
Message
|
| vmcgloin |
 Posted: Wed Oct 09, 2002 7:50 am Post subject: Aggregation & DistributionList |
 |
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
Is anyone out there using the Aggregate nodes (2.1) with an output node specifying DistributionList, rather than 2 or more MQOutput nodes?
I am having problems with it and need some reassurance that it *should* work.
To be more specific, in case anyone can help, I am getting the following error:
( BRK001X2.default ) Database statement 'INSERT INTO MQSIUID.BAGGREGATE (BrokerUUID , aggregateName , replyId , replyProtocol , timeout , data , unsolicited , messageDomain , messageFormat , messageSet , messageType , encoding , ccsid) VALUES ( ? , ? , ? , ? , ? , ? , 'Y' , ? , ? , ? , ? , ? , ? )' could not be executed.
All message flows are transactional etc., and the MsgId is unique.
Thanks,
Vicky |
|
| Back to top |
|
 |
| devans |
| Posted: Wed Oct 09, 2002 11:13 pm Post subject: |
|
|
Apprentice
Joined: 18 Mar 2002
Posts: 43
|
You should be able to use a DestinationList. You haven't provided the full error listing, but it looks like the error is happening in the AggregateReply node, and that it couldn't identify your reply as being part of any aggregation, and is trying to store it away as an unknown message.
If there is another error near the one you provided grumbling about the uniqueness of a key, then your problem will be that you're not copying the MsgId of the request message into the CorrelId of the reply message. If you're using a message flow to produce your replies, then an MQReply node will copy the Ids for you. Either that or you could use a Compute node
SET OutputRoot.MQMD.CorrelId = InputRoot.MQMD.MsgId.
If you have a true backend system producing the replies, you'll have to modify that to do the copy for you. |
|
| Back to top |
|
|
| vmcgloin |
| Posted: Thu Oct 10, 2002 3:01 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
Thanks for the reply. At least I know that it does work and I am just doing something wrong.
I did already have the copying of MsgId to CorrelId in my reply flows. I ran with user trace and it appears that the replies are 'unknown' because the control message does not arrive at the AggregateReply node before them. (BIP4412I: Corresponding request record not found for the reply message.)
The first time I ran with trace there was a 30s wait after the message left the out terminal of the AggregateControl, before the control message left the control terminal. I have stopped various apps on my poor old NT box, and now the difference is only 2s, but it still doesn't reach the AggregateReply node even though it reaches a trace node just before it.
The duplicate key db error is for the 2nd unknown reply being stored. This obviously has the same Msg/CorrelId as the 1st unknown reply. Is this a problem?
Thanks for your time,
Vicky |
|
| Back to top |
|
|
| devans |
| Posted: Thu Oct 10, 2002 3:17 am Post subject: |
|
|
Apprentice
Joined: 18 Mar 2002
Posts: 43
|
The fact that the control message isn't arriving in a timely manner isn't of significance here.
May I make a couple of suggestions. Setting the "Unknown timeout" attribute is only relevant if your application may be affected by early replies. As you say that you are doing all of your work within a transaction, this will not be an issue for you, so you can set this attribute to the default "0". Unknown messages are then either caused by late replies, or rogue messages. You want to eliminate rogue messages because they indicate an error in your message flow logic. To eliminate them, you have to isolate them. To do this, set your normal "Timeout" attribute to "0". This eliminates the possibility of late replies arriving. If you still see your error message or messages being sent to the "unknown" terminal, then you still have some sort of problem with your CorrelId processing. I'd recommend putting some Trace nodes in before replies get passed to your AggregateReply node and inspecting the MQMD that comes through.
If you've turned off timeouts and find that your "unknown" messages disappear, then the "unknown" messages are late replies.
My best guess is still that your CorrelId processing is broken somehow, but you need to isolate the problem as described above to be sure.
Good luck.  |
|
| Back to top |
|
|
| devans |
| Posted: Thu Oct 10, 2002 3:22 am Post subject: |
|
|
Apprentice
Joined: 18 Mar 2002
Posts: 43
|
| You mentioned that the CorrelId of the 1st and 2nd unknown reply is the same. They shouldn't be the same, because they are merely copies of a MsgId, and every MsgId should be unique. If your CorrelId is X'00000...' then you are forgetting to set your CorrelId and it is using the default. If your CorrelId looks valid (X'1234...') then you are sending out multiple requests without unique MsgId's. You would have to fix that. |
|
| Back to top |
|
|
| lillo |
| Posted: Thu Oct 10, 2002 6:00 am Post subject: |
|
|
Master
Joined: 11 Sep 2001
Posts: 224
|
I think the problem is that you already store in the database the MsgId and you can´t store again (second or next mqoutput). To solve this problem, try to set in the MQOutput node, before the AggregateRequest node, NewCorrelID in the advanced tab.
Cheers,
_________________
Lillo
IBM Certified Specialist - WebSphere MQ |
|
| Back to top |
|
|
| devans |
| Posted: Thu Oct 10, 2002 7:12 am Post subject: |
|
|
Apprentice
Joined: 18 Mar 2002
Posts: 43
|
| The CorrelId has no relevance on the fan-out side (where the AggregateRequest node is). There's nothing to correlate against yet. |
|
| Back to top |
|
|
| vmcgloin |
| Posted: Wed Oct 23, 2002 4:28 am Post subject: Still don't get it... |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
Devans/Lillo/Anyone,
If I have a single request with a unique MsgId. That is then split two ways i.e. duplicated and sent to all those on its distribution list. What you are saying is that to get the fan-out flow to work I need to generate a new MsgId for each fanned-out message on the MQOutput node.
But, how does the standard request/reply logic work with that? My client application stores the MsgId of the message it has just put then does a GET to fetch the reply by CorrelId using the stored Id. If I introduce a new Msg Id, how can the client get the replies?
Thanks in advance,
Vicky |
|
| Back to top |
|
|
| devans |
| Posted: Wed Oct 23, 2002 5:55 am Post subject: |
|
|
Apprentice
Joined: 18 Mar 2002
Posts: 43
|
I think what you're asking is how do you preserve information such as MsgId and ReplyToQ and suchlike across an aggregation.
The recommendation is that you add an extra arm to your fan-out. In this you create a new message (XML or whatever) and the body contains the information you want to preserve (MsgId, ReplyToQ, etc). You then send this out as a "dummy" request complete with an AggregateRequest node and everything. You then have a little flow in your broker (MQInput --> MQReply) which picks up your request and sends it back to your fan-in flow. When you get your aggregated reply message, you pull the MsgId etc out of the BODY of your additional message, put it into the MQMD of YOUR reply message, and then the client should be able to find it and correlate it. |
|
| Back to top |
|
|
| vmcgloin |
| Posted: Wed Oct 23, 2002 6:04 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
Great, thanks.
I just need this for Msg/Correl Id though. I am not forced to change the ReplyToQ.
I suspect after all this that my managers are going to decide to stick with the C executable that we currently use as a 'collator', just because these message flows look so complicated.
Thanks again,
Vicky
p.s. If it isn't there already maybe your recommendation should be in the documentation somewhere. |
|
| 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
|
|
|
|
