| Author |
Message
|
| lung |
 Posted: Mon Oct 14, 2002 12:41 am Post subject: Aggregation |
 |
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
I'm having some problems trying to use those aggregation nodes in my message flow. Here's my scenario:
I'm receiving my input as an XML message (msg1), and in my request flow, I transform this message into a fixed-length message with certain fields changed. In my reply flow (which is in the same message flow, actually), I receive my input as a fixed-length message (msg2), in my flow, I transform this message back into an XML message with certain fields change. The changing of fields in msg2 requires some data from msg1, and to accomplish this, I opted for use of the aggregation nodes. Is there any other way to accomplish this if I'm not using the aggregation nodes?
Anyway, using the aggregation nodes, here's my design...
I wired my AggregateControl node just after my MQInput node in my request flow, and my AggregateRequest node to the OUT terminal of my AggregateControl node. OUT terminal of AggregateRequest node is wired to Compute node which leads to an MQOutput node. Control terminal of AggregateControl node is wired to CONTROL terminal of the AggregateReply node. MQInput node in my reply flow is wired to the IN terminal of the AggregateReply node. OUT terminal of Aggregate Reply node is wired to a Compute node which leads to the final MQOutput node. Is this correct?
Here's my problem... All my input messages in my reply flow, when going through the AggregateReply node, gets translated as an 'unknown' message and goes to the 'unknown' out terminal... How does the AggregateReply node determines if the messages is 'known' or 'unknown'?
Hope someone out there can answer my questions or give some suggestions on how to handle my scenario as described above, thanks!
_________________
lung |
|
| Back to top |
|
 |
| lillo |
| Posted: Mon Oct 14, 2002 2:56 am Post subject: |
|
|
Master
Joined: 11 Sep 2001
Posts: 224
|
The problem is with your design. Take a look to chapter 6 of "Developing solutions in WebSphere MQ Integrator". Here is the link http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246579.pdf
Chapter 6 covers the aggregation nodes in details and include an example of how implement this kind of message flow. Also discuss whether you should use a two message flow implementation or three message flow implementation.
If you have any problem, just tell me.
Cheers,
_________________
Lillo
IBM Certified Specialist - WebSphere MQ |
|
| Back to top |
|
|
| lung |
| Posted: Mon Oct 14, 2002 4:57 pm Post subject: |
|
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
Thanks lillo!
I will take a look at the document. In the meantime, do you have any suggestion on how I should handle my scenario? I will not want to use aggregation nodes if possible (performance hit)...
Thanks again!
_________________
lung |
|
| Back to top |
|
|
| lillo |
| Posted: Mon Oct 14, 2002 10:48 pm Post subject: |
|
|
Master
Joined: 11 Sep 2001
Posts: 224
|
Hi lung,
To pass the information you need from the input to the output I see three different possibilities:
Use a database
Use aggregate nodes
Pass the information in the message as a variable
Personally I prefer the database or aggregate nodes. If you decide to use the aggregate nodes I will use the three message flow implementation.
I hope this help you.
Cheers,
_________________
Lillo
IBM Certified Specialist - WebSphere MQ |
|
| Back to top |
|
|
| lung |
| Posted: Tue Oct 15, 2002 5:06 pm Post subject: |
|
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
Okay, my aggregation nodes are working now, but I couldn't get the output message in the correct format. Do I need to add an MQMD header myself after the aggregateReply node? What I did is, I put a compute node after the aggregateReply node with the following code...
| Code: |
SET OutputRoot.MQMD.Version = 2;
SET OutputRoot.MQMD.Format = 'MQSTR ';
SET OutputRoot.XML.Test = InputRoot.ComIbmAggregateReplyBody.Test; |
The output comes out in XML format, but together with all the message properties and the mqmd (in XML!)
So what's the workaround to this?
Thanks!
_________________
lung |
|
| Back to top |
|
|
| lillo |
| Posted: Tue Oct 15, 2002 10:07 pm Post subject: |
|
|
Master
Joined: 11 Sep 2001
Posts: 224
|
Lung,
You have to go lower in the XML tree. Change your SET for this one.
| Code: |
SET OutputRoot.XML.Test = InputRoot.ComIbmAggregateReplyBody.Test.XML;
|
Under ComIbmAggregateReplyBody you have as many folder as aggregation request message you send. In each of this folders you have the reply information. This reply is a WMQI message, then you have your Properties, MQMD and data, XML domain in your case.
I hope this help you. If you don´t understand the folder structure wire a trace node after the Aggregate reply node.
Cheers,
_________________
Lillo
IBM Certified Specialist - WebSphere MQ |
|
| Back to top |
|
|
| lung |
| Posted: Wed Oct 16, 2002 5:04 pm Post subject: |
|
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
It's working now, lillo... Thanks!
Okay, the aggregation flow works okay, but now I'm having problem trying to determine the timeout values of the AggregateControl and AggregateReply node... 
_________________
lung |
|
| Back to top |
|
|
| devans |
| Posted: Thu Oct 17, 2002 12:50 am Post subject: |
|
|
Apprentice
Joined: 18 Mar 2002
Posts: 43
|
| If your flows are transactional (which they ought to be for aggregation), set the "Unknown timeout" on the AggregateReply node to 0. The value that you set the "Timeout" value on the AggregateControl node depends on what your solution requires. If you can possibly get away with not using timeouts, then set it to '0' and things ought to run slightly faster. If you do want timeouts, you may have to measure the performance of your backend systems, determine a requirement for a response time from the broker, and just come up with a figure that seems to work. Don't just use timeouts for the sake of using them though. They do incur a performance overhead. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Oct 17, 2002 1:46 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| I disagree - if you don't set a timeout for "unknown" message - you run the risk of one of the aggregate replies arriving before the control message and being considered "unknown". A small value is better than none (in my opinion). |
|
| Back to top |
|
|
| devans |
| Posted: Thu Oct 17, 2002 3:16 am Post subject: |
|
|
Apprentice
Joined: 18 Mar 2002
Posts: 43
|
| The control message arriving after the reply message will not cause the reply message to be considered "unknown". A reply is only an early reply if it arrives before the DB INSERT performed by the AggregateRequest node is commited. This appears to be a commonly held misconception about the control message. |
|
| Back to top |
|
|
| lung |
| Posted: Thu Oct 17, 2002 4:49 pm Post subject: |
|
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
I've tested this and found that request messages arriving before the control message will indeed cause the reply node to identify the request messages as 'unknown'.
Somehow, if I don't put any timeout values for both the control and reply nodes, all my request messages will go to the unknown terminal. I rectified this by setting 5 secs for reply and 10 secs for control.
_________________
lung |
|
| Back to top |
|
|
| devans |
| Posted: Fri Oct 18, 2002 2:01 am Post subject: |
|
|
Apprentice
Joined: 18 Mar 2002
Posts: 43
|
It sounds like your fan-out isn't transactional or you're sending your request messages with your MQOutput node out of syncpoint.
Trust me about the control message. I wrote these nodes. |
|
| Back to top |
|
|
| lung |
| Posted: Sun Oct 20, 2002 5:41 pm Post subject: |
|
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
devans,
You're right. Transaction modes are set to 'no' for all my input and output nodes (default). I still do not fully understand how all these 'within synpoint'-thingy works in WMQI. So if I'm using aggregation nodes, am I suppose to set transaction modes to 'yes' for my input nodes and my output nodes? Or only for certain nodes? If so, which nodes?
Thanks!
_________________
lung |
|
| Back to top |
|
|
| devans |
| Posted: Tue Oct 22, 2002 1:30 am Post subject: |
|
|
Apprentice
Joined: 18 Mar 2002
Posts: 43
|
| Well, you want everything to be in a transaction, and there are a couple of ways to do it. The safest way is to set your input nodes to transaction=yes because he's the guy who's going to begin and commit the transaction. then set your output nodes to transaction=yes. The other options and combinations are useful, but probably not in an aggregation flow. |
|
| Back to top |
|
|
| lung |
| Posted: Tue Oct 22, 2002 1:44 am Post subject: |
|
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
Thanks, devans! I will try it out... 
_________________
lung |
|
| Back to top |
|
|
|
|
