xsi:type is not handled as QName when parsing SOAP request

[Anonymous]

Good afternoon,
we are using Talend ESB 5.5 and facing a problem with parsing a SOAP message with xsi:type attribute set to xsd:string under certain circumstances. Essentially, it seems that xsi:type attribute is improperly handled as string, whereas it should be treated as QName.
Below is a fragment of our WSDL. We have an untyped element "in" in the request message, and the client sets a specific type to it, depending on a context. This is just a PoC, not a real-world situation, that is more complex, but this describes the problem easily.

 <wsdl:types>
  <xsd:schema xmlns:xsd=""
   targetNamespace="">
   <xsd:element name="testOperation">
    <xsd:complexType>
     <xsd:sequence>
      <xsd:element name="in" nillable="true"></xsd:element>
     </xsd:sequence>
    </xsd:complexType>
   </xsd:element>
  </xsd:schema>
 </wsdl:types>
 <wsdl:message name="testOperation">
  <wsdl:part name="parameters" element="tns:testOperation"></wsdl:part>
 </wsdl:message>
 <wsdl:portType name="testPortType">
  <wsdl:operation name="testOperation">
   <wsdl:input message="tns:testOperation"></wsdl:input>
   .......
  </wsdl:operation>
 </wsdl:portType>

Now, we send the following request to ESB:

<soapenv:Envelope xmlns:soapenv="" xmlns:ser="">
   <soapenv:Body xmlns:xsd="" xmlns:xsi="" >
      <ser:testOperation>
         <in xsi:type="xsd:string">aaa</in>
      </ser:testOperation>
   </soapenv:Body>
</soapenv:Envelope>

The request is perfectly valid. We defined xsi and xsd prefixes on the Body element. However, when this message is sent to tESBProviderRequest and logged using tLogRow, the message is like this:

<?xml version="1.0" encoding="UTF-8"?>
<ser:testOperation xmlns:ser="">
   <in xmlns:xsi="" xsi:type="xsd:string">aaa</in>
</ser:testOperation>

So what happened is that xsi prefix definition was moved from soapenv:Body to the lowest-level element, however, xsd prefix did not. Whereas the repositioning of the xsi prefix definition itself is perfectly fine, the other one was lost. It seems that xsi:type was improperly handled as a pure string, not as a QName, and this is why the parser decided to remove xsd prefix - it was never used.
I have to say that everything works fine magically when I move both prefix declarations one level lower, beneath Body element (see the SOAP message and the parsed message below):

<soapenv:Envelope xmlns:soapenv="" xmlns:ser="">
   <soapenv:Body>
      <ser:testOperation xmlns:xsd="" xmlns:xsi="" >
         <in xsi:type="xsd:string">aaa</in>
      </ser:testOperation>
   </soapenv:Body>
</soapenv:Envelope>

<?xml version="1.0" encoding="UTF-8"?>
<ser:testOperation xmlns:ser="" xmlns:xsd="" xmlns:xsi="">
   <in xsi:type="xsd:string">aaa</in>
</ser:testOperation>

Suddenly, the xsd prefix definition is preserved.
Unfortunately, this approach cannot be accepted as a work-around, because the client system is out of our control, as we are the ones who has to implement their interface as per their requirements and status quo.
Any support will be appreciated.
Michal Bures
P.S. I just found out that the namespace URIs were removed from the code above - a wierd feature of this forum. Please consider the namespace URIs are as usual.

[Anonymous]

Hi
Check the 'log message' box in the advanced settings tab to see the request message received by  tESBProviderRequest, I remember the request message contains body element.
Best regards
Shong

[Anonymous]

Hi Shong,
the logging check-box works fine, and the whole SOAP message is logged, which is correct. However, this is not the problem.
The real problem is that when the message comes to further processing, the XSD namespace definition gets lost. The xsi:type should be a QName, so it should preserve both namespace and the token name, but rather it is handled as a plain text string.
Imagine that ESB works as a simple proxy, for example. So the same request is passed from the client to ESB and then to a back-end. In this scenario, ESB looses the XSD namespace definition, which causes the back-end web service to fail, due to an invalid XML message.
Hope this clarifies the problem.
Michal

[Anonymous]

Hi Michal 
I have reproduced the issue, but I am not sure if it is a bug or not, can you please a jira issue on our bugtracker? Our developers will investigate it further.
BR
Shong

[Anonymous]

Reported as TESB-14912.