Submit and vote on feature ideas.

Welcome to the new Parasoft forums! We hope you will enjoy the site and try out some of the new features, like sharing an idea you may have for one of our products or following a category.

Response -> XML Validator errors...what to do?

LegacyForum Posts: 1,664 ✭✭
edited December 2016 in SOAtest
Good Day,

I am working on a test that regularly fails a chained step "Response SOAP Envelope -> XML Validator". Here are the details of the step:
simple add method with a large record
chained output to Response SOAP Envelope -> Added Or Validated Correctly
chained output to Response SOAP Envelope -> XML Validator
chained output to Traffic Object -> Traffic Viewer

The header for this test uses WS-Security, which works correctly for all other steps.

The problem lies in the XML Validator. The traffic viewer makes it look like the step has finished correctly. Request and response appear normal. But the Test Results tab shows an error which reads:

Row Child Uniqueness (row 1) - cvc-complex-type.2.4.a: Invalid content was found starting with element 'ServiceMetaData'. One of '{WC[##other:""]}'; is expected.

What is the XML Validator trying to do? "Validate against schema" is selected. I believe it is trying to validate the response against the known schema which appears in the WSDL. Boxes also checked: Use namespace as location URI for Schema, and Validate against schemas refererenced ijn WSDL or Schema (which also has the wsdl listed).

If so, why would this cause a fail?

Also, what does the SOAtest error message "One of '{WC[##other:""]}'; is expected. " mean? All of the schemas are intact in their correct directory.

Sorry for the ambiguity on this one. It's been difficult to run it down this far!

Have a great day!


  • LegacyForum
    LegacyForum Posts: 1,664 ✭✭
    edited October 2008

    We have a few people working on this here and I just found out that this is very due to our custom response. The wsdl file service genreated does not include the header information. As the SOAP headers are now part of our response, it doesn't match the current WSDL. This causes the XML validator to fail.

    Problem solved...sortof

    Happy Hall ween all!
  • LegacyForum
    LegacyForum Posts: 1,664 ✭✭
    Our local problem here (custom response SOAP headers) and the grande scheme of things (SOATEST!) are not mixing well.

    What I need to do now is to strip off the header in the response message and process the information in the Body only. But I still want to use the XML validator. I can certainly use the XML Data Bank to strip off the Header, but the XML Data Bank does not allow output to be added to it so I can send the Body contents to the XML Validator.

    How can I process either the Body on the XML Data Bank or the response without the Header and send it to the XML Validator? Gah! So very close...

    Thank you!
  • LegacyForum
    LegacyForum Posts: 1,664 ✭✭
    Evening Brian,

    The simplest way of doing this is to use String manipulation on the SOAP response. To break it into steps:
    1. Pass the entire response to a Method Tool
    2. Find the index of "<SOAP-ENV:Header>" and the index of "<SOAP-ENV:Body>"
    3. Using String.substring(), remove the SOAP Header
    4. Return the value of the modified String to an XML Transformer
    5. Use the XML Transformer to ensure that the XML is correct, and then chain the XML Validator to the output

    I have created an example .tst file to demonstrate this setup.

  • LegacyForum
    LegacyForum Posts: 1,664 ✭✭
    As always, thanks for your help, Joseph. The method does exactly what I need. ( I honestly can't see another way to do this without that method tool!)

    I'm interested to know how I can use the XML Transformer without actually selecting anything to transform. It apparently "transforms" something because the XML Validator doesn't work without it!

    At any rate, this works great. Thanks!

  • LegacyForum
    LegacyForum Posts: 1,664 ✭✭
    Good morning Brian,

    I suggested using the XML Transformer so that you can observe the resultant output and visually ensure that everything looks correct. However, it is not a necessary tool. You can instead add the "soaptest.api" package to the method tool, and return SOAPUtil.getXMLFromString([result], 1) instead. The last line will then inform SOAtest that the output is indeed XML, and should be treated as such (instead of just a regular String).

  • LegacyForum
    LegacyForum Posts: 1,664 ✭✭
    Actually, I like it. The teams here are trying to get away from too much scripting as they can be more difficult to decipher when batch runs are performed at night. I'll keep the Transformer!

    Many thanks!