| Author |
Message
|
| _Angus_ |
 Posted: Thu Oct 26, 2006 8:53 am Post subject: Aggregation node timeout handling... in WMQI 2.1 |
 |
|
Acolyte
Joined: 25 Apr 2005
Posts: 54
Location: Edinburgh
|
Hi guys,
After much frustrating coding and debugging I've created a 3-way fan out aggregation flow for WMQI 2.1 (unfortunately the company I'm working for are still using 2.1!).
Needless to say I've discovered how fragile aggregation is! The only bit remaining in the flow I'd like to do is work out which replies timed out if I recieve a time out. If I try to reference the relevant folders to see if they exist it doesn't like it and more exceptions get thrown and records left in the aggregation database that keep trying to time out!
What's the best way to handle this? .. and where can I find examples\advice etc. on aggregation coding for 2.1. All the links on the ibm sites I've been to see to be dead!
Any help would be much appreciated 
_________________
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Angus Cooke ~ AngusSoft
Integration Development Tools
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* |
|
| Back to top |
|
 |
| vk |
| Posted: Thu Oct 26, 2006 10:16 pm Post subject: |
|
|
Partisan
Joined: 20 Sep 2005
Posts: 302
Location: Houston
|
When timeout happens, all replies which were received before timeout will be sent to the Timeout terminal. You can count the number of nodes to see how many replies were received before timeout. You can also inspect the MQMD header or body of individual noides. I am doing this in my flow successfully.
Once timeout happens, all entries in the BAGGREGATE table in the broker database will be deleted. Any reply which comes after timeout will be treated as Unknown reply and will be sent to the Unknown terminal. Here also, you can analyse the node details.
I am createng a Timeout XML message and Unknown XML message respectively with values fetched from the individual replies in the nodes and am sendig them to Timeout and Unknown queues.
You can tuen on broker tracing to get more details of why you are getting errors.
Regards,
VK. |
|
| Back to top |
|
|
| _Angus_ |
| Posted: Fri Oct 27, 2006 1:09 am Post subject: |
|
|
Acolyte
Joined: 25 Apr 2005
Posts: 54
Location: Edinburgh
|
Ok, that makes sense and I understand what you're saying but I'm not sure how to do it! - do you have an example you can mail me or post here?
I'm basically not sure how to reference stuff on failed replies without sending the aggregate reply node into a weird state (where it doesn't delete the database entries and I have to clean 'em up myself!).
_________________
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Angus Cooke ~ AngusSoft
Integration Development Tools
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* |
|
| Back to top |
|
|
| vk |
| Posted: Fri Oct 27, 2006 5:16 am Post subject: |
|
|
Partisan
Joined: 20 Sep 2005
Posts: 302
Location: Houston
|
Message sent through the Timeout terminal of AggregateReply node will have a special tree structure. Below is the sample ESQL code for accessing the MsgId from the MQMD header of the first reply.
SET OutputRoot.XML.Timeout.MessageSource.MsgId =
InputRoot.ComIbmAggregateReplyBody.{cFolderName}[1].MQMD.MsgId;
Message sent to the unknown terminal will be like any other normal message. You can access the MsgId as follows -
SET OutputRoot.XML.Timeout.MessageSource.MsgId =
InputRoot.MQMD.MsgId;
You can also access the body of the message in the same way. Body will come after MQMD header and any other additional header. The message sent to the Out termainal of the Aggregate Reply node will also have a similar structure as the message sent to the Timeout terminal.
Regards,
VK. |
|
| Back to top |
|
|
| _Angus_ |
| Posted: Fri Oct 27, 2006 7:23 am Post subject: |
|
|
Acolyte
Joined: 25 Apr 2005
Posts: 54
Location: Edinburgh
|
Thanks for your help VK - I've actually sorted it now. The only thing I was missing was the MRM tag (the reply I was interested in is CWF).
I needed:
InputRoot.ComIbmAggregateReplyBody.{cFolderName}.MRM.{fieldName}
works a treat now.
As an aside, I have noticed if the compute node hanging off the catch blows up the flow gets very confused and seems to throw lots of time outs - this is what results in the records being left in the BAGGREGATE table :-|
Thanks again
_________________
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Angus Cooke ~ AngusSoft
Integration Development Tools
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Oct 27, 2006 1:08 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| _Angus_ wrote: |
As an aside, I have noticed if the compute node hanging off the catch blows up the flow gets very confused and seems to throw lots of time outs - this is what results in the records being left in the BAGGREGATE table :-|
Thanks again |
That's why we have a Filter built in before the compute node.
If the redelivered count is greater than x the filter just drops the message. This gets rid of unwanted (late) messages... especially if they blow up later in the catch branch...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
