| Author |
Message
|
| broker_new |
 Posted: Tue Apr 02, 2013 6:30 am Post subject: WMBv8=> validation using message model |
 |
|
Yatiri
Joined: 30 Nov 2006
Posts: 614
Location: Washington DC
|
Hi Guys,
We are enforcing strict validation rules for the inbound messages(schema validations) using SOAP Input node.
When we opted for the option Parset Options>>Parse timing>> Complete it doesn't valdiate the complete SOAP request message.
it just throws the exception if there is a validation failure in a particular field and doesn't validate the remaining part of the XML which is little annoying as we have 150 fields in the request message. is there an option that can validate the complete request message and throw a summary of exception (validation failures) in message broker v8.0 (fixpack1 or 2)? 
_________________
IBM ->Let's build a smarter planet |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Tue Apr 02, 2013 6:51 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
The first field/value that does not match the XSD brings the show to a stop. You will not get a list of all the problems with your payload, just the first one that fails.
If you want to see your errors comprehensively, use a comprehensive testing tool like SoapUI.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| broker_new |
| Posted: Tue Apr 02, 2013 6:55 am Post subject: |
|
|
Yatiri
Joined: 30 Nov 2006
Posts: 614
Location: Washington DC
|
yes, just the field which has the problem with, why not the complete summary of the problems...
Think about the level of effort for testing, why not make it more powerful to validate the complete message, should we raise a RFE or just implement the validation rules in ESQL/ Java (input node parser options as "On Demand") ? 
_________________
IBM ->Let's build a smarter planet |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Apr 02, 2013 7:14 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
You may like to use a testing tool to actually test your payloads; WMB is a runtime engine, not a testing tool.
WMB is doing exactly what you are telling it to do.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Apr 02, 2013 7:26 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| You may like to use a testing tool to actually test your payloads; WMB is a runtime engine, not a testing tool. |
I would hope the OP is looking for a complete list of all the problems with any Production XML for return to the sender, rather than any kind of testing issue. I theorise that the SOAP Input node in question faces either a 3rd part or a separate business unit.
If they really just want to throw XML at the flow in test to see which bits slide down the wall, then I agree with you; there are any number of other tools that will do this.
It's also straightforward enough to pass anyone using your SOAPInput node the associated WSDL, say "it has to look like this" and explain that if it doesn't match that it will fail.
| lancelotlinc wrote: |
| WMB is doing exactly what you are telling it to do. |
Functioning as designed. WMB will not waste time parsing an XML document it's already decided can't match the schema to see what else is wrong.
| broker_new wrote: |
| Think about the level of effort for testing, why not make it more powerful to validate the complete message, should we raise a RFE or just implement the validation rules in ESQL/ Java (input node parser options as "On Demand") |
If you really, really want to use WMB for testing then you need to code all the rules in ESQL / Java. This exercise will inform you why people make tools to test & validate XML. This will certainly be faster than an RFE and even in the Production scenario I outline above, currently most of us are happy to bounce XML on the first error and advise the sender to check they're using the right WSDL. It would be cool if you could report all the errors, but I live daily with not being cool & it assumes that the XML parser can continue after the first error.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| goffinf |
| Posted: Tue Apr 02, 2013 12:58 pm Post subject: Re: WMBv8=> validation using message model |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| broker_new wrote: |
Hi Guys,
We are enforcing strict validation rules for the inbound messages(schema validations) using SOAP Input node.
When we opted for the option Parset Options>>Parse timing>> Complete it doesn't valdiate the complete SOAP request message.
it just throws the exception if there is a validation failure in a particular field and doesn't validate the remaining part of the XML which is little annoying as we have 150 fields in the request message. is there an option that can validate the complete request message and throw a summary of exception (validation failures) in message broker v8.0 (fixpack1 or 2)? |
You are looking for 'exhaustive validation'. AFAIK you won't get that from the way the validating parser is configured for you with Broker and I don't know any way of changing that. Obviously you can do it yourself in a JCN (i.e. switch off validation on the SOAPInput and do it immediately after), and if it fails construct a more useful SOAP Fault back to you caller that includes all of the errors found. Or you could follow a selective validation approach and just validate the parts of the message that you care about. You can do that in ESQL, .. You can even make it part of other transformation logic if you want.
XSD validation is a pretty blunt tool at the best of times. It's much improved in 1.1 but unfortunately Broker doesn't support that. You could do most of what you need in XSLT too, but that's a comment for another day.
Fraser. |
|
| Back to top |
|
|
| goffinf |
| Posted: Tue Apr 02, 2013 2:45 pm Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| Vitor wrote: |
| lancelotlinc wrote: |
| You may like to use a testing tool to actually test your payloads; WMB is a runtime engine, not a testing tool. |
I would hope the OP is looking for a complete list of all the problems with any Production XML for return to the sender, rather than any kind of testing issue. I theorise that the SOAP Input node in question faces either a 3rd part or a separate business unit.
If they really just want to throw XML at the flow in test to see which bits slide down the wall, then I agree with you; there are any number of other tools that will do this.
It's also straightforward enough to pass anyone using your SOAPInput node the associated WSDL, say "it has to look like this" and explain that if it doesn't match that it will fail.
| lancelotlinc wrote: |
| WMB is doing exactly what you are telling it to do. |
Functioning as designed. WMB will not waste time parsing an XML document it's already decided can't match the schema to see what else is wrong.
| broker_new wrote: |
| Think about the level of effort for testing, why not make it more powerful to validate the complete message, should we raise a RFE or just implement the validation rules in ESQL/ Java (input node parser options as "On Demand") |
If you really, really want to use WMB for testing then you need to code all the rules in ESQL / Java. This exercise will inform you why people make tools to test & validate XML. This will certainly be faster than an RFE and even in the Production scenario I outline above, currently most of us are happy to bounce XML on the first error and advise the sender to check they're using the right WSDL. It would be cool if you could report all the errors, but I live daily with not being cool & it assumes that the XML parser can continue after the first error. |
Actually Victor you can easily accomplish exhaustive validation in a few lines of Java and leverage the XSD as the constraint model. Would I do that ? Well I have on a few projects but I'm no great fan of XML schema as I have commented many times on this forum. That's not to say that others might find significant utility there. |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Apr 03, 2013 10:05 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
The OP's question is a reasonable one. The short answer is 'working as designed' but the obvious next question is 'why design it like that?'.
This is one of those annoying technical questions where the problem looks simple but is not. There are certainly some xsds for which the validator could easily issue a complete list of problems AND the reported error list would be the only sensible list of errors. There are other xsds ( ones which use the advanced features of the xsd language ) which could allow for a number of different error lists, depending on the assumptions built into the validator's error recovery mechanisms.
I'm not claiming that the problem is technically impossible - a very clever validator could identify the simple cases and report an error list - but it is sufficiently difficult to make a general solution very expensive. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Apr 03, 2013 11:07 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| kimbert wrote: |
| I'm not claiming that the problem is technically impossible - a very clever validator could identify the simple cases and report an error list - but it is sufficiently difficult to make a general solution very expensive. |
And the general solution would likely produce the wrong error list for any given customer's expectations. |
|
| Back to top |
|
|
|
|
