Watch, Follow, &
Connect with Us

Please visit our new home
community.embarcadero.com.

Public Report
Report From: Delphi-BCB/SOAP/WSDL Importer    [ Add a report in this area ]  
Report #:  35512   Status: Closed
WSDL Importer does not generate Array types from MaxOccurs="unbounded"
Project:  Delphi Build #:  8.1
Version:    7.0 Submitted By:   Chiel van Eeden
Report Type:  Basic functionality failure Date Reported:  10/20/2006 5:47:27 AM
Severity:    Critical / Show Stopper Last Updated: 3/20/2012 2:24:39 AM
Platform:    All versions Internal Tracking #:   242796
Resolution: Fixed (Resolution Comments) Resolved in Build: :
Duplicate of:  None
Voting and Rating
Overall Rating: (1 Total Rating)
5.00 out of 5
Total Votes: 8
Description
This problem looks like the defects reported in QC#24056, QC#28062 and in QC#30712.

To put it straight: An array with objects, defined with maxOccurs="Unbounded"  is not always recognized as such.

We were able to setup a relative simple WSDL in which the problem occurs and also not occurs.

The generation is sucessful when the complexType contains a sequence with one element which also has the maxOccurs="Unbounded". The generation fails when the same complexType, contains more than one element. The last situation will be merely the case and this bug will burst beautiful SOAP-dreams into bubbles.

25-10-2006:  I have checked this out on Borland Developer Studio 2006 and there seems to be no relevant difference in the resulting output of the WSDL-importers in these versions.

For more details, see below

Yours sincerely,
Chiel van Eeden

In WSDL:

<complexType name="ArrayRequest">
  <sequence>
    <element maxOccurs="unbounded" name="objectArray" nillable="true" type="tns2:SingleObject"/>
    <element name="disturb" nillable="true" type="xsd:string"/>
  </sequence>
</complexType>
<complexType name="SingleObject">
  <sequence>
    <element name="text" nillable="true" type="xsd:string"/>
  </sequence>
</complexType>
<complexType name="ArrayResponse">
  <sequence>
    <element maxOccurs="unbounded" name="objectArray" nillable="true" type="tns2:SingleObject"/>
  </sequence>
</complexType>

WSDL Importer produces:

  SingleObject         = class;                 { "http://bean.arraytestservice.soap.fair.nl.fortis.com" }
  ArrayRequest         = class;                 { "http://bean.arraytestservice.soap.fair.nl.fortis.com" }
  ArrayResponse        = class;                 { "http://bean.arraytestservice.soap.fair.nl.fortis.com"[A] }

The generated comment after the class declaration contains also the indication [A] if the class is recognized as an array.

In the class ArrayRequest the recognition fails and wrong class declarations and implementation are generated, while the class ArrayRespones is generated according our expectations. The only difference between those classes is an extra element typed string and named 'disturbed' in the class ArrayRequest.


Steps to Reproduce:
I've zipped two WSDL's, the first named 'ArrayTestWebService_Right.wsdl' and the second named 'ArrayTestWebService_Wrong.wsdl'.

Also included in zip is the resulting pascal and a commandfile to launch the importer with controlled options in order to reproduce the results.

Just put these WSDL's through the importer and look at the differences.

Workarounds
A workaround can be to redesign the interface and wrap the arrays in an single object. In our case we are lucky to have the opportunity to do so.

On 3rd-party interfaces, I can only think of patching the generated pascal and hope no more problems will show up at runtime. This is not what I've tried or even intend to try. However, if you're desperate this could be an approach, but if you don't have a good idea about what you're doing, just forget it. My suggestion for daredevils only is to follw the next steps:

1) Generate form the original WSDL the sourcecode, which contains the erroneaous code and keep this aside.
2) Strip all disturbing elements from the original WSDL
3) Generate again the sourcecode, but now with hopefully the correct implementations of the array(s).
4) Replace the erreneaous declarations and incorrect generated constructions by the correct ones.

It won't be simple as that, but maybe it will help you to get a step further.
Attachment
RightAndWrong.zip
Comments

John Sargent at 10/25/2006 7:32:30 PM -
That is intriguing that you discovered the fact that when wrapped within a single object with no disturbing elements along side of the array, there is no problem. I'm not so lucky to try your solution since I'm consuming someone else's web service and my array is in a structure along side of disturbing elements tied into the interpretation of the array.

Otherwise, good job finding an interim solution for someone that can control their own WSDL file if they're doing both sides.

(I posted QC #28062 a while ago.)

Server Response from: ETNACODE01