|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
PROPOGATE Function Behaviour |
« View previous topic :: View next topic » |
Author |
Message
|
wmqiguy |
Posted: Wed Oct 23, 2002 4:10 am Post subject: |
|
|
 Centurion
Joined: 09 Oct 2002 Posts: 145 Location: Florida
|
This topic is getting so large, I think it should be a forum.
Ahaaaa. Now I see your point. And the pesky BITSTREAM only works on input.
My only suggestion would be to put the transformed message into a database and then refer to it each time as you move through the loop. The dilemna is whether the database hit is more/less expensive than performing the transformations each time. The answer to that is probably the classic "it depends".
Would be nice if the nice folks at IBM were to add another tree in the Local enviroment that could be manipulated and not propagated. Perhaps, NoPropLocalEnvironment?
Let us know if you find any other creative solutions. |
|
Back to top |
|
 |
kirani |
Posted: Wed Oct 23, 2002 8:56 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001 Posts: 3779 Location: Torrance, CA, USA
|
Lung,
I think the contents of Environment tree should remain there even after PROPAGATE command. Looking at your sample code I think you should do your transformation for each account in a while loop.
Code: |
DECLARE I INT;
SET I = 1;
WHILE ( I <= CARDINALITY(InputBody.Msg.AccNo[])) DO
SET OutputRoot.Properties = InputRoot.Properties;
SET OutputRoot.MQMD = InputRoot.MQMD;
-- Build your output tree for AccNo[I]
PROPAGATE;
SET I = I + 1;
|
_________________ 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 |
|
 |
JimmyCheung |
Posted: Thu Oct 24, 2002 9:23 am Post subject: |
|
|
Newbie
Joined: 24 Oct 2002 Posts: 1
|
Hi Alison,
I'm not sure if you already have the answer to your original append, in case you haven't I think here is your answer:
The important information you gave was this line:
* Exception is thrown and caught at input node and is handled correctly
Because your logic "caught" the error, the system does not think there is an error, and therefore commits all your updates when the catch path completes successfully. This is why any messages up to the point the exception occurred will remain on the output queue.
If you didn't handle the error, all of the messages will have been removed from the output queue, and your original input message rolled back onto the input queue, which is what you want.
In order to achieve your goal, you may want to consider connecting a THROW node at the end of your catch processing, in order to backout the entire message flow.
Hope that helps. _________________ Jimmy Cheung
Consultant
MQFocus Limited |
|
Back to top |
|
 |
kirani |
Posted: Thu Oct 24, 2002 10:37 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001 Posts: 3779 Location: Torrance, CA, USA
|
cool! Thanks for the clarification jimmy! _________________ 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 |
|
 |
lung |
Posted: Thu Oct 24, 2002 10:08 pm Post subject: |
|
|
 Master
Joined: 27 Aug 2002 Posts: 291 Location: Malaysia
|
Kiran,
A whole lot of ESQL statements are involved to build my output tree for each account. Which is why I prefer not to copy and paste it into the loop... Anyway, if there's no other alternative, I guess I'll just have to do that for now.
Thanks, guys!
 _________________ lung |
|
Back to top |
|
 |
|
|
|
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
|
|
|
|