| Author |
Message
|
| Spidyctf |
 Posted: Wed May 30, 2007 1:38 pm Post subject: Aggregate Reply node is eating up the Global environment. |
 |
|
Newbie
Joined: 09 Dec 2006
Posts: 8
|
Hi
We are facing a strange problem with Aggregate Reply node.
The Fan In flow has
MQInput Node -> JavaCompute Node -> AggregateReplyNode ->.......
In the Java Compute node we are initializing some variables and storing them in the global environment variables which will be used later in the flow.
The problem is that the Aggregate Reply node is sometimes eating up the Global environment when the control comes after the Aggregate Reply node. So just after the Aggregate Reply node the environment comes empty.
Its behaving very inconsistently. Sometimes the environment comes as it is , but sometimes AggregateReply node is eating up the environment.
Has anyone faced such problem.
Can someone give some imputs on this.
Regards
Spidy |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed May 30, 2007 1:44 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Put the data you need into the reply message, instead of the global environment.
If you think about the problems that aggregation is supposed to solve - for example, assembling results from multiple different flows - then you'll see that global environment is not useful for this.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| au@kosa |
| Posted: Mon Jun 04, 2007 9:56 pm Post subject: |
|
|
Centurion
Joined: 04 Jan 2007
Posts: 103
Location: pune
|
Hi jefflowrey,
I agree with you. Now my question is Aggregate Reply node launches the new thread or it works with in the same thread started for the last message in the MQinput node. I belief in the later one. If that is true, it (AggregateReply node) should not at all drop the global environment variables initialised in JCN (after MQinput node) when processing the last message of the MQinput node (FANIN case).
_________________
Regards,
au@kosa
IBM Certified SOA Solution Designer/Associate |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jun 05, 2007 2:09 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It really depends on how your flow is wired, and if you're using reply timeouts.
It's not guaranteed to happen a specific way.
Please code accordingly.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| au@kosa |
| Posted: Tue Jun 05, 2007 4:11 am Post subject: |
|
|
Centurion
Joined: 04 Jan 2007
Posts: 103
Location: pune
|
Jefflowrey,
I have seen their code and design. They are handling the time out situation. The FAN IN Flow is as below
MQInputNode->JCN ->AggReplynode->ComputeNode
JCN they are using to save certain information and MQMD header in global environment for auditing purpose.
Infact i want to get rid of this design (bit late to propose so) but we are looking for a rational (THe MQMD header appears inside global environment in JCN vanishes when the message successfuly comes out of the "out" terminal of the Aggregate reply node). This behaviour is inconsistent.
Jeff please suggest.
_________________
Regards,
au@kosa
IBM Certified SOA Solution Designer/Associate |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jun 05, 2007 4:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
So every message that appears in the MQInput node will start a new Environment.
Just like every message that appears at any MQInput node creates a new Environment.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| au@kosa |
| Posted: Tue Jun 05, 2007 4:50 am Post subject: |
|
|
Centurion
Joined: 04 Jan 2007
Posts: 103
Location: pune
|
yes, every message will have a new environemt variable. I expects, the last message at input node along with environment variable should complete its journey beyond aggregation reply node, till the end of the FAN IN flow.
_________________
Regards,
au@kosa
IBM Certified SOA Solution Designer/Associate |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jun 05, 2007 5:02 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I understand that that is what you expect.
I've told you that it's not correct to expect that.
I've told you that the PROPER way to do what you want is to put the information you need into the reply message itself, so that it will be available in the Aggregate Reply folder.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| au@kosa |
| Posted: Tue Jun 05, 2007 5:06 am Post subject: |
|
|
Centurion
Joined: 04 Jan 2007
Posts: 103
Location: pune
|
Thanks Jeff for all your support.
_________________
Regards,
au@kosa
IBM Certified SOA Solution Designer/Associate |
|
| Back to top |
|
|
| Paul D |
| Posted: Thu Sep 27, 2007 6:06 am Post subject: |
|
|
Master
Joined: 16 May 2001
Posts: 200
Location: Green Bay Packer Country
|
I just hit this issue also. Here's an approach that I thought others might benefit from. I took my whole environment tree and copied it into my RFH2 user folder area. This is particularly helpful when you are aggragating with non-XML messages. I replace it back immediately after the aggregrate reply node. I was able to do this with two small pieces of reusable code. Sinceyou end up rebuilding the message from the aggregrate folders, most all the time the use of theRFH2 folder is invisible and does not effect existing transformation code. I only other thing to mention is to watch for casting. For example if you placed a CCSID or Encoding value in there, you'd need to cast as a INT when referencing it again, or just recast it when you place in back into the environment tree.
_________________
Thanks!!!
Paul D |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Sep 27, 2007 2:21 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Paul D wrote: |
| I just hit this issue also. Here's an approach that I thought others might benefit from. I took my whole environment tree and copied it into my RFH2 user folder area. This is particularly helpful when you are aggragating with non-XML messages. I replace it back immediately after the aggregrate reply node. I was able to do this with two small pieces of reusable code. Sinceyou end up rebuilding the message from the aggregrate folders, most all the time the use of theRFH2 folder is invisible and does not effect existing transformation code. I only other thing to mention is to watch for casting. For example if you placed a CCSID or Encoding value in there, you'd need to cast as a INT when referencing it again, or just recast it when you place in back into the environment tree. |
Not worth the pain.
Jeff pointed out the right solution:
Send an additional message through aggregation request. That message contains as a payload all the information you wanted in the Environment tree.
You will get the message in any of the aggregations (partial or full) and as such can recreate your environment. The only messages that cannot benefit from this are the ones that have timed out. But they should already go a different route...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Paul D |
| Posted: Fri Sep 28, 2007 4:17 am Post subject: |
|
|
Master
Joined: 16 May 2001
Posts: 200
Location: Green Bay Packer Country
|
It's just another approach, an option for someone in the same situation of not knowing this was a requirement. I was certainly never implying that the other approach is not a viable one. I need more than just what was in the request, that's only about half of it. Given what my flow is trying to do, I think it's the best path.
_________________
Thanks!!!
Paul D |
|
| Back to top |
|
|
|
|
