Forum Discussion

Kevin_Slade's avatar
Kevin_Slade
Contributor
17 years ago

WSDL fields with min=1, Max=1, nillable,type=DateTime are seen as mandatory



This is regarded by SoapUI as a mandatory field and must have a valid DateTme entry.

The correct behaviour should be to allow an empty field to be used and if the value is empty (nill) the XML should have a corresponding entry of:


                 

A WSDL file that has this property set is attached.

9 Replies

  • omatzura's avatar
    omatzura
    Super Contributor
    Hi Kegin,

    thanks, this should be fixed in the next update..

    regards!

    /Ole
    eviware.com
  • christof's avatar
    christof
    Occasional Contributor
    This is still a problem for me in responses. A datetime field is defined in my service as follows:

    <xsd:element name="valid_until" nillable="true" type="xsd:dateTime"/>


    And turns up in the response XML like this:

    <valid_until/>


    Which should be fine, but I get:

    Invalid date value: wrong type:


    from my schema compliance assertion.

    I am using SoapUI pro (trial) 4.0.1

    Any help on this?
  • RJanecek's avatar
    RJanecek
    Regular Contributor
    this: <valid_until/> isnt valid against your xsd. You should have something like this:

    <valid_until nameOfNamespace:nil="true"/>
  • christof's avatar
    christof
    Occasional Contributor
    <valid_until/> is a child of <ns1:get_queueResponse>.
    ns1 is the namespace that the schema declaration in the WSDL has as a targetNamespace.
    This should be correct, no?
  • christof's avatar
    christof
    Occasional Contributor
    Well, the whole thing is huge and it's not a public api, but here's the relevant part:

    WSDL:
    <definitions name="my_api" targetNamespace="https://my_namespace" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="https://my_namespace" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
    <types>
    <xsd:schema targetNamespace="https://my_namespace">
    <xsd:complexType name="message">
    <xsd:all>
    <xsd:element name="message_type" type="tns:wsws_message_simple_message_type"/>
    <xsd:element name="message" type="tns:wsws_message_simple_customer_message"/>
    <xsd:element name="confirm_until" nillable="true" type="xsd:dateTime" minOccurs="1" maxOccurs="1"/>
    <xsd:element name="url" type="tns:wsws_message_simple_url"/>
    </xsd:all>
    </xsd:complexType>
    ...


    The response:
    <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="https://my_namespace">
    <SOAP-ENV:Body>
    <ns1:get_queueResponse>
    <get_queueResult>
    <messages>
    <item>
    <message_type>queue</message_type>
    <message/>
    <confirm_until/>
    <url/>
    </item>
    </messages>
    </get_queueResult>
    </ns1:get_queueResponse>
    </SOAP-ENV:Body>
    </SOAP-ENV:Envelope>


    Thanks for your time!
  • Hi ,

    Just after having a look into the WSDL file, the first thing i observed is :
    nillable="true" & minOccurs=1
    both coming in at same time for "confirm_until" element.

    Ideally, it should be one of them or if you want to have both than minOccurs=0 should be used will nillable.
    I hope this will help.

    Best Regards,
    {Pradeep Bishnoi}
    http://learnsoapui.wordpress.com
  • christof's avatar
    christof
    Occasional Contributor
    Hi Pradeep

    Thanks for your response. That's kind of what this thread is about though, it's in the title.
    It is a mandatory field, but nillable says it may be empty, which it is in the response.

    I also tried it with like the following though, which also does not work (same schema assertion errors):

    <xsd:element name="confirm_until" nillable="true" type="xsd:dateTime" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="confirm_until" nillable="true" type="xsd:dateTime"/>


    Can anybody else verify this in a testcase? Judging by omatzura's response, this shouldn't be an issue anymore?

    Thanks,
    Christof