| Author |
Message
|
| jhotaling |
 Posted: Tue Mar 25, 2003 7:38 am Post subject: aggregation flow question |
 |
|
Newbie
Joined: 25 Mar 2003
Posts: 7
Location: Maryland
|
Has anyone handled a situation where NO replies were received. What appears to happen is that a totally null message  is propagated to the timeout terminal of the AggregateReply node. I need some sort of reference to the original input message so I can "inform" the requestor that no replies were received (i want to use the same MQ headers as the input message). I've tried try/catch right after the MQInput, but WMQI appears to go into a "loop" retrying to process the original request.
Thanks in advance! |
|
| Back to top |
|
 |
| tillywern |
| Posted: Tue Mar 25, 2003 3:47 pm Post subject: Cache the message |
|
|
Centurion
Joined: 28 Jan 2003
Posts: 109
Location: Colorado
|
You have to cache the message... You can push the message into a database table that would allow the original to be inserted and retrieved.
You could also try to force and error and see if you can recover the incomming message with try catch but wire the error output to a reply node or whatever..
The database option will work but requires more code.. But you would probably use code like that in more than one place so it would be worth the time. |
|
| Back to top |
|
|
| lillo |
| Posted: Tue Mar 25, 2003 11:54 pm Post subject: |
|
|
Master
Joined: 11 Sep 2001
Posts: 224
|
You can also have an extra branch which will pass your original message to the fan-in message flow. So, if everything works fine (no timeout) in your output terminal you will have the original message and your replies. And if you get the timeout in your timeout terminal you will only get your original message.
I hope this help you.
Cheers,
_________________
Lillo
IBM Certified Specialist - WebSphere MQ |
|
| Back to top |
|
|
| jhotaling |
| Posted: Thu Mar 27, 2003 12:46 pm Post subject: |
|
|
Newbie
Joined: 25 Mar 2003
Posts: 7
Location: Maryland
|
Thanks for the suggestions - I went with a MQReply Node approach - basically sending a derivation of the original message to an output queue (which had the Request/Reply-To stuff set in it) which feeds a MQReply, always ensuring a reply.
Now, I am pulling my hair out  as the timed-out partial reply appears (or so my trace nodes tell me...) to be put into the output queue where the consolidated response is expected, BUT when I use MQExplorer to browse the queue - NOTHING is there. No bad things in W2K event viewer & no exceptions as far as I can tell.
Weird thing is Transactional = TRUE for all traced messages until the AggregateReply node times out - all downstream messages from there have Transactional = UNKNOWN
or Transactional = FALSE.
Any suggestions?
Thanks again! |
|
| Back to top |
|
|
| jhotaling |
| Posted: Thu Mar 27, 2003 1:41 pm Post subject: Think I found it |
|
|
Newbie
Joined: 25 Mar 2003
Posts: 7
Location: Maryland
|
I added the following in my compute node:
Set OutputRoot.Properties.CreationTime = CURRENT_GMTTIMESTAMP;
Set OutputRoot.Properties.ReplyProtocol = 'MQ';
Set OutputRoot.Properties.Transactional = TRUE;
Set OutputRoot.Properties.Persistence = TRUE;
Which "fixed" the NULL & UNKNOWNs that resulted from the AggregateReply timeout "result" and the message ended up in the output queue FINALLY. FYI: Here's the output from the AggregateReply timeout that ruined my day:
2003-03-27 16:13:38.097 - Timeout PARTIAL Msg: (
(0x1000000)Properties = (
(0x3000000)MessageSet = NULL
(0x3000000)MessageType = NULL
(0x3000000)MessageFormat = NULL
(0x3000000)Encoding = NULL
(0x3000000)CodedCharSetId = NULL
(0x3000000)Transactional = UNKNOWN
(0x3000000)Persistence = UNKNOWN
(0x3000000)CreationTime = NULL
(0x3000000)ExpirationTime = NULL
(0x3000000)Priority = NULL
(0x3000000)ReplyIdentifier = NULL
(0x3000000)ReplyProtocol = NULL
(0x3000000)Topic = NULL )
(0x1000000)ComIbmAggregateReplyBody = (
(0x1000000)NoReply = (
(0x1000000)Properties = (
(0x3000000)MessageSet = ''
(0x3000000)MessageType = ''
(0x3000000)MessageFormat = ''
(0x3000000)Encoding = 546
(0x3000000)CodedCharSetId = 437
(0x3000000)Transactional = FALSE
(0x3000000)Persistence = FALSE
(0x3000000)CreationTime = NULL
(0x3000000)ExpirationTime = -1
(0x3000000)Priority = 0
(0x3000000)ReplyIdentifier = X'414d51204a5744322020202020202020b100ac3e20003e01'
(0x3000000)ReplyProtocol = NULL
(0x3000000)Topic = NULL
)
(0x1000000)MQMD = (
(0x3000000)SourceQueue = ''
(0x3000000)Transactional = FALSE
(0x3000000)Encoding = 546
(0x3000000)CodedCharSetId = 437
(0x3000000)Format = 'MQSTR '
(0x3000000)Version = 2
(0x3000000)Report = 0
(0x3000000)MsgType = 2
(0x3000000)Expiry = -1
(0x3000000)Feedback = 0
(0x3000000)Priority = 0
(0x3000000)Persistence = 0
(0x3000000)MsgId = X'414d51204a5744322020202020202020b100ac3e20003a04'
(0x3000000)CorrelId = X'414d51204a5744322020202020202020b100ac3e20003e01'
(0x3000000)BackoutCount = 0
(0x3000000)ReplyToQ = ' '
(0x3000000)ReplyToQMgr = 'JWD2 '
(0x3000000)UserIdentifier = 'db2admin '
(0x3000000)AccountingToken = X'0000000000000000000000000000000000000000000000000000000000000000'
(0x3000000)ApplIdentityData = ' '
(0x3000000)PutApplType = 26
(0x3000000)PutApplName = 'JWD2 '
(0x3000000)PutDate = DATE '2003-03-27'
(0x3000000)PutTime = GMTTIME '21:13:07.630'
(0x3000000)ApplOriginData = ' '
(0x3000000)GroupId = X'000000000000000000000000000000000000000000000000'
(0x3000000)MsgSeqNumber = 1
(0x3000000)Offset = 0
(0x3000000)MsgFlags = 0
(0x3000000)OriginalLength = -1
)
(0x1000010)XML = (
(0x1000000)DUMMY_REPLY = (
(0x2000000) = 'Broker Generated Dummy Reply Message to prevent Timeout when no other replies are received.'
)
)
)
)
)
I can't imgaine why the timeout, with partial responses received, didn't work like the non-timeout case (which had transactional and persistent both set to TRUE with no intevention on my behalf).
 |
|
| Back to top |
|
|
|
|
