XML Editor
Sign up for a WebBoard account Sign Up Keyword Search Search More Options... Options
Chat Rooms Chat Help Help News News Log in to WebBoard Log in Not Logged in
Show tree view Topic
Topic Page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Go to previous topicPrev TopicGo to next topicNext Topic
Postnext
Eddie KoehnSubject: 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





DocumentHereGoes.wsdl
wsdl

Postnext
Alberto MassariSubject: Web Service Call fails - targetNameSpace, DefaultNameSpace Issue
Author: Alberto Massari
Date: 09 Apr 2008 02:47 AM
Originally Posted: 09 Apr 2008 02:48 AM
Hi Eddie,
I tried creating a new Web Service Call document based on your WSDL schema using Stylus Studio 2007 Release 1, and the SOAP fragment I got was

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<tns1:Z_EKTEST xmlns:tns1="urn:sap-com:document:sap:rfc:functions">
<PARM_IN/>
</tns1:Z_EKTEST>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Unfortunately Stylus Studio 2008 attempts to preserve the namespace bindings used by the schema, and ends up adding a xmlns="urn:sap-com:document:sap:rfc:functions" to tns1:Z_EKTEST that makes PARM_IN fall in the same tns1 namespace; you must then manually remove the namespace binding in order to get the correct SOAP fragment.

As for your question about children elements being automatically in the same namespace of the parent, that's not true: every element is potentially in any namespace, obtained by looking at what is specified in a xmlns:prefix binding found in the element or in its ancestors.

Hope this helps,
Alberto

Postnext
Eddie KoehnSubject: 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



Postnext
Ivan PedruzziSubject: Web Service Call fails - targetNameSpace, DefaultNameSpace Issue
Author: Ivan Pedruzzi
Date: 10 Apr 2008 11:05 AM
Originally Posted: 10 Apr 2008 10:24 AM
Eddie

What you are experiencing is a Stylus Studio defect, we are working on a fix for the upcoming release.

Background:

By default in XML Schema local elements are declared "unqualified" therefore they are place in the default namespace. For example if you look at the WSDL embedded schema you see


<xsd:element name="Z_EKTEST">
<xsd:complexType>
<xsd:all>
<xsd:element name="PARM_IN">
<xsd:annotation>
<xsd:documentation/>
</xsd:annotation>
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:maxLength value="10"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:all>
</xsd:complexType>
</xsd:element>

A valid fragment for the above declaration is

<tns1:Z_EKTEST
xmlns:tns1="urn:sap-com:document:sap:rfc:functions">
<PARM_IN>aaa</PARM_IN>
</tns1:Z_EKTEST>

Stylus Studio is generating a similar structure but tries to re-use the namespace declarations from the WSDL and it ends up overriding the default namespace.

A temporary workaround could be saving a local copy of the WSDL and remove the following declaration from the xsd:schema element

xmlns="urn:sap-com:document:sap:rfc:functions"

At this you should be able to use the parameters tree


Hope this helps
Ivan Pedruzzi
Stylus Studio Team


DocumentHereGoes(1).wsdl

Posttop
Eddie KoehnSubject: Web Service Call fails - targetNameSpace, DefaultNameSpace Issue
Author: Eddie Koehn
Date: 10 Apr 2008 11:16 AM
Hi Ivan,

It works and it's a simple workaround.
Thanks for the info.

Eddie

 
Topic Page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Go to previous topicPrev TopicGo to next topicNext Topic
Download A Free Trial of Stylus Studio 6 XML Professional Edition Today! Powered by Stylus Studio, the world's leading XML IDE for XML, XSLT, XQuery, XML Schema, DTD, XPath, WSDL, XHTML, SQL/XML, and XML Mapping!  
go

Log In Options

Site Map | Privacy Policy | Terms of Use | Trademarks
Stylus Scoop XML Newsletter:
W3C Member
Stylus Studio® and DataDirect XQuery ™are from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2016 All Rights Reserved.