Forum Discussion

Kevin_Slade's avatar
Kevin_Slade
Contributor
13 years ago

The generated XML is out of order after project update

Attached are 2 sets of WSDL & XSD files for sequential versions of one of our projects.

When the 4.2.1 set is loaded into SoapUI Pro Snapshot soapui-pro-3.6.2-SNAPSHOT-linux-bin.zip 11-May-2011 or older
the generated XML for the PipeCreate request maintains the expected XML structure order.

However if the 4.2.0 set is loaded and then the definitions are updated using the 4.2.1 set, generated xml is not ordered as expected. The result is that the SOAP server that has been created using Axis2C complains and fails to parse the XML.

A sample from the request after the upgrade is below. Note that the extra DelayDataSource and MapInterface sections occur earlier in the XML than expected.

<soapenv:Body>
<nin:PipeCreate>
<Name>test</Name>
<Config>
<nin:DelayDataSource>
<nin:DataObject>
<nin:Type>ROTFILE</nin:Type>
<nin:Name>r3</nin:Name>
</nin:DataObject>
<nin:Delay>12</nin:Delay>
</nin:DelayDataSource>
<nin:MapInterface>
<nin:In>B</nin:In>
<nin:Out>A</nin:Out>
</nin:MapInterface>
<nin:MapInterface>
<nin:In>C</nin:In>
<nin:Out>A</nin:Out>
</nin:MapInterface>
<nin:MapInterface>
<nin:In>D</nin:In>
<nin:Out>A</nin:Out>
</nin:MapInterface>
<nin:Enabled>false</nin:Enabled>
<!--1 or more repetitions:-->
<nin:DataSource>
<nin:Type>ROTFILE</nin:Type>
<nin:Name>R1</nin:Name>
</nin:DataSource>
<!--Zero or more repetitions:-->
<nin:DelayDataSource>
<nin:DataObject>
<nin:Type>ROTFILE</nin:Type>
<nin:Name>r2</nin:Name>
</nin:DataObject>
<nin:Delay>12</nin:Delay>
</nin:DelayDataSource>
<!--Optional:-->
<nin:MergeSources>?</nin:MergeSources>
<!--Optional:-->
<nin:DataSink>
<nin:Type>DAG</nin:Type>
<nin:Name>dagmod.3</nin:Name>
</nin:DataSink>
<!--Optional:-->
<!--Optional:-->
<!--0 to 4 repetitions:-->
<nin:MapInterface>
<nin:In>A</nin:In>
<nin:Out>A</nin:Out>
</nin:MapInterface>
<nin:OutputDataType>ERF</nin:OutputDataType>
<!--Optional:-->
<!--Optional:-->
<!--Optional:-->
<!--Optional:-->
<!--Optional:-->
<!--Optional:-->
<nin:PilotEnabled>false</nin:PilotEnabled>
<!--Optional:-->
<nin:Replay>
<nin:Enabled>true</nin:Enabled>
<!--Optional:-->
<nin:Rate>
<nin:Mode>RELATIVE</nin:Mode>
<!--Optional:-->
<!--Optional:-->
<nin:ScaleFactor>1</nin:ScaleFactor>
<nin:BitRate>123</nin:BitRate>
</nin:Rate>
<!--Optional:-->
<!--Optional:-->
<nin:Count>13</nin:Count>
<!--Optional:-->
</nin:Replay>
<!--Optional:-->
<nin:FastFilterEnabled>?</nin:FastFilterEnabled>
<!--Optional:-->
</Config>
</nin:PipeCreate>
</soapenv:Body>
</soapenv:Envelope>

5 Replies

Sort By
  • Kevin_Slade's avatar
    Kevin_Slade
    Contributor
    13 years ago
    Further to above information, when array elements are deleted and then later recreated (eg DelayDataSource) the DelayDataSource section of the XML is generated immediately below the <Config> rather than below the <nin:DataSource> elements where it is expected.

    The result of this is that the XML ordering is lost and the Axis2C soap server refuses to process the generated XML. Manually moving the out of order XML elements to to appropraite place allows the Axis2C server to process the request.

             <Config>
                <nin:DelayDataSource>
                   <nin:DataObject>
                      <nin:Type>ROTFILE</nin:Type>
                      <nin:Name>rot_col3</nin:Name>
                   </nin:DataObject>
                   <nin:Delay>15</nin:Delay>
                </nin:DelayDataSource>
                <nin:DelayDataSource>
                   <nin:DataObject>
                      <nin:Type>ROTFILE</nin:Type>
                      <nin:Name>rot_col4</nin:Name>
                   </nin:DataObject>
                   <nin:Delay>20</nin:Delay>
                </nin:DelayDataSource>
                <nin:Enabled>false</nin:Enabled>
                <!--0 or more repetitions:-->
                <nin:DataSource>
                   <nin:Type>ROTFILE</nin:Type>
                   <nin:Name>rot_col1</nin:Name>
                </nin:DataSource>
                <!--Optional:-->
                <nin:DataSource>
                   <nin:Type>ROTFILE</nin:Type>
                   <nin:Name>rot_col2</nin:Name>
                </nin:DataSource>

    <!-- The <nin:DelayDataSource> elements need to be inserted here -->

                <nin:MergeSources>CONCURRENT</nin:MergeSources>
  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    SmartBear Alumni (Retired)
    13 years ago
    Hi,

    Could you post the full contents of the request before updating to 4.2.1? This will make it easier for us to reproduce what is happening when you update the wsdl. Also, are you using the "Update Definition" or the "Refactor Definition" functionality? For more information on WSDL refactoring, see this link.

    Regards,
    Dain
    eviware.com
  • Kevin_Slade's avatar
    Kevin_Slade
    Contributor
    13 years ago
    Hi Dain

    Attached is a copy of the SoapUI test suite prior to the 4.2.1 update.

    I use "Update Definition" to move forward from one WSDL revision to a later version.

    The second posting is taken from a soap call PipeCreate that was generated from the 4.2.1 WSDL as a new SoapUI project and the Soap request for PipeCreate had values entered, and the some of the array elements added, deleted and then added again. It is the subsequent additions that cause the data elements to placed out of order. This is the crux of the problem. As can be seen from the attached project the test cases can be complex.

    Please let me know if you need more information

    Thanks
    Kevin
  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    SmartBear Alumni (Retired)
    13 years ago
    Hi,

    Can you try using "Refactor Definition" instead of "Update Definition" and see if that works any better?

    Regards,
    Dain
    eviware.com
  • Kevin_Slade's avatar
    Kevin_Slade
    Contributor
    13 years ago
    Hi Dain

    I will check using "Refactor Definition", BUT the main issue is that when some of the operations, especially PipeCreate are edited, by the deletion and later addition of one of the array elements, the XML that is generated, is out of order.

    This may be due to the complexity of the definition for this operation.

    Regards
    Kevin