| Author |
Message
|
| AlexeiSkate |
 Posted: Wed Jul 10, 2002 12:43 pm Post subject: Propagating messages out of a loop |
 |
|
Centurion
Joined: 10 Apr 2002
Posts: 123
|
I have an input XML message with one header and multiple lines. If I have a while loop to iterate over each line, is it possible to send each line to another subflow to do some calculations and then come back to the same loop again ( I guess it's similar to doing a function call within the loop in the traditional programming practice) ?
thanks,
Alex |
|
| Back to top |
|
 |
| lillo |
| Posted: Wed Jul 10, 2002 1:48 pm Post subject: |
|
|
Master
Joined: 11 Sep 2001
Posts: 224
|
It is possible to forward those lines individually to continue the message flow with the PROPAGATE esql command. But from this point you will have different message in the flow. Until the first message doesn´t finish to process the next one won´t be processed.
So, I suggest you to combine the PROPAGATE with the aggregate. Then you message flows will be:
1.- a message flow to do the different request for the lines in your message.
2.- a message flow to process the messages you generate.
3.- a message flow to collect the replies.
I hope this help you. I have done something similar and it is quite easy to do. Ask if you need more help.
Cheers
_________________
Lillo
IBM Certified Specialist - WebSphere MQ |
|
| Back to top |
|
|
| matthews |
| Posted: Wed Jul 10, 2002 1:56 pm Post subject: Using Propogate |
|
|
Novice
Joined: 15 Apr 2002
Posts: 12
|
Alex,
In WMQI there is the Propagate function. It is intended/designed to allow a message flow to generate multiple output messages without having to do additional filtering and looping. When you code the Propagate function, the compute node stops at that poing and sends the current OutputRoot tree out the "Out" terminal. When all nodes have finished, then control returns to the next ESQL statement in the compute node - BUT - the OutputRoot tree is now EMPTY. Thus, you must rebuild the entire tree again, ie properties, mqmd, etc.
One thought is to have a filter node that could check something to decide if the subflow should be called - or if the message is really finished..
Looks like it should be doable.
Cheers,
Bill |
|
| Back to top |
|
|
| kirani |
| Posted: Wed Jul 10, 2002 2:16 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Bill,
Sending output empty tree after propagate command can be avoided by having the SQL return FALSE towards the end of the node. For example,
| Code: |
WHILE loop
....
....
PROPAGETE;
increment counter
END WHILE;
RETURN FALSE;
|
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| AlexeiSkate |
| Posted: Thu Jul 11, 2002 9:18 am Post subject: |
|
|
Centurion
Joined: 10 Apr 2002
Posts: 123
|
Hi,
Thanks for the replies.
So at the point of PROPAGATION, my msg line is essentially a separate msg that will continue will the rest of the msg flow that's connected to the ComputeNode's output terminal, and the only purpose for going back to the ComputeNode is to increment the index to get the next msg line. Is this correct ? If my input XML msg is one Header and two lines, the msg leaving the Compute node terminal will not also be one Header and two lines, but will be two lines that is each a separate msg ?
Lillo, in the scenario that you described, are you saying that I can propagate each of my line to a msg flow for processing and then send each of those line to an aggregate reply/request flow to reassemble the lines into one msg ?
thanks,
Alex |
|
| Back to top |
|
|
| kirani |
| Posted: Thu Jul 11, 2002 3:47 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Alex,
| AlexeiSkate wrote: |
So at the point of PROPAGATION, my msg line is essentially a separate msg that will continue will the rest of the msg flow that's connected to the ComputeNode's output terminal, and the only purpose for going back to the ComputeNode is to increment the index to get the next msg line. Is this correct ?
|
Yes, you will come back to the compute node to increment the index and get the next msg.
| AlexeiSkate wrote: |
If my input XML msg is one Header and two lines, the msg leaving the Compute node terminal will not also be one Header and two lines, but will be two lines that is each a separate msg ?
|
It depends whether you want to propagate header message or not. If you decide not to propagate Header message, you could add an if loop within your while loop to check for header message and increment the counter directly (without propagating).
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| lillo |
| Posted: Thu Jul 11, 2002 10:14 pm Post subject: |
|
|
Master
Joined: 11 Sep 2001
Posts: 224
|
| Quote: |
Lillo, in the scenario that you described, are you saying that I can propagate each of my line to a msg flow for processing and then send each of those line to an aggregate reply/request flow to reassemble the lines into one msg ?
|
Yes, I have a similar scenario. It´s important, for the aggregate to work, to generate a new messageId in the MQOutput node. This is because the messageId is recorded in the broker database.
I hope this help you.
Cheers
_________________
Lillo
IBM Certified Specialist - WebSphere MQ |
|
| Back to top |
|
|
| AlexeiSkate |
| Posted: Fri Jul 12, 2002 9:54 am Post subject: |
|
|
Centurion
Joined: 10 Apr 2002
Posts: 123
|
This is what I have in my compute node:
DECLARE i INTEGER;
SET i = 1;
WHILE i <= CARDINALITY(InputRoot.XML."MellonDepositConfirmationTransaction"."MellonDepositConfirmationLine"[]) DO
SET OutputRoot = InputRoot;
SET OutputRoot.XML = NULL;
SET OutputRoot.XML.BookSold."MD01" =
InputRoot.XML."MellonDepositConfirmationTransaction"."MD01";
SET OutputRoot.XML.BookSold."TransactionLine" =
InputRoot.XML."MellonDepositConfirmationTransaction"."MellonDepositConfirmationLine"[i];
PROPAGATE;
SET i = i + 1;
END WHILE;
RETURN FALSE;
How can I set the MsgId of each message propagated to be unique ? I tried just doing 'SET "OutputRoot"."MQMD"."MsgId" = UUIDASBLOB;", expecting the uuidasblob function to automatically generate an id but I get the 'length must be correct' error message from the mqmd parser. |
|
| Back to top |
|
|
| kirani |
| Posted: Fri Jul 12, 2002 4:42 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Alex,
| AlexeiSkate wrote: |
...is it possible to send each line to another subflow to do some calculations and then come back to the same loop again...
|
Could you tell us about your requirement and What processing are you planning to do in your subflow? May be Aggregation is not required at all.
I don't think you can use uuidasblob function to create new Message ID. You could configure your MQOutput node to generate unique message id by select "New Message ID" in Advanced tab.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| AlexeiSkate |
| Posted: Sun Jul 14, 2002 12:14 pm Post subject: |
|
|
Centurion
Joined: 10 Apr 2002
Posts: 123
|
Kirani,
My input XML message consists of one header and multiple lines. For each of the line, I have to send it to a subflow(s) that will request some reference information specific to each line from an external application. I'll then have to reform the original header and each of the line messages back into one message of one header and multiple lines and then decide what to do from there, depending on whether each of the line message was able to successfully retrieved its referenced information.
I'll have one top level Aggregate Request-Reply flow to take in the original XML message; This flow propagates each line of the original message to subflows to retrieve reference information and then regroup them back into one msg of one header and multiple lines.
My process to retrieve the reference information for each line has to be done in a two-steps process because of the way the external application is handling the request. I have one Aggregate Request/Reqply subflow to do the first request for each line. Then the reply of this request has to be sent to another Aggregate Request/Reply subflow in order to get the specific referenced information required for each line.
So right now I have one main flow and two subflows, each of which is an Aggregate Request-Reply flow.
1) Do I need to keep track of the msg ids throughout these three flows so that at the end I'll have back an XML msg on one header and multiple lines ?
2) I think if I propagate the lines in a compute node and the compute node is in an Aggregate Request-Reply flow, then I'll have to manually assign each a distinct id. Doesn't the broker store the msg id into the repository,and then compare the reply msg's CorrId to the original msgId to determine how to aggregate the reply ?
3) I've seen this example in a Compute Node: [ SET "OutputRoot"."MQMD"."MsgId" = uuidasblob || x'0000000000000000'; ]. I'm not sure what ORING the uuidasblob function with the hexadecimal specification does, but doesn't this generate a uniquid MsgId ?
Thanks for any help you can provide.
-Alex |
|
| Back to top |
|
|
| AlexeiSkate |
| Posted: Mon Jul 15, 2002 7:11 am Post subject: |
|
|
Centurion
Joined: 10 Apr 2002
Posts: 123
|
Actually, I don't think I need the "SET "OutputRoot"."MQMD"."MsgId" = uuidasblob || x'0000000000000000' " statement in my compute node at all. As long as I set the CorrId of the reply msg to the MsgId of the request msg by either indirectly using the ReplyNode or directly setting it in the compute node, the aggregate reply/request flow seems to work ok.
Can you send a message coming out of one FanOut node into a subflow that also has a FanOut/FanIn implementation without having to directly change the message in some way ? When I send my msg coming out of the first FanOut node into a subflow that also has a FanOut node, the msg get sent to the DeadLetterQueue. |
|
| Back to top |
|
|
| kirani |
| Posted: Mon Jul 15, 2002 8:18 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Alex,
Sorry for my late reply.
Yes, you are correct. You don't need to keep track of Msg-ID throughout these flows. Also, you don't have to generate new Msg-ID within your message flow.
I guess, the reason your messages are going to DLQ is because of the following entry in LocalEnvironment Tree, which gets created by your AggregateRequest node in first fanout sub-flow.
| Code: |
(0x1000000)ComIbmAggregateControlNode = (
(0x3000000)aggregateName = 'XXXX'
(0x3000000)replyGroupId = '681deb1add8f479bb73a70ce3ac197eb'
(0x3000000)timeout = 0
)
|
Could you reset LocalEnvironment tree before the message is sent to secong Fan-OUT/Fan-IN sub-flow? What is the ReasonCode it is showing for the message that is sent to DLQ?
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
|
|
