| Author |
Message
|
| nize |
 Posted: Mon Nov 15, 2010 6:13 am Post subject: SOAPInput node failure terminal |
 |
|
Voyager
Joined: 02 Sep 2009
Posts: 90
|
Hi,
Background
I have a WMB flow with the following setup:
SOAPInput -> ErrorHandlingSubFlow -> DoWork -> SOAPReply
All three terminals (output, catch and failure) of the SOAPInput node are connected to the ErrorHandlingSubFlow (In, Catch and Failure respectively). These are the connections between the "SOAPInput" node and the "ErrorHandlingSubFlow" node:
output -> In
catch -> Catch
failure -> Failure
The idea is that the ErrorHandlingSubFlow should catch the exception and log it and thereafter throw a new exception causing the SOAPInput node to put the message to the Failure terminal. On the failure terminal the subflow puts the message to a specific dead-letter-queue and constructs a customized SOAPFault message which it returns to the user.
Problem
When I throw an exception in DoWork the exception is caught in to the catch terminal of the ErrorHandlingSubFlow and rethrown again. So far, so well. However, the SOAPInput node returns a response to the requester instead of putting it to the failure terminal! Why?!
More details
The SOAPInput node is configured to route inbound processing failures to failure terminal:
sendProcessingFaultsToFailure="true"
Extract from user trace:
UserTrace BIP3724I: Node 'SCFL255_PartServiceFlow.SOAP Input' sending a SOAP fault message to the originating client. |
|
| Back to top |
|
 |
| mgk |
| Posted: Mon Nov 15, 2010 6:25 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
| Quote: |
| However, the SOAPInput node returns a response to the requester instead of putting it to the failure terminal! Why?! |
Because the SOAPInput node behaves like most other broker nodes and only sends messages to the failure terminal if the exception happened insidethe node. Once the message has left the node, down the Out terminal, the Failure terminal is not used.
Setting sendProcessingFaultsToFailure="true" means that inbound message processing exceptions that would normally be turned into SOAPFaults immediately (such as a message not matching an operation etc) will instead be sent to the Failure terminal rather than never making the flow at all (because the default behaviour is to send the fault back immediately).
I hope this helps...
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 |
|
|
| nize |
| Posted: Mon Nov 15, 2010 6:38 am Post subject: |
|
|
Voyager
Joined: 02 Sep 2009
Posts: 90
|
Thanks for the quick response!
Isn't it correct that the SOAPInput node should put the message to the failure output in case an exception is raised on the catch path? I believe the MQInput node behaves like that. Am I wrong?
Sorry if I didn't get the point  . |
|
| Back to top |
|
|
| mgk |
| Posted: Mon Nov 15, 2010 6:45 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
| Quote: |
| Isn't it correct that the SOAPInput node should put the message to the failure output in case an exception is raised on the catch path |
Nope
_________________
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 |
|
|
| Vitor |
| Posted: Mon Nov 15, 2010 7:02 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| nize wrote: |
I believe the MQInput node behaves like that. Am I wrong?
|
I think you are. I don't think the MQInput node does that.
I defer entirely to mgk in this, as he has the inside track. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| nize |
| Posted: Mon Nov 15, 2010 7:27 am Post subject: |
|
|
Voyager
Joined: 02 Sep 2009
Posts: 90
|
| Quote: |
I don't think the MQInput node does that.
|
hmm... ok, but if the backout threshold is reached in an MQInput node then the message is put to the failure terminal. Am I wrong?
I mean when an exception is raised on the catch path of the MQInput node this leads, after a number of backouts, to the message being put to the failure terminal of the MQInput node. This would make the behavior different from the SOAPInput node, which never uses the failure terminal due to exceptions raised in the catch path. Am I missing anything? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Nov 15, 2010 7:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| nize wrote: |
| hmm... ok, but if the backout threshold is reached in an MQInput node then the message is put to the failure terminal. Am I wrong? |
Yes. If the backout threshold is reached the MQInput node puts the message to the backout queue.
| nize wrote: |
| Am I missing anything? |
How the nodes work?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| nize |
| Posted: Mon Nov 15, 2010 7:52 am Post subject: |
|
|
Voyager
Joined: 02 Sep 2009
Posts: 90
|
| Quote: |
Yes. If the backout threshold is reached the MQInput node puts the message to the backout queue.
|
Yes, it puts it to the backout queue, but ONLY in case the failure terminal is not connected. Right?
Citation from http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/topic/com.ibm.etools.mft.doc/ac00414_.htm
| Quote: |
If the backout threshold has been reached:
* If you have connected the Failure terminal, node propagates the message to that terminal. You must handle the error on the flow connected to the Failure terminal.
* If you have not connected the Failure terminal, the node attempts to put the message on an available queue, in order of preference:
|
This would in practice mean that the MQInput and SOAPInput have slightly different behaviors. Exceptions in the catch path of the input node ends up in the failure path (after some retries) when it comes to the MQInput node, but NOT when it comes to the SOAPInput node.
Please correct me  |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Nov 15, 2010 8:00 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| nize wrote: |
| Please correct me |
From the same link you posted:
| Quote: |
If the MQInput node has successfully propagated the message to the out terminal and an exception is thrown in the out flow, the message is returned to the MQInput node:
If you have not connected the Catch terminal, the message is rolled back to the input queue. The MQInput node writes the error to the local error log and invokes the retry logic, described in Retry processing.
If you have connected the Catch terminal, you are responsible for handling the error in the flow connected to the Catch terminal. The broker creates a new exception list to represent the error and this list is propagated to the Catch terminal as part of the message tree, but neither the MQInput node nor the broker provide any further failure processing. |
As I understand it, you have the Catch terminal connected, so retry processing (where your quote comes from) does not come into play.
Please correct me if I've misunderstood your situation.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mgk |
| Posted: Tue Nov 16, 2010 2:32 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
This really comes down when things happen and the sequence of events. The simplified sequence is first to note that the backout threshold is only checked when a message is read from the queue. So if an exception happens downstream of the Out terminal of the MQInput node, it will rollback if the Catch terminal is not connected. If the Catch terminal is connected the message is sent there. If there is a second exception down the Catch terminal then again it will cause the message to be rolled back. So the rolled back message is read in again as if it were a new message and the backout count is checked against the threshold. If it is reached it can then send it to the failure terminal. But the key is that this is processing of a message within the node that it has just received from the Queue. It has not yet been sent to any terminals on this iteration. So, as I said before, it "only sends messages to the failure terminal if the exception happened inside the node". In the SOAPInput node case, it does not back out HTTP messages so there is no sending to the failure terminal once the message has left the Out terminal.
I hope this helps explain this a little better...
_________________
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 |
|
|
| mqjeff |
| Posted: Tue Nov 16, 2010 2:49 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Just to remind everyone as well, the HTTP Protocol does not support rollback or backout processing. |
|
| Back to top |
|
|
| nize |
| Posted: Tue Nov 16, 2010 4:15 am Post subject: |
|
|
Voyager
Joined: 02 Sep 2009
Posts: 90
|
| Quote: |
| I hope this helps explain this a little better... |
mqk: Yes, it does. Thanks! The event "backout count reached!" is considered an exception/failure that happens INSIDE the node and is in one way unrelated to any exception raised in the MQInput node Catch path.
Now I believe I understand the behavior (and it is consistent with my experience), so then the next step is to adapt the ErrorHandingSubFlow to NOT expect a message on the SOAPInput node Failure terminal in cases where an exception is has occurred on the SOAPInput node Catch terminal path.
mqjeff: good point. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Nov 16, 2010 5:30 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
If you are going to be doing things that might involve the catch & failure terminals of SOAP Nodes you might like to look at APAR IC70662.
This stops you getting messages like 'SOAP Reply ID has already been used'. This is scheduled for inclusion in the next V7 Fixpack.
It make the handling more in-line with what happens in an MQInput Node.
_________________
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 |
|
|
| nize |
| Posted: Tue Nov 16, 2010 7:08 am Post subject: |
|
|
Voyager
Joined: 02 Sep 2009
Posts: 90
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Nov 16, 2010 7:30 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You can open a PMR and request a specific build of any APAR that is published. You can request this build be made against a specific version and fixlevel of Broker and a specific set of already applied APARs.
Your fix is targeted for inclusion in 6.1.0.9, so there's little reason to doubt it will be there. Even if it is not, you can request a build of the APAR against 6.1.0.9... |
|
| Back to top |
|
|
|
|
And there is a risk that the 6.1.0.9 will not be released until the Q1 2011. By the way I am depending on the fix WMB 6.1.0.5-WS-MB-AIXPPC64-TFIC70029 which I don't know whether it will be included in 6.1.0.9 or not.