| Author |
Message
|
| Omuch |
 Posted: Wed Jan 14, 2015 2:25 am Post subject: Try Catch node issue |
 |
|
Acolyte
Joined: 23 Mar 2012
Posts: 54
|
Hi
I'm using WMB 7.0.0.5
I have a main flow that includes subflow.
Inside the subflow i have :
Input -> Try Catch node -> other nodes connected to the Try terminal,
nothing is connected to the catch terminal.
When an exception occurs downstream of the Try terminal , I assumed that the exception won't go upstream to the main flow because of the Try Catch node , but that's exactly what happened.
I also tried to connect a trace node to the Catch termianl of the Try Catch node. the The result was the same.
Any Suggestions? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Jan 14, 2015 5:46 am Post subject: Re: Try Catch node issue |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Omuch wrote: |
I have a main flow that includes subflow.
Inside the subflow i have :
Input -> Try Catch node -> other nodes connected to the Try terminal,
nothing is connected to the catch terminal. |
So if the subflow abends, you just ignore it?
| Omuch wrote: |
| When an exception occurs downstream of the Try terminal , I assumed that the exception won't go upstream to the main flow because of the Try Catch node , but that's exactly what happened. |
So your design expectation is that data comes into the main flow, goes into the subflow and if it abends, quietly disappears with no mess, no fuss and no indication that the data was ever sent? Odd.
| Omuch wrote: |
| Any Suggestions? |
Well you can't seriously have designed a flow that swallows failing data without a word, so there's clearly something more at work here.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Jan 14, 2015 6:52 am Post subject: Re: Try Catch node issue |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Omuch wrote: |
Inside the subflow i have :
Input -> Try Catch node -> other nodes connected to the Try terminal,
nothing is connected to the catch terminal.
|
Would you care to explain why you are not connecting anything to the Catch terminal of the try-catch node?
Why is the object of putting the Try-catch node there?
Most of those who post here use properly designed exception handing.
In many cases we just connect it up to the catch terminal of the Flow Input node and we are done.
There are a few instances where I have used a Try-Catch node after Flow Input Nodes but this is very much the exception to the rule than anything else.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Omuch |
| Posted: Wed Jan 14, 2015 8:14 am Post subject: Re: Try Catch node issue |
|
|
Acolyte
Joined: 23 Mar 2012
Posts: 54
|
I will explain.
In my main flow I do some things like http request , insert the response to DB and more stuff.
When an exception occurs on the main flow ,I have an exception handler that connected to to catch terminal of the MQinput of the main flow that handles all exceptions.
In some parts of the main flow, I have the subflow that puts a copy of the message (with flow order) to another Flow that writes the copy to file.
The requirement is that any exception that occurs in the subflow won't effect the main flow becasue the copy is not "must to have" requirement. and it can't effect the main process of the flow.
So more precisely, the subflow look like this:
Input->Flow order->(first)->Try catch->(Try)->MqOutput
(second)-> Output
Is it clear now? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 14, 2015 8:27 am Post subject: Re: Try Catch node issue |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Omuch wrote: |
| In some parts of the main flow, I have the subflow that puts a copy of the message (with flow order) to another Flow that writes the copy to file. |
Bingo.
If there's an exception in the flow attached to the First terminal of a FlowOrder node, the flow attached to the Second terminal will still execute.
| Omuch wrote: |
| Is it clear now? |
No. I still don't see why you'd design a system that takes a copy of a message unless it doesn't. What's the point? If (for example) you're taking a copy of the message for audit or to diagnose problems with downstream (non broker) processes, what do you do if you need to audit or diagnose a message that's not been copied?
Not directly relevant to the code behaviour you're seeing, and if you think this is a cool design go in peace with it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Omuch |
| Posted: Wed Jan 14, 2015 8:52 am Post subject: Re: Try Catch node issue |
|
|
Acolyte
Joined: 23 Mar 2012
Posts: 54
|
| Vitor wrote: |
Bingo.
If there's an exception in the flow attached to the First terminal of a FlowOrder node, the flow attached to the Second terminal will still execute.
|
So what you're saying basically is that I do not have to use the Try Catch node if i use Flow Order node?
Can't be.
| Info center wrote: |
"If the first phase of processing fails, the FlowOrder node does not regain control and does not propagate the message through the Second terminal."
|
Precisely for this reason i used the Try Catch node, but like I said the exception goes upstream to the main flow for some reason...
| Vitor wrote: |
No. I still don't see why you'd design a system that takes a copy of a message unless it doesn't. What's the point? If (for example) you're taking a copy of the message for audit or to diagnose problems with downstream (non broker) processes, what do you do if you need to audit or diagnose a message that's not been copied?
Not directly relevant to the code behaviour you're seeing, and if you think this is a cool design go in peace with it. |
The Flow replaces an old process that existed in the organization.
The requirement was that the behavior will be the same as the old process from all kinds of considerations(not only technical).
Forget it, it's not the issue |
|
| Back to top |
|
|
| mgk |
| Posted: Wed Jan 14, 2015 10:39 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
| Quote: |
| If there's an exception in the flow attached to the First terminal of a FlowOrder node, the flow attached to the Second terminal will still execute. |
Err, no. From the Knowledge center: http://www-01.ibm.com/support/knowledgecenter/SSMKHH_9.0.0/com.ibm.etools.mft.doc/ac04790_.htm
| Quote: |
| If the first phase of processing fails, the FlowOrder node does not regain control and does not propagate the message through the Second terminal |
But on the original topic, I can confirm that the correct behaviour should be that a recoverable exception thrown downstream of the "try" terminal on the TryCatch node should always be propagated to the "catch" terminal on the TryCatch node, even if it is not wired. This would mean that the exception would in effect be "black-holed" if the "catch" terminal was not wired, just like PROPAGATEing to a terminal that was not wired does in ESQL (or just not connecting the output terminal of any other node for that matter).
So if you are not seeing this behaviour then there is something strange about the exception or you have a defect in which case you should raise a PMR.
Kind regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| Omuch |
| Posted: Wed Jan 14, 2015 1:28 pm Post subject: |
|
|
Acolyte
Joined: 23 Mar 2012
Posts: 54
|
| mgk wrote: |
But on the original topic, I can confirm that the correct behaviour should be that a recoverable exception thrown downstream of the "try" terminal on the TryCatch node should always be propagated to the "catch" terminal on the TryCatch node, even if it is not wired. This would mean that the exception would in effect be "black-holed" if the "catch" terminal was not wired, just like PROPAGATEing to a terminal that was not wired does in ESQL (or just not connecting the output terminal of any other node for that matter).
So if you are not seeing this behaviour then there is something strange about the exception or you have a defect in which case you should raise a PMR.
Kind regards, |
This is exactly what I expected too,and we were both right, I just found out the problem. An exception occurred after the subflow in the main flow
apparently I missed it during the debug at the first times.
So in the end it all goes well, sorry that i bothered you.
thanks anyway |
|
| Back to top |
|
|
| usamagdy |
| Posted: Tue Jan 20, 2015 1:07 am Post subject: |
|
|
Newbie
Joined: 30 Mar 2013
Posts: 8
|
please use the following to ignore any exception
CREATE COMPUTE MODULE xxxxx_Subflow_CopyMessage
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
-- CALL CopyMessageHeaders();
CALL CopyEntireMessage();
BEGIN
DECLARE CONTINUE HANDLER FOR SQLSTATE LIKE'%' BEGIN END;
PROPAGATE To TERMINAL 'out' Delete none;
END;
PROPAGATE To TERMINAL 'out1' Delete none;
RETURN FALSE;
END; |
|
| Back to top |
|
|
|
|
