| Author |
Message
|
| nathanw |
 Posted: Mon Mar 14, 2005 7:01 am Post subject: Aggregation just what data is required |
 |
|
Knight
Joined: 14 Jul 2004
Posts: 550
|
OK
I have the situation that a single message input will need several things
I am remapping a large portion of the message and that is fine.
I am propagating a series of repeating fields out to a service which will return individually a response with enhanced data
I am using aggregation to pull all the data together
First question does aggregation take the ID of the original message for all of the 'n' replies
Second question
The re integration of all the data is carried out in another message flow with 2 inputs, the mapped portion and the aggregated responses
Is this correct?
Never having used Aggregate before I am not 100% sure on this. I have read the documentation but some points are vague
Any help appreciated. |
|
| Back to top |
|
 |
| JT |
| Posted: Mon Mar 14, 2005 9:42 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
| Quote: |
| does aggregation take the ID of the original message for all of the 'n' replies |
It appears new message ids are generated for each request sent in the 'fan-out' process using a slight variation of the original message id. At least that's what the following excerpt seems to indicate, and a quick test of my own confirmed.
| Quote: |
| When the initial request is processed by the fan-out flow, the MsgId held in the MQMD is lost. If you want to correlate the aggregated output message to the original input message, one way to do this is to preserve the MsgId and specify it as the CorrelId in the aggregated output message. |
| Quote: |
The re integration of all the data is carried out in another message flow with 2 inputs, the mapped portion and the aggregated responses
Is this correct? |
Not necessarily. The 2 inputs can also be in the same flow that performs the 'fan-out' (thus negating the need for a 2nd flow), and therefore the Control (out) terminal of the AggregateControl node would be hard-wired to the Control (in) terminal of the AggregateReply node.
| Quote: |
The advantages of a single message flow that contains both fan-out and fan-in are:
It is easier to associate the fan-out and fan-in flows, because you connect the two together as described above.
The control information passes directly from the AggregateControl node to the AggregateReply node and does not incur the overhead of being put to and retrieved from another destination such as a WebSphere MQ queue.
The advantages of creating separate fan-out and fan-in flows are:
The two flows can be modified independently of each other.
The two flows can be stopped and started independently of each other.
The two flows can be deployed to separate execution groups to take advantage of multiprocessor systems, or to provide data segregation for security or integrity purposes.
|
|
|
| Back to top |
|
|
| nathanw |
| Posted: Tue Apr 05, 2005 3:02 am Post subject: |
|
|
Knight
Joined: 14 Jul 2004
Posts: 550
|
Many thanks JT
I am at the stage of testing thsi and some errors are occuring
one is teh BIP4405 error ie local environment not valid
I am assuming that the compute nodes i have after the Control node are changing the local environment and therefore, for want of a better word, corrupting the content. I can understand this happening BUT if i move the control node to after the compute node i still get the same error. All that is between the 2 is a trace node and a MQ output node
The situation is as follows
a single message comes in
upper half is reformatted
lower half has multiple items and tehrefore i am propagating a repeat for each item (this is the aggregate that requires a response)
so i pass the entire message thru the control node
the upper half is the control and is pass to the separate (this is probably the better solution at the moment) return/fan in flow
the lower half after control is ran thru esql to propagate the items for responses in its own compute node
this is then put to a mq output node and then the aggregation request node
however the problem is that, i think, that the propagating portion as i say above is changing the environment and therefore not matching the control.
this is an intriging problem i have to say |
|
| Back to top |
|
|
| JT |
| Posted: Tue Apr 05, 2005 7:29 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
| Quote: |
Select a value for the Basic property Compute Mode. This property specifies which sections of the message tree are modified by the node.
The AggregateControl node inserts elements into the LocalEnvironment tree in the input message that the AggregateRequest node reads when the message reaches it. Ensure that the LocalEnvironment is copied from the input message to the output message in the Compute node. This happens automatically unless you specify a value that includes LocalEnvironment (one of All, LocalEnvironment, LocalEnvironment and Message, or Exception and LocalEnvironment).
If you specify one of these values, the broker assumes that you are customizing the Compute node with ESQL that writes to LocalEnvironment, and that you will copy over any elements within that tree that are required in the output message.
If you want to modify LocalEnvironment, add the following statement to copy the required aggregate information from input message to output message:
SET OutputLocalEnvironment.ComIbmAggregateControlNode =
InputLocalEnvironment.ComIbmAggregateControlNode; |
I believe the ESQL statement above is required in the Compute node. |
|
| Back to top |
|
|
| nathanw |
| Posted: Tue Apr 05, 2005 9:07 am Post subject: |
|
|
Knight
Joined: 14 Jul 2004
Posts: 550
|
many thanks again JT suspect that is my problem
havent spotted that piece of code in any help i have read
N |
|
| Back to top |
|
|
| JT |
| Posted: Tue Apr 05, 2005 10:19 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
|
| Back to top |
|
|
| lillo |
| Posted: Tue Apr 05, 2005 10:39 pm Post subject: |
|
|
Master
Joined: 11 Sep 2001
Posts: 224
|
| JT wrote: |
Not necessarily. The 2 inputs can also be in the same flow that performs the 'fan-out' (thus negating the need for a 2nd flow), and therefore the Control (out) terminal of the AggregateControl node would be hard-wired to the Control (in) terminal of the AggregateReply node.
|
I tested recently a new aggregation scenario and found the control message is not propagated to the control terminal. Did you find the same behaviour? I use WBIMB 5.0 CSD2.
Regards,
_________________
Lillo
IBM Certified Specialist - WebSphere MQ |
|
| Back to top |
|
|
| JT |
| Posted: Wed Apr 06, 2005 6:22 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
No, we haven't experienced this behaviour in v5.0.2 or v5.0.4.
What leads you to believe the control message is not being propogated? Try adding a Trace node between the Control terminals of the AggregateControl and AggregateReply nodes, with the trace pattern ${Root}. You could also use a queue as an intermediary to verify the propogation of the control message.
| Code: |
(0x01000010):XML = (
(0x01000000):ComIbmAggregateControlNode = (
(0x03000000):brokerUUID = 'bea1ff8400010000008080c3030b5079'
(0x03000000):aggregateName = 'JT'
(0x03000000):replyGroupId = '84e467e8a6a611d9a683a86d35140000'
(0x03000000):timeout = '1112797130'
) |
|
|
| Back to top |
|
|
| JacobSteenDue |
| Posted: Wed Apr 06, 2005 9:16 pm Post subject: |
|
|
Novice
Joined: 22 Mar 2005
Posts: 13
|
I seem to have the same problem - no control message. I've checked using debugger as well as having trace nodes.
Edit: I forgot - I'm using CSD04
_________________
Jacob Steen Due
Chief Consultant
IBM Certified Solution Designer - WebSphere MQ V5.3
IBM Certified Solution Designer - WebSphere Business Integration Message Broker V5 |
|
| Back to top |
|
|
| lillo |
| Posted: Wed Apr 06, 2005 10:34 pm Post subject: |
|
|
Master
Joined: 11 Sep 2001
Posts: 224
|
| JacobSteenDue wrote: |
I seem to have the same problem - no control message. I've checked using debugger as well as having trace nodes.
Edit: I forgot - I'm using CSD04 |
I also checked with the visual debugger and trace nodes. And checking the queue status I could only see the queue is openned to get messages (fan-in message flow).
_________________
Lillo
IBM Certified Specialist - WebSphere MQ |
|
| Back to top |
|
|
|
|
