| Author |
Message
|
| sanu_mit |
 Posted: Fri Aug 29, 2003 3:57 am Post subject: Message validation anomaly |
 |
|
Apprentice
Joined: 03 Jul 2003
Posts: 25
Location: Kolkata
|
I have created a message set in MRM domain with XML physical format layer. My message has been built by importing a DTD for an XML.
One of my requirement is to validate the input message against the DTD. I have created a simple flow consisting of just an input node and output node, one connected to the other. The input node is configured to completely validate the message by appropripately setting the validate tab of input node properties. The catch and failure node of the input node is connected to the input to a subflow which does some formatting to the exception occurred before placing the message in the error queue.
When this flow is run, it behaves normally with a valid XML message. But when an invalid message is passed through the flow, it does not get any exception. Rather, it comes out through the failure terminal of the input node before getting inside the subflow. This message in the subflow does not contain any exception and so the subflow does not work properly. My requirement is to get an exception and process that in the subflow to retrieve the error text from the exception. Here I do not get any error text.
I tried a workarround. I configured the input node without any message validation. A compute node was placed in between the input and output node which was configured to perform the validation and it just copied the input root to output root. In this case, an invalid XML message rightly gets an exception with error text. But, a valid XML message also receives an exception. A valid message never passed out of the compute node.
Can anyone help me out to solve this problem? My requirement is that a Valid XML will pass out of the flow. An invalid XML will get an exception with error text.
Thanks in anticipation.
Sanu_Mit. |
|
| Back to top |
|
 |
| Craig B |
| Posted: Fri Aug 29, 2003 7:02 am Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
Hi,
In your first scenario with the MQInput node wired to an MQoutput node then you said you set the validation to be complete. What this means is to validate the complete message tree when the message is first parsed. When you have an MQInput node wired to an MQOutput node then the message will never be parsed and so validation will never be driven. If you specify IMMEDIATE as your Validation timing, then this would cause a full parse to be driven on the MQInput node, and this will cause full validation.
Without knowing the BIP error message that was generated when your valid XML message was rejected in your compute node it is hard to say why it might have happened. However, I do know there is a defect in Compute node validation which gives a BIP5374 error even when the message is valid. It is possible that you encountered this error which rejected your valid message.
_________________
Regards
Craig |
|
| Back to top |
|
|
| sanu_mit |
| Posted: Fri Aug 29, 2003 7:25 am Post subject: |
|
|
Apprentice
Joined: 03 Jul 2003
Posts: 25
Location: Kolkata
|
Thanks Criag for your valuable suggestion.
Yeah, I am getting the error that you have mentioned when using the compute node. Well, as you say that it is a defect/bug of the compute node, then I have no way out by this method.
Also Criag, then input node configuration that you have spoken about for the other case, has already been taken care of. I have configured the input node for validation for content and value and also the other option is set to immediate. In this scenerio, I find that the message propagates through the failure terminal (through debug) and consequently, I do not get any error text for the failure. Can you help me here?
Thanks once again. |
|
| Back to top |
|
|
| Craig B |
| Posted: Fri Aug 29, 2003 8:30 am Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
Hi,
For the compute node validation, a fix was made available for this problem in WMQI V2.1 CSD05. If you cannot move to CSD05 on your broker installation then you should contact your IBM support team and ask for a fix on the CSD level that you are running at.
For your MQInput node validation problem then an error is being thrown in the MQInput node. This gives rise to several possible situations. If your catch terminal is wired then the message and ExceptionList will be propagated to the catch terminal. If the catch terminal is not wired, then the transaction will be rolled back at the message will be returned to the input queue. At this point the MQMD.Backout is incremented by the queue manager for this message, and the current flow instance finishes. At this point any exception List information and flow variables are lost. The flow then goes to pick the next message up from the input queue, which just happens to be the one it backed out. At this point it is likely that the MQMD.BackoutCount exceeds the backout threshold of the Input queue. At this point the message will be propagated to the failure terminal if it is wired, and in your case it is. The error you get now is for a completely different flow instance than the validation error and is for the backout count being exceeded.
So if you want to process your validation error you should wire the catch terminal of the MQInput node. You would then examine the exceptionList for whatever you want to look for, or report this ExceptionList to your appropriate logging mechanism for your flow. If you then wish to rollback the transaction, then you can use a throw node, or ESQL THROW statement to cause the processing to flow back to the input node.
Hope this helps.
_________________
Regards
Craig |
|
| Back to top |
|
|
| sanu_mit |
| Posted: Tue Sep 02, 2003 8:05 pm Post subject: |
|
|
Apprentice
Joined: 03 Jul 2003
Posts: 25
Location: Kolkata
|
Sorry Criag, for the delay to respond. I was out of station for the last few days and was unable to access the internet.
Thanks Criag, for the suggestion to update to CSD05. But for the moment I am unable to do that and consequently, I shall have to run with CSD04.
But about the wiring the catch terminal of input node that you spoke about, I just need to inform you that in that flow the aforesaid terminal along with the failure terminal are both wired to the input terminal of a subflow which processes the exception list tree. Through debug, I discovered that when an invalid XML message is put in to the input node it passes out through the failure terminal and not through the catch terminal as expected although both the terminals are wired here.
Could you please throw some light for this beheaviour?
Thanks in advance Criag, b'coz I'm sure that you have an answer as you always have that. |
|
| Back to top |
|
|
| mpuetz |
| Posted: Wed Sep 03, 2003 12:59 pm Post subject: |
|
|
Centurion
Joined: 05 Jul 2001
Posts: 149
Location: IBM/Central WebSphere Services
|
Hi,
unfortunately that is the behavior of all input nodes:
If an exception (like a parser validation exception) happens
in the input node the exception is *not* propagated down
the catch terminal but right to the failure node.
There are couple of other cases other than validation
where this happens (e.g. if MQ gives a warning, like
a converion failure).
Thus immediate validation is - in my opinition - not a good
idea, since you won't get any feedback in the message flow
about the cause.
_________________
Mathias Puetz
IBM/Central WebSphere Services
WebSphere Business Integration Specialist |
|
| Back to top |
|
|
| Craig B |
| Posted: Wed Sep 03, 2003 1:49 pm Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
Hi,
If the message validation exception is not being propagated to the Catch terminal then this should be seen as a defect. The user should be given the opportunity to evaluate the error to see if they can handle the error themselves. In this message validation scenario, if the catch terminal is wired then the validation exception should be propagated to the Catch terminal. If not wired, then it will take the normal error processing path of rolling back the transaction and then rely on retry processing to try again or if the BackoutThreshold threshold is exceeded it is propagated to the Failure terminal.
If the user does not get chance to handle and examine the validation errors, then as the previous update mentions, it makes no sense having validation options on the input node that allow Immediate validation.
Can you raise a problem problem with IBM support for that issue. If you dont want to do it, I'll try take care of it.
_________________
Regards
Craig |
|
| Back to top |
|
|
| mpuetz |
| Posted: Thu Sep 04, 2003 1:23 am Post subject: |
|
|
Centurion
Joined: 05 Jul 2001
Posts: 149
Location: IBM/Central WebSphere Services
|
Hi Craig,
please, feel free to raise a pmr, cause right now I don't have the time.
I am not sure, if you can convince the lab to change this behavior
since it would envolve some re-design of the input node.
Such a re-design might break other customer code in other situations.
I believe the observed behavior is also ducomented, hence they
might try to get away with an answer like : Works as designed.
Thus a PMR might not be the right way to get them to re-think.
A change/feature request might be more appropriate.
_________________
Mathias Puetz
IBM/Central WebSphere Services
WebSphere Business Integration Specialist |
|
| Back to top |
|
|
| sanu_mit |
| Posted: Thu Sep 04, 2003 1:52 am Post subject: |
|
|
Apprentice
Joined: 03 Jul 2003
Posts: 25
Location: Kolkata
|
Thanks to both Mathius and Craig. It is a bit disheartening to learn from Mathius that input node passes out through failure terminal when a message is dropped for validation.
Craig, I would surely like to inform this discrepancy to IBM. Buttruely speaking, I'm a novice in the arena of MQSI and so not at all aware of the norms of reporting. If you please inform me as to how and whereabout to write/contact to it would be very much helpful to me.
Also, I would never mind (rather be happy) if you correspond with IBM regarding this matter. But then, I would just request you to keep me in the loop of your correspondence. I hope you don't mind that. My mail id is smart_santanu@yahoo.com.
Thank you once again for all your efforts. |
|
| Back to top |
|
|
| Craig B |
| Posted: Thu Sep 04, 2003 4:08 am Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
Hi,
No problem ..... its has already been done. I'll make sure it gets looked into.
_________________
Regards
Craig |
|
| Back to top |
|
|
| Craig B |
| Posted: Tue Sep 09, 2003 12:34 pm Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
Hi,
Just to let you know that APAR IC37326 has been raised to address this issue in a future CSD. If you require a fix for this behaviour before then, then contact your IBM support centre who should be able to provide you with one.
_________________
Regards
Craig |
|
| Back to top |
|
|
|
|
