Anne
On 1/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]
> wrote:
Hi,
We have a problem with Axis schema checking.
We use a SOAP Gateway component that checks the legality of request and return
structures plus there content.
We are using Axis 1.2.1 and get the incorrect ordering of elements from the
standard bean serializer for the response
The WSDL defines a complexType with a sequence defined (these elements should
apear in this order for correct schema checking)
<complexType name="QueueResultS">
<sequence>
<element name="internalSpId" nillable="true" type="xsd:string"/>
<element name="orderType" nillable="true" type="xsd:string"/>
<element name="orderId" nillable="true" type="xsd:string"/>
<element name="productCode" nillable="true" type="xsd:string"/>
<element name="msisdn" nillable="true" type="xsd:string"/>
<element name="simNumber" nillable="true" type="xsd:string"/>
<element name="errorCode" nillable="true" type="xsd:string"/>
<element name="backEndSystem" nillable="true" type="xsd:string"/>
<element name="optionId" nillable="true" type="xsd:string"/>
<element name="orderStartDate" nillable="true" type="xsd:string"/>
<element name="orderErrorDate" nillable="true" type="xsd:string"/>
<element name="executionDate" nillable="true" type="xsd:string"/>
<element name="MNPPortingDate" nillable="true" type="xsd:string"/>
<element name="FLNPortingDate" nillable="true" type="xsd:string"/>
<element name="channelId" nillable="true" type="xsd:string"/>
<element name="eaiOrderStatus" nillable="true" type="xsd:string"/>
<element name="spOrderStatus" nillable="true" type="xsd:string"/>
<element name="eaiOrderId" nillable="true" type="xsd:string"/>
<element name="spOliInternalStatus" nillable="true" type="xsd:string"/>
<element name="oliId" nillable="true" type="xsd:string"/>
</sequence>
</complexType>
However, The actual SOAP result created by Axis does not honour this sequence
of elements and we have a return type created as follows.
<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope xmlns:soapenv=" http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns1:getFailedOrdersResponse
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/ "
xmlns:ns1="http://interfaces.ejb.spain.o2.com">
<getFailedOrdersReturn soapenc:arrayType="ns2:QueueResultS[1]"
xsi:type="soapenc:Array" xmlns:ns2=" http://soap.vo.ejb.spain.o2.com"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
<getFailedOrdersReturn xsi:type="ns2:QueueResultS">
<FLNPortingDate xsi:type="xsd:string" xsi:nil="true"/>
<MNPPortingDate xsi:type="xsd:string" xsi:nil="true"/>
<backEndSystem xsi:type="xsd:string">1</backEndSystem>
<channelId xsi:type="xsd:string">3</channelId>
<eaiOrderId xsi:type="xsd:string">S0000000008</eaiOrderId>
<eaiOrderStatus xsi:type="xsd:string">Q</eaiOrderStatus>
<errorCode xsi:type="xsd:string" xsi:nil="true"/>
<executionDate xsi:type="xsd:string">2005-11-18
12:41:01</executionDate>
<internalSpId xsi:type="xsd:string">SP001</internalSpId>
<msisdn xsi:type="xsd:string" xsi:nil="true"/>
<oliId xsi:type="xsd:string">1</oliId>
<optionId xsi:type="xsd:string" xsi:nil="true"/>
<orderErrorDate xsi:type="xsd:string" xsi:nil="true"/>
<orderId xsi:type="xsd:string">14</orderId>
<orderStartDate xsi:type="xsd:string">2005-11-18
12:43:48</orderStartDate>
<orderType xsi:type="xsd:string">MIGOPT</orderType>
<productCode xsi:type="xsd:string">O2P0002</productCode>
<simNumber
xsi:type="xsd:string">8949245006672055011</simNumber>
<spOliInternalStatus
xsi:type="xsd:string">Q</spOliInternalStatus>
<spOrderStatus xsi:type="xsd:string">Q</spOrderStatus>
</getFailedOrdersReturn>
</getFailedOrdersReturn>
</ns1:getFailedOrdersResponse>
</soapenv:Body>
</soapenv:Envelope>
As can be seen the getFailedOrdersReturn with a complexType shown above in the
WSDL schema section, does not follow the sequence defined in the complexType.
This is a problem for us as it is not possible to use schema checking on the
responses.
Is there a workaround for this? Creating custom serializers is NOT an option as
we have over 200 complex types used as return obects within our service.
I would assume that the Axis implementation is a defect as it does not honour
the scheme sequence definition.
Regards
Steven McArdle
