ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Aggregate Flow Not Finding Original Message

Post new topic  Reply to topic
 Aggregate Flow Not Finding Original Message « View previous topic :: View next topic » 
Author Message
EricCox
PostPosted: Fri Apr 08, 2011 8:45 am    Post subject: Aggregate Flow Not Finding Original Message Reply with quote

Master

Joined: 08 Apr 2011
Posts: 292

Could someone help me figure out why my AGG_RS flow is not finding the original message and allowing the message to flow into the MAIN_RS_FLOW

I am using AggregateControl, AggregateRequest and AggregateReply to handle timeout issues only.

I have:
ServiceConsumer>>>AGG_RQ>>>MAIN_RQ_FLOW
ServiceDelivery>>>AGG_RS>>>MAIN_RS_FLOW>>>ServiceConsumer

The AGG_RQ uses the AggregateControl to set the timeout and has a AggregateRequest node setting the folder on its way out to the MAIN_RQ_FLOW.

The AGG_RS flow does not find the original message and does not allow the message to flow to the MAIN_RS_FLOW.

Here are the sections of the trace that catch my eye.

Here it looks like as I propogate the message to the storage queue the AGG_RS flow tries to pick it up at the same time the main
request flow begins to process.

2011-04-08 08:43:25.011137 11348 UserTrace BIP2537I: Node 'TLR_AGG_RQ.Propagate Orig Msg': Executing statement ''RETURN TRUE;'' at ('.TLR_AGG_RQ_Propogate_Orig_Msg.Main', '10.3').
2011-04-08 08:43:25.011234 11348 UserTrace BIP4007I: Message propagated to 'out' terminal of node 'TLR_AGG_RQ.Propagate Orig Msg'.
2011-04-08 08:43:25.054632 11348 UserTrace BIP2638I: The MQ output node 'TLR_AGG_RQ.IAB.TLR.AGG.ORIG.RQ.IN' attempted to write a message to queue ''IAB.TLR.AGG.ORIG.RQ.IN'' connected to queue manager ''''. The MQCC was '0' and the MQRC was '0'.
2011-04-08 08:43:25.054731 11348 UserTrace BIP2622I: Message successfully output by output node 'TLR_AGG_RQ.IAB.TLR.AGG.ORIG.RQ.IN' to queue ''IAB.TLR.AGG.ORIG.RQ.IN'' on queue manager ''''.
2011-04-08 08:43:25.205026 1492 UserTrace BIP2632I: Message received and propagated to 'out' terminal of MQ input node 'TLR_AGG_RS.IAB.TLR.AGG.ORIG.RQ.IN'.
2011-04-08 08:43:25.205795 1492 UserTrace BIP6060I: Parser type ''Properties'' created on behalf of node 'TLR_AGG_RS.IAB.TLR.AGG.ORIG.RQ.IN' to handle portion of incoming message of length 0 bytes beginning at offset '0'.
2011-04-08 08:43:25.207307 1492 UserTrace BIP6061I: Parser type ''MQMD'' created on behalf of node 'TLR_AGG_RS.IAB.TLR.AGG.ORIG.RQ.IN' to handle portion of incoming message of length '364' bytes beginning at offset '0'. Parser type selected based on value ''MQHMD'' from previous parser.
2011-04-08 08:43:25.207479 1492 UserTrace BIP6061I: Parser type ''BLOB'' created on behalf of node 'TLR_AGG_RS.IAB.TLR.AGG.ORIG.RQ.IN' to handle portion of incoming message of length '3926' bytes beginning at offset '364'. Parser type selected based on value ''NONE'' from previous parser.
2011-04-08 08:43:25.210180 4396 UserTrace BIP2632I: Message received and propagated to 'out' terminal of MQ input node 'TLR_RQ.IAB.TLR.MONETARY.RQ.IN'.
2011-04-08 08:43:25.212095 4396 UserTrace BIP6060I: Parser type ''Properties'' created on behalf of node 'TLR_RQ.IAB.TLR.MONETARY.RQ.IN' to handle portion of incoming message of length 0 bytes beginning at offset '0'.
2011-04-08 08:43:25.213127 1492 UserTrace BIP2537I: Node 'TLR_AGG_RS.CopyMsgIdToCorelId': Executing statement ''BEGIN ... END;'' at ('.TLR_AGG_RS_CopyMsgIdToCorellId.main', '1.41').
2011-04-08 08:43:25.213312 1492 UserTrace BIP2537I: Node 'TLR_AGG_RS.CopyMsgIdToCorelId': Executing statement ''SET OutputRoot = InputRoot;'' at ('.TLR_AGG_RS_CopyMsgIdToCorellId.main', '2.3').
2011-04-08 08:43:25.213378 4396 UserTrace BIP6061I: Parser type ''MQMD'' created on behalf of node 'TLR_RQ.IAB.TLR.MONETARY.RQ.IN' to handle portion of incoming message of length '364' bytes beginning at offset '0'. Parser type selected based on value ''MQHMD'' from previous parser.
2011-04-08 08:43:25.213483 1492 UserTrace BIP2539I: Node 'TLR_AGG_RS.CopyMsgIdToCorelId': Evaluating expression ''InputRoot'' at ('.TLR_AGG_RS_CopyMsgIdToCorellId.main', '2.20'). This resolved to ''InputRoot''. The result was ''ROW... Root Element Type=16777216 NameSpace='' Name='Root' Value=NULL''.
2011-04-08 08:43:25.213550 1492 UserTrace BIP2568I: Node 'TLR_AGG_RS.CopyMsgIdToCorelId': Copying sub-tree from ''InputRoot'' to ''OutputRoot''.
2011-04-08 08:43:25.214057 1492 UserTrace BIP2537I: Node 'TLR_AGG_RS.CopyMsgIdToCorelId': Executing statement ''SET OutputRoot.MQMD.CorrelId = InputRoot.MQMD.MsgId;'' at ('.TLR_AGG_RS_CopyMsgIdToCorellId.main', '4.3').
2011-04-08 08:43:25.214136 1492 UserTrace BIP2539I: Node 'TLR_AGG_RS.CopyMsgIdToCorelId': Evaluating expression ''InputRoot.MQMD.MsgId'' at ('.TLR_AGG_RS_CopyMsgIdToCorellId.main', '4.34'). This resolved to ''InputRoot.MQMD.MsgId''. The result was ''ROW... Root Element Type=50331648 NameSpace='' Name='MsgId' Value=X'414d5120514d424b524430312020202034ef774d238ebc03'''.
2011-04-08 08:43:25.214206 1492 UserTrace BIP2568I: Node 'TLR_AGG_RS.CopyMsgIdToCorelId': Copying sub-tree from ''InputRoot.MQMD.MsgId'' to ''OutputRoot.MQMD.CorrelId''.
2011-04-08 08:43:25.214307 1492 UserTrace BIP2537I: Node 'TLR_AGG_RS.CopyMsgIdToCorelId': Executing statement ''RETURN TRUE;'' at ('.TLR_AGG_RS_CopyMsgIdToCorellId.main', '5.3').
2011-04-08 08:43:25.214391 1492 UserTrace BIP4007I: Message propagated to 'out' terminal of node 'TLR_AGG_RS.CopyMsgIdToCorelId'.
2011-04-08 08:43:25.219575 4396 UserTrace BIP6061I: Parser type ''XML'' created on behalf of node 'TLR_RQ.IAB.TLR.MONETARY.RQ.IN' to handle portion of incoming message of length '3951' bytes beginning at offset '364'. Parser type selected based on value ''XML'' from previous parser.
2011-04-08 08:43:25.233001 4396 UserTrace BIP2537I: Node 'TLR_RQ.CalcStartTime.CalcStartTime': Executing statement ''BEGIN ... END;'' at ('.CalcStartTime_V1R0M0_CalcStartTime.main', '1.40').
2011-04-08 08:43:25.233095 4396 UserTrace BIP2537I: Node 'TLR_RQ.CalcStartTime.CalcStartTime': Executing statement ''SET OutputRoot = InputRoot;'' at ('.CalcStartTime_V1R0M0_CalcStartTime.main', '2.1').
2011-04-08 08:43:25.233161 4396 UserTrace BIP2539I: Node 'TLR_RQ.CalcStartTime.CalcStartTime': Evaluating expression ''InputRoot'' at ('.CalcStartTime_V1R0M0_CalcStartTime.main', '2.18'). This resolved to ''InputRoot''. The result was ''ROW... Root Element Type=16777216 NameSpace='' Name='Root' Value=NULL''.
2011-04-08 08:43:25.233213 4396 UserTrace BIP2568I: Node 'TLR_RQ.CalcStartTime.CalcStartTime': Copying sub-tree from ''InputRoot'' to ''OutputRoot''.
2011-04-08 08:43:25.236980 4396 UserTrace BIP2537I: Node 'TLR_RQ.CalcStartTime.CalcStartTime': Executing statement ''DECLARE startTime INTERVAL;'' at ('.CalcStartTime_V1R0M0_CalcStartTime.main', '4.1').
2011-04-08 08:43:25.237041 4396 UserTrace BIP2537I: Node 'TLR_RQ.CalcStartTime.CalcStartTime': Executing statement ''SET startTime = CURRENT_GMTTIMESTAMP - GMTTIMESTAMP '2002-01-01 00:00:00';'' at ('.CalcStartTime_V1R0M0_CalcStartTime.main', '7.1').
2011-04-08 08:43:25.238597 4396 UserTrace BIP2540I: Node 'TLR_RQ.CalcStartTime.CalcStartTime': Finished evaluating expression ''CURRENT_GMTTIMESTAMP'' at ('.CalcStartTime_V1R0M0_CalcStartTime.main', '7.18'). The result was ''GMTTIMESTAMP '2011-04-08 12:43:25.211535'''.
2011-04-08 08:43:25.247583 1492 UserTrace BIP4412I: Corresponding request record not found for the reply message.
An AggregateReply node has received a message at its 'in' terminal. No corresponding record of a request message being sent could be found. See subsequent messages to determine how this situation has been handled.
It is possible that extraneous messages are arriving at the AggregateReply node 'in' terminal. Check your flow to ensure that the only messages arriving here are replies to request messages previously sent out and passed through an AggregateRequest node. It is possible that this message is a valid reply but part of an aggregation which previously timed out. It is possible that this is a reply to a message which has not yet been recorded by an AggregateRequest node. This can happen if request messages are sent outside of transactional control. Adjust your transaction settings to ensure that messages are sent under transactional control.
2011-04-08 08:43:25.255105 4396 UserTrace BIP2539I: Node 'TLR_RQ.CalcStartTime.CalcStartTime': Evaluating expression ''CURRENT_GMTTIMESTAMP - GMTTIMESTAMP '2002-01-01 00:00:00''' at ('.CalcStartTime_V1R0M0_CalcStartTime.main', '7.39'). This resolved to ''GMTTIMESTAMP '2011-04-08 12:43:25.211535' - GMTTIMESTAMP '2002-01-01 00:00:00'''. The result was ''INTERVAL '292423405.211535' SECOND''.
2011-04-08 08:43:25.255231 4396 UserTrace BIP2537I: Node 'TLR_RQ.CalcStartTime.CalcStartTime': Executing statement ''SET Environment.TimingData.StartTime = startTime;'' at ('.CalcStartTime_V1R0M0_CalcStartTime.main', '8.1').
2011-04-08 08:43:25.255332 4396 UserTrace BIP2539I: Node 'TLR_RQ.CalcStartTime.CalcStartTime': Evaluating expression ''startTime'' at ('.CalcStartTime_V1R0M0_CalcStartTime.main', '8.46'). This resolved to ''startTime''. The result was ''INTERVAL '292423405.211535' SECOND''.
2011-04-08 08:43:25.255405 4396 UserTrace BIP2566I: Node 'TLR_RQ.CalcStartTime.CalcStartTime': Assigning value ''INTERVAL '292423405.211535' SECOND'' to field / variable ''Environment.TimingData.StartTime''.
2011-04-08 08:43:25.255458 4396 UserTrace BIP2537I: Node 'TLR_RQ.CalcStartTime.CalcStartTime': Executing statement ''RETURN TRUE;'' at ('.CalcStartTime_V1R0M0_CalcStartTime.main', '11.1').
2011-04-08 08:43:25.255544 4396 UserTrace BIP4007I: Message propagated to 'out' terminal of node 'TLR_RQ.CalcStartTime.CalcStartTime'.
2011-04-08 08:43:25.264316 1492 UserTrace BIP4413I: Storing unknown message persistently for subsequent processing.
The message has been stored persistently by the AggregateReply node. If it is subsequently discovered to be a valid reply in an aggregation then it will be processed as such at that time. If a number of seconds passes as specified by the 'unknown timeout' attribute, then the message will be propagated to the 'unknown' terminal.
No user action required.



Then later when the response comes in the flow can't find the original and ceases to execute the flow.

2011-04-08 08:43:27.630090 4920 UserTrace BIP6061I: Parser type ''MQMD'' created on behalf of node 'TLR_AGG_RS.IAB.TLR.AGG.RS.IN' to handle portion of incoming message of length '364' bytes beginning at offset '0'. Parser type selected based on value ''MQHMD'' from previous parser.
2011-04-08 08:43:27.630266 4920 UserTrace BIP6061I: Parser type ''BLOB'' created on behalf of node 'TLR_AGG_RS.IAB.TLR.AGG.RS.IN' to handle portion of incoming message of length '4374' bytes beginning at offset '364'. Parser type selected based on value ''NONE'' from previous parser.
2011-04-08 08:43:27.638023 4920 UserTrace BIP4412I: Corresponding request record not found for the reply message.
An AggregateReply node has received a message at its 'in' terminal. No corresponding record of a request message being sent could be found. See subsequent messages to determine how this situation has been handled.
It is possible that extraneous messages are arriving at the AggregateReply node 'in' terminal. Check your flow to ensure that the only messages arriving here are replies to request messages previously sent out and passed through an AggregateRequest node. It is possible that this message is a valid reply but part of an aggregation which previously timed out. It is possible that this is a reply to a message which has not yet been recorded by an AggregateRequest node. This can happen if request messages are sent outside of transactional control. Adjust your transaction settings to ensure that messages are sent under transactional control.
2011-04-08 08:43:27.647132 4920 UserTrace BIP4413I: Storing unknown message persistently for subsequent processing.
The message has been stored persistently by the AggregateReply node. If it is subsequently discovered to be a valid reply in an aggregation then it will be processed as such at that time. If a number of seconds passes as specified by the 'unknown timeout' attribute, then the message will be propagated to the 'unknown' terminal.
No user action required.
2011-04-08 08:43:31.614786 5716 UserTrace BIP6060I: Parser type ''Properties'' created on behalf of node 'TLR_AGG_RS.processMonetary' to handle portion of incoming message of length 0 bytes beginning at offset '0'.
2011-04-08 08:43:31.615892 5716 UserTrace BIP6061I: Parser type ''MQMD'' created on behalf of node 'TLR_AGG_RS.processMonetary' to handle portion of incoming message of length '364' bytes beginning at offset '0'. Parser type selected based on value ''MQHMD'' from previous parser.
2011-04-08 08:43:31.616142 5716 UserTrace BIP6061I: Parser type ''BLOB'' created on behalf of node 'TLR_AGG_RS.processMonetary' to handle portion of incoming message of length '3926' bytes beginning at offset '364'. Parser type selected based on value ''NONE'' from previous parser.
2011-04-08 08:43:36.549266 5716 UserTrace BIP6060I: Parser type ''Properties'' created on behalf of node 'TLR_AGG_RS.processMonetary' to handle portion of incoming message of length 0 bytes beginning at offset '0'.
2011-04-08 08:43:36.549533 5716 UserTrace BIP6061I: Parser type ''MQMD'' created on behalf of node 'TLR_AGG_RS.processMonetary' to handle portion of incoming message of length '364' bytes beginning at offset '0'. Parser type selected based on value ''MQHMD'' from previous parser.
2011-04-08 08:43:36.550010 5716 UserTrace BIP6061I: Parser type ''BLOB'' created on behalf of node 'TLR_AGG_RS.processMonetary' to handle portion of incoming message of length '4374' bytes beginning at offset '364'. Parser type selected based on value ''NONE'' from previous parser.
2011-04-08 08:44:03.028563 2888 UserTrace BIP2632I: Message received and propagated to 'out' terminal of MQ input node 'ConfigurationMessageFlow.InputNode'.
2011-04-08 08:44:03.028896 2888 UserTrace BIP6060I: Parser type ''Properties'' created on behalf of node 'ConfigurationMessageFlow.InputNode' to handle portion of incoming message of length 0 bytes beginning at offset '0'.
2011-04-08 08:44:03.029011 2888 UserTrace BIP6061I: Parser type ''MQMD'' created on behalf of node 'ConfigurationMessageFlow.InputNode' to handle portion of incoming message of length '364' bytes beginning at offset '0'. Parser type selected based on value ''MQHMD'' from previous parser.
2011-04-08 08:44:03.029242 2888 UserTrace BIP6061I: Parser type ''XMLS'' created on behalf of node 'ConfigurationMessageFlow.InputNode' to handle portion of incoming message of length '348' bytes beginning at offset '364'. Parser type selected based on value ''XMLS'' from previous parser.

Here is the AggregateResponse Module

CREATE COMPUTE MODULE "TLR_AGG_RS_ComputeAggResponse"
CREATE FUNCTION Main() RETURNS BOOLEAN BEGIN

DECLARE I INTEGER 1;
DECLARE J INTEGER;
SET J = CARDINALITY(InputRoot.*[]);
WHILE I < J DO
SET OutputRoot.*[I] = InputRoot.*[I];
SET I = I + 1;
END WHILE;

SET OutputRoot.Properties.MessageDomain = 'XML';
SET OutputRoot.Properties.MessageFormat = 'XML';
-- Set MQMD Variables
SET OutputRoot.MQMD = InputRoot.ComIbmAggregateReplyBody.Teller.MQMD;

/* Copy the TellerProcessMonetary XML to the output */
SET OutputRoot.XML = InputRoot.ComIbmAggregateReplyBody.Teller.XML;
----------------------------------------------------------------
DECLARE ref_MsgHdrRq REFERENCE TO InputRoot.ComIbmAggregateReplyBody.OrigRequest.XML."cfg-env:Envelope"."cfg-env:Header"."cfg-hdr:MessageHeader";
DECLARE ref_MsgHdrRs REFERENCE TO OutputRoot.XML."cfg-env:Envelope"."cfg-env:Header"."cfg-hdr:MessageHeader";
DECLARE ref_TellerRq REFERENCE TO InputRoot.ComIbmAggregateReplyBody.OrigRequest.XML."cfg-env:Envelope"."cfg-env:Body"."CFX".TellerRq;
DECLARE ref_TellerRs REFERENCE TO OutputRoot.XML."cfg-env:Envelope"."cfg-env:Body"."CFX".ProcessMonetaryRs;
DECLARE numReq INTEGER;

SET numReq = CAST(InputRoot.ComIbmAggregateReplyBody.OrigRequest.XML."cfg-env:Envelope"."cfg-env:Header"."cfg-hdr:MessageHeader"."cfg-hdr:ControlOptions"."cfg-hdr:TellerControl"."cfg-hdr:SeqNumber" AS INTEGER);

IF numReq = -1 THEN
SET ref_MsgHdrRs."cfg-hdr:ControlOptions" = NULL;
ELSE
SET ref_MsgHdrRs."cfg-hdr:ControlOptions" =
InputRoot.ComIbmAggregateReplyBody.Teller.XML."cfg-env:Envelope"."cfg-env:Header"."cfg-hdr:MessageHeader"."cfg-hdr:ControlOptions";
END IF;


---------------------------SetUp MQMD details----------------------------------

--Note: we need to ensure the correlid is the msgid from the original request.
SET OutputRoot.MQMD.ReplyToQ = InputRoot.ComIbmAggregateReplyBody.OrigRequest.MQMD.ReplyToQ;
SET OutputRoot.MQMD.ReplyToQMgr = InputRoot.ComIbmAggregateReplyBody.OrigRequest.MQMD.ReplyToQMgr;

SET OutputRoot.MQMD.CorrelId = InputRoot.ComIbmAggregateReplyBody.OrigRequest.MQMD.MsgId;
--Delete the CorrelID from the MessageHeader
SET OutputRoot.XML."cfg-env:Envelope"."cfg-env:Header"."cfg-hdr:MessageHeader"."cfg-hdr:CorrelId" = Null;
SET OutputRoot.MQMD.Report = MQRO_NEW_MSG_ID;
SET OutputRoot.MQMD.Report = BITOR( OutputRoot.MQMD.Report, MQRO_PASS_CORREL_ID);

SET OutputRoot.MQMD.MsgType = MQMT_REPLY;
-- Delete the OrigReplyToQ definition from the response
SET OutputRoot.XML."cfg-env:Envelope"."cfg-env:Header"."cfg-hdr:MessageHeader"."cfg-hdr:From"."cfg-hdr:OrigReplyToQ" = Null;


RETURN TRUE;

END;
END MODULE;

Please give me some details on what to look for in troubleshooting this. Let me know what you'd like to see and I'll post it.

Thanks,
Eric
Back to top
View user's profile Send private message
mqjeff
PostPosted: Fri Apr 08, 2011 9:12 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

It sounds like the reply that is coming back does not match up to the request that has been sent out.

Put a trace node right before the AggregateRequest node, and right before the AggregateReply node and make sure that the correct things are set for messages that are supposed to match up.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Fri Apr 08, 2011 7:33 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

If you run a request reply model through the aggregation and you do have 2 different flows, like in fan-out flow and fan-in flow, you need to make sure in the fan-out flow that you also send the original message to the aggregation fan-in with the appropriate information....

One way to do so is to set up a dummy service that just turns the message around and sends it to the reply to queue with the appropriate correl id.

Now in the aggregation you receive not only the original message but also the other messages in the aggregation and you can set up an accurate aggregated reply.

Have fun.
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Aggregate Flow Not Finding Original Message
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.