on 06-30-2009 3:45 AM
Hi All,
Have a requirement to Consume an External Web Service in ABAP. We have the WSDL for Ext. Web Service.
Did some research and came across the link:
http://help.sap.com/saphelp_nw2004s/helpdata/en/69/8a1e9553dc4baba6026a3db510cadb/content.htm
First tried to generate a 'Consumer Proxy'. Since external WSDL, used SE80 to generate the Consumer Proxy.
But finally got Error Msg 'Incorrect value: XSD name space not available'! Could you please let me know:
1) What is causing this error and how to rectify it?
2) Is it possible to view the Proxy that I had created (which is in error)? is there a Proxy Editor?
I agree with Chris. It has nothing to do with security as the other poster indicates. I have never had a successful generation of a proxy object via URL or via file if the file wasn't modified. I always have to paste the WSDL into Wordpad and edit the WSDL until all conflicts are removed. It's just another one of those SAP tools that doesn't work as designed.
Look for the offending XSD namespace declarations in the WSDL and comment them out in a file until the error goes away. You should still be able to generate a good proxy object after that. Other common errors are due to additional bindings in the WSDL, such as for http. You can easily remove those in a file.
Chris, thanks for posting that note - I had not seen that program before.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Brad,
Thanks for your post!
I am glad to hear I am not the only one having this trouble.
Unfortunately I am new to Web Services, XML, etc. so for me to change the WSDL file is a bit of a challenge at this point, but I may try (always a good learning opportunity, right?)...
Another alternative (and I hate to go back in time to older technologies) I had success with is using the "HTTP_POST" function module (completely bypassing the Proxy generation) in order to pass the XML request and get the result back. Any thoughts on that?
Edited by: Christopher Twirbutt on Jul 1, 2009 6:50 PM
Editing a WSDL isn't very difficult - you'll get used to it after a bit of trial and error. I've never had the need to use the HTTP_POST function in previous versions. However, I do use the HTTP classes frequently now and the HTTP RFC destination type. It's easy to use and supports SSL with the SAP Crypto library installed. You should have no issues there.
Hi Brad,
In case I do end up using Proxy generation, I was wondering is there any way you can take a quick glance at the WSDL and see if there are some obvious changes you would make to get it to generate the Proxy ?
Here is the WSDL:
https://addresscheck.melissadata.net/v2/SOAP/Service.wsdl
I would greatly appreciate any input as this is all brand new to me.
Hello Brad,
Thanks for your inputs.
You have mentioned to look for the offending XSD namespace declarations in the WSDL and comment them out.
This question might sound really naive (sorry I am new to SOA):
How do we identify the incorrect XSD namespace declaration in WSDL? What exactly is XSD namespace, do we need to
map anything, even before we try to generate a Proxy for a WSDL?
When I try to generate the Proxy it just gives error message: 'Incorrect Value: XSD Namespace not available'
(The actual message is in German 'Incorrect value: XSD Namensraum nicht verfugba') & does not specify the field, so I am confused which field in WSDL is causing this error.
@ Chris - Thanks for your inputs as well and for sharing the Note.
Hi Chris,
I took the WSDL you posted and successfully generated a Client Proxy from it with out modifications.
I am assuming that you needed to generate the client proxy and not the server proxy as the interface definition in that WSDL is created as an outbound interface.
what I have done is opened your link, then just viewed the source of the page (right click, choose view source) and then saved that as an XML file on my local machine.
When creating the Proxy Object, I simply reference that XML file saved on my local machine.
So it seems that there is no need for changes to WSDL?
Kind Regards
Pravesh
Edited by: Pravesh Parbhoo on Jul 2, 2009 10:26 AM
you forgot to tell where you created the proxy.
apart from the fact that you silently avoided the shortcoming of the proxy wizard when trying to call HTTPS-URLS, when I try your approach on 7.0, 7.01 EHP4, 7.02 I always get the same error 'Unknown TypeReference q1:RequestArray'. And there is probably more. So, I am one more who is not able to create a proxy object for the above WSDL without any modifications to the WSDL itself.
anton
I had the same issue on NW7.0 SP16 with the WSDL that Chris posted. However, I saved it as an XML file and edited it in Wordpad to remove the 'alias' references for RequestArray and ResponseArray and moved the complex type definitions up under their respective element declarations. Then the proxy class generated just fine. There may have been another way to go about it as well, though.
Hy Brad, I got the same error by trying to generate a 'Consumer Proxy' from a external WSDL. u2019Incorrect value: XSD name space not available'. I have solved it in this way: The report RSSIDL_DESERIALIZE_DEMO has the same check routines as the R3-Proxy Generator. I debugged this report using a saved external WSDL and compared it with using a saved WSDL (Server) generated under /nse80.
-> In the WSDL, in part message the "type" isnu2019t allowed, because the dezerialization is done already.
Coding, not working:
<xsd:complexType name="OrderRequestMsg">
<xsd:sequence>
<xsd:element name="shop" type="xsd:string"/>
u2026
</xsd:sequence>
</xsd:complexType>
<message name=" OrderRequest">
<part name="input" type=" tns:OrderRequestMsg"/>
</message>
Coding, working::
<xsd:element name="OrderRequestMsg">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="shop" type="xsd:string"/>
...
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<message name="OrderRequest">
<part name="input" element="tns:OrderRequestMsg"/>
</message>
Hi experts!
I am very pleased to see, that i am not the only one with this problem... Did you already find a solution for it or do you still correct the WSDL manually? (-> this could definitive not be the solution... )
Currently i am trying to find, what i have to correct in my WSDL... -> this is not very funny...
When i try to generate proxy classes in Visual Studio 2008 there is no error..
In SAP i get one error after the other...
Thank you for your comments...
Can you make sure you have proper authorization for webservice creation,you have to be a registered developer. In SAP Service Market place, you will get developer access key. This should be entered in DEVACCESS table by creating any development object.
below notes would helpyou (follow the pdf document in the note).
regards
nag
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Chandy,
The Proxy Class/Object can be managed via SE80 only after it has been successfully generated.
Since you are getting this error during generation, the Proxy Class never gets created, hence you have nothing to view (but the error itself).
I am having this trouble with many (if not all external Web Services).
I have even opened up some OSS notes to ask for assistance but the only replies I have received are that SAP doesn't support the SOAP 1.2 version or some other aspect of the WSDL bindings etc. So I too am stuck (haven't found a single external Web Service I can consume in BASIS/ABAP version 700).
I have found an OSS note that explains the limitations of Proxy generation of WSDLs in SAP. The note # is 1327511.
I will let you know if/when I learn anything else (I am very experienced in ABAP, but new to Web Services/SOA, etc.). Please do the same so we can share our experiences.
Thanks!
-Chris
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
101 | |
13 | |
13 | |
11 | |
11 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.