Wrong namespace in generated transformation

[Former Member]

Hi Guys.

I'm stuck for quite a while now figuring out why my consumer proxy does not map XML-Response into ABAP-Structure.

Finally i found that the generated simple transformation is expecting a namespaced node (<n1:response ..>).
But the original response from the webservice is just delivering (<response>).

Is there a possibility to define the WSDL in such a way, that generated simple transformation is not expecting a <n1:response> node?
(Additional info: the next node in the WSDL <AccessData> does not own a namespace in the simple transformation!)

Thanks for any help,

Timo

Following a snippet from the simple transformation

<tt:ref name="ROOT">

...

<tt:ref name="ROOT">

And the corresponding parts of the WSDL file:

          <xsd:complexType name="__SearchAccessResponse">

            <xsd:sequence>

              <xsd:element name="AccessData" nillable="true" type="tns:__AccessItem" minOccurs="0"/>

              <xsd:element name="errorCode" nillable="true" type="xsd:string" minOccurs="0"/>

              <xsd:element name="errorMessage" nillable="true" type="xsd:string" minOccurs="0"/>

            </xsd:sequence>

          </xsd:complexType>

          <xsd:complexType name="__AccessItem">

            <xsd:sequence>

              <xsd:element name="item" nillable="true" type="tns:__AccessEntry" minOccurs="0" maxOccurs="unbounded"/>

            </xsd:sequence>

          </xsd:complexType>

...

          <wsdl:message name="_searchAccessOutput" xmlns="">

          <wsdl:part name="response" type="tns:__SearchAccessResponse"/>

         </wsdl:message>

[Former Member]

In the end I called the proxy class, got the XML-Payload over the protocol interface and used an own simple transformation to fill the output structure. So if the WSDL file will some day be generated in the correct way, I just remove the couple of additional lines and everything still works and will be fine.

Thanks for trying to help.

Timo.

[ttrapp]

Hi Timo,

I don't understand the question: the ABAP framework gets a WSDL and creates a proxy. There are some restrictions - not all WSDL (and XML Schema) features are supported. But if the WSDL contains the right features the Simple Transformation is OK - otherwise there is an error in the underlying framework which deserves a OSS note.

I think it is more likely that your SOAP messages doesn't corresond to the WSDL. Did you check this? How was your SOAP message was generated? By the test tool or with a tool called SOAP UI?

Best Regards,

Tobias

[Former Member]

Hi Tobias.
Thanks for your answer. I think you  got the question right.
Unfortunately I can throw a light on the wsdl file caus I got it from the creators of the external web service without any information how it was created. The test of the webservice is going well, I got the right informations back as XML. Only the transformation does not work cause of the n1:response tag (and it is not possible to change the transformation in a generated proxy).

As far as i got it, SAP proxy generation sets the namespace for the message tag.
Even the xmlns=" " didn't help.

<wsdl:message name="_searchAccessOutput" xmlns=" ">
  <wsdl:part name="response" type="tns:__SearchAccessResponse"/>
</wsdl:message>

I think I try calling my proxy and getting the xml-Payload using my own simple transformation.
Someone did that before?

Thanks again,
Timo

If someone wants to dive in I added the response XML as it is send by the web service:

<n0:searchAccessResponse SOAP-ENC:root="1"   
    xmlns:n0="http://first.declared.ns/with/folder"
    xmlns:ser-root="http://first.declared.ns/with/folder"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<response xsi:type="sc1:__SearchAccessResponse" id="id1"    
        xmlns:sc1="http://some.other.url/folder">
    <AccessData xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="sc1:__AccessEntry[1]" id="id2">
        <item xsi:type="sc1:__AccessEntry" id="id3">
            <ZZUT_PROFILNR xsi:type="xsd:string">384</ZZUT_PROFILNR>
            <ZZUT_PROFILNAME xsi:type="xsd:string">Area A</ZZUT_PROFILNAME>
            <ZZUT_P_BESCHR xsi:type="xsd:string">FN Area A</ZZUT_P_BESCHR>
            <ZZUT_PROFILKL xsi:type="xsd:string">FN</ZZUT_PROFILKL>
            <ZZUT_GUELTIGAB xsi:type="xsd:string">20000101000000</ZZUT_GUELTIGAB>
            <ZZUT_GUELTIGBIS xsi:type="xsd:string">99991231235959</ZZUT_GUELTIGBIS>
            <ZZUT_SICHT_KUMU xsi:type="xsd:string">A;N</ZZUT_SICHT_KUMU>
            <ZZUT_BEGLEIT xsi:type="xsd:string">0</ZZUT_BEGLEIT>
            <checkresponsibility xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="sc1:__checkresponsibility[1]" id="id4">
                <item xsi:type="sc1:__checkresponsibility" id="id5">
                    <ZZUT_ID_PRUEF xsi:type="xsd:string">SOMETHING_A</ZZUT_ID_PRUEF>
                    <ZZUT_PRUEFACTION xsi:type="xsd:string">2</ZZUT_PRUEFACTION>
                </item>
            </checkresponsibility>
            <ZZUT_OPKO_BG xsi:type="xsd:string">0</ZZUT_OPKO_BG>
            <ZZUT_P_STATUS_MILK xsi:type="xsd:string">A</ZZUT_P_STATUS_MILK>
        </item>
    </AccessData>
</response>
</n0:searchAccessResponse>

[ttrapp]

Hi Timo,

I implemented a lot of service calls and everytime such an error happens it was the fault of the service provider: the response message is not valid according to the WSDL. So the Web Service provider has to change the URL or the WSDL.

Here some additional information:

• The Simple Transformation is generated by the web service framework of AS ABAP. I can‘t recommend changing the transformation because it is too invasive.
• The Simple Transformation parses a structure with lookahead one – so it’s a subset of an XML Schema validation that checks the structure of the payload as well as the namespace. If the transformation throws an error then it’s either an error of the web service framework of AS ABAP or (much more likely) a error by the web service provider.
• If I look at parts of the web service definition it seems to that this is a poor or at least old fashioned desing style: they use namespaces with http://first.declared.ns/with/folder" and SOAP-ENC:Array. When they work this way it is likely that they confuse namespaces.

Best Regards,

Tobias

[Former Member]

Hi.

One little question still.
Is it possible to define a WSDL in such a way that the first node
of the generated simple transformation is not containing a namespace?

(Highlighted Bold in snippet)

If I remove tns: from wsdl part "response" I will get an parsing error,
if adding targetNamespace=" " to complexType "__SearchAccessResponse the generation
fails, because of missing element (In part it is defined with tns).
So that's a roundabout I can't get out...

@Tobias
The soap response file I use is the answer to an original call to the web service from SAP, no test tool or SoapUI involved. Only the mapping response -> ABAP structure is the problem

Every help or hint is highly appreciated,
Timo
 
<!--
name /1SAI/TXEDC219B307A807524CFCF
object CLAS
obj_name ZTSCCO_CRM_EXOS_PROFILE_PORT_T
method SEARCH_ACCESS
extended
-->

<?sap.transform simple?>
<tt:transform version="1.0" xmlns:tt="http://www.sap.com/transformation-templates" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:sapgdt="http://sap.com/xi/SAPGlobal/GDT" xmlns:ddic="http://www.sap.com/abapxml/types/dictionary"
                            xmlns:prx="urn:sap.com:proxy:E30:/1SAI/TXEDC219B307A807524CFCF:700:2011/05/10" xmlns:n0="http://www.xxxxx.ch/StarGate/crm_profile/SearchAccess/crm_profile" xmlns:n1="http://www.xxxxx.ch/StarGate/crm_profile/SearchAccess">

  <tt:root name="OUTPUT" type="ddic:ZTSCSEARCH_ACCESS_RESPONSE"/>
  <tt:variable name="_C_NIL" val="''"/>
  <tt:template name="ZTSCSEARCH_ACCESS_RESPONSE">
    <tt:context>
      <tt:root name="ROOT" type="ddic:ZTSCSEARCH_ACCESS_RESPONSE"/>
      <tt:variable name="_C_1" val="'3'"/>
    </tt:context>
  <tt:ref name="ROOT">
    <tt:deserialize>
      <tt:group>
        <tt:cond frq="?">
          <n1:response tt:ref="RESPONSE">
          <tt:clear var="_C_1"/>
        <tt:d-cond>

Corresponding WSDL-Entry

         <xsd:complexType name="__SearchAccessResponse">
            <xsd:sequence>
              <xsd:element name="AccessData" nillable="true" type="tns:__AccessItem" minOccurs="0"/>
              <xsd:element name="errorCode" nillable="true" type="xsd:string" minOccurs="0"/>
              <xsd:element name="errorMessage" nillable="true" type="xsd:string" minOccurs="0"/>
            </xsd:sequence>
          </xsd:complexType>

<wsdl:message name="_searchAccessOutput">
  <wsdl:part name="response" type="tns:__SearchAccessResponse" />
</wsdl:message>

[ttrapp]

Hi Timo,

of course you can try an empty targetNamespace attribute in your WSDL and perhaps it will help you with your problem.

In fact I don't recommend it because this because it can produce interoperability problems. The first reason is that some Java Frameworks have problems with it because they generate package names according to the namespaces. The second reason is that the corresponding standards WSDL and XML Schema are very complicated and there are a lot of interoperability problems. Therefore a new standard WS-I BP was created (SAP was part of that group) that simplified possible WSDL definitions and gave interpretations of the standard in complex cases where different interpretations of a WSDL document are possible. The standard says in http://www.ws-i.org/profiles/basicprofile-1.1.html#WSDL_and_Schema_Definition_Target_Namespaces:

4.3.2 Schema targetNamespace Structure
Requiring a targetNamespace on all xsd:schema elements that are children of wsdl:types is a good practice, places a minimal burden on authors of WSDL documents, and avoids the cases that are not as clearly defined as they might be. 
R2105 All xsd:schema elements contained in a wsdl:types element of a DESCRIPTION MUST have a targetNamespace attribute with a valid and non-null value, UNLESS the xsd:schema element has xsd:import and/or xsd:annotation as its only child element(s). 

WSDL and SOAP is all about interoperability - unfortunately the corresponding standards have contradictions that are resolved in WS-I BP:

http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html#refinement16696288

So my recommendation is to use only WSDLs that are compliant to those standards.

Regards,

Tobias