|
|
 next
|
  Subject: Web Service Call fails - targetNameSpace, DefaultNameSpace Issue
Author: Eddie Koehn
Date: 08 Apr 2008 08:58 PM
|
Hello,
I am encountering an error when I make a Web Service Call. I am using Stylus Studio 6 Release 2. I also tried the same wsdl in an eval copy of the 2008 Enterprise and still encountered similar problems.
I have attached the wsdl file in question for reference. When I open the wsdl in a new "Web Service Call", the pertinent parameter information is formatted as follows:
<tns1:Z_EKTEST>
<tns1:PARM_IN/>
</tns1:Z_EKTEST>
. . . for testing I add a value: <tns1:PARM_IN>test</tns1:PARM_IN>
Seems simple enough . . . but when I test, it fails. The back end server (Cast Iron appliance) returns the message:
"The following item(s) were invalid: Content model does not allow element <tns1:PARM_IN>"
If I change the parameter as follows, it works:
<tns1:Z_EKTEST>
<PARM_IN>test</PARM_IN>
</tns1:Z_EKTEST>
In other words, if I "unqualify" (no-namespace) the nested elements in the request schema, the service works just fine.
My first thought was that the server (Cast Iron appliance) must be at fault for not recognizing the qualified element (<tns1:PARM_IN>). When calling Cast Iron's tech support, the responded that they use the tool Oxygen XML for testing purposes and the service tested fine in Oxygen without any adjustments.
So I tried this same wsdl in an evaluation copy of Oxygen XML, and another open-source WSDL test tool, PushToTest (SoapUI). In both of these other tools, the nested elements are automatically "unqualified" for testing purposes and therefore the service runs successfully without any manipulation (i.e. manual unqualifying of elements).
I prefer to use Stylus Studio for wsdl testing. I have used Stylus Studio for a number of years and it has proved invaluable - it is simply a great tool that has saved a lot of time (creating xml, transformations and web testing).
So I have a number of questions related to this issue:
1) Is there any way in Stylus Studio (version 6 release 2), in the web service call scenario to force the generation of the request envelope without qualifying the nested elements of the request
2) Does a newer version of Stylus Studio solve this problem, or at least give options as to how the request envelope is generated?
3) On a theoretical level, are nested elements supposed to be qualified, optional, or qualified only under certain conditions. It seems to me that <tns1:PARM_IN> would always be equivalent to <PARM_IN> if they are a nested element and the parent element is appropriately namespaced with "tns1". But I don't know what rules are supposed to apply here. It's apparent that different applications/solutions treat this issue differently.
Thanks in advance for your help.
Eddie
 HereGoes.wsdl
wsdl
|
|
next
|
Subject: Web Service Call fails - targetNameSpace, DefaultNameSpace Issue
Author: Eddie Koehn
Date: 09 Apr 2008 11:45 AM
|
Hi Alberto,
Thank you for the response. It does help some, but I am still looking for further clarification.
I found the same result in Stylus Studio 2008 which you describe. If I manually remove the default namespace (xmlns="urn:sap-com..."), I do get the correct SOAP fragment. However, the down side is that the editing of parameters in the upper pane is then no longer possible. I can change the soap envelope xml directly, but I no longer have use of the parameter editor. It would make me very happy if this simply worked rather than having to repeatedly remove/replace the default namespace.
The dilemma I have is that we need a test tool for some rather complicated web service calls. We own and know Stylus Studio. We don't want to buy/learn a new tool (i.e. Oxygen) when for all other purposes Stylus Studio serves so well.
***********************************************************************
The crux of my last question (3 On a theoretical level . . .) was to understand if Stylus Studio is indeed generating the Soap request envelope according to strict SOAP standard rules. If so, and if I can understand and articulate those specifics back to our service Vendor (Cast Iron), perhaps I could plead the case and attempt to convince them that their implementation requires modification to accept the kind of soap request envelope that Stylus Studio is generating.
***********************************************************************
I can also pose the question another way.
Here is the soap request envelop generated by Stylus 2008
-------------- envelope generated by Stylus ---------------------
<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<tns1:Z_EKTEST
xmlns="urn:sap-com:document:sap:rfc:functions"
xmlns:tns1="urn:sap-com:document:sap:rfc:functions">
<PARM_IN/>
</tns1:Z_EKTEST>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
-----------------------------------------------------------------
Here is the soap request envelope generated by Oxygen:
-------------- envelope generated by Oxygen ---------------------
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
<Z_EKTEST xmlns="urn:sap-com:document:sap:rfc:functions">
<PARM_IN xmlns=""/>
</Z_EKTEST>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
-----------------------------------------------------------------
After evaluating the namespaces/prefixes, the essential difference between Stylus and Oxygen is this:
Stylus: <PARM_IN xmlns="urn:sap-com:document:sap:rfc:functions">
Oxygen: <PARM_IN xmlns="">
The question then is: which one is accurate according to the WSDL provided coupled with SOAP standards? Or is there enough wiggle room in the interpretation of SOAP standards that both interpretations would be considered accurate?
Thanks,
Eddie
|
|
|
|
|
top