I'm trying to call a web service method using wsdlpull and it is pretty simple until I get to one service method that accepts a parameter that is an array of complextypes, in this case it takes 1 parameter that is an unbounded number of types containing 2 members - an array of name/value pairs.
<s:complexType name="SendDetails">
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded" name="Detail" type="tns:Detail"/>
</s:sequence>
</s:complexType>
<s:complexType name="Detail">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="Name" type="s:string"/>
<s:element minOccurs="0" maxOccurs="1" name="Value" type="s:string"/>
</s:sequence>
</s:complexType>
and I have no clue how to go about setting these as parameters to wsdlpull.
Does anyone have example code or a snippet to get me started before I rewrite using a different tool?
It seems like the WsdlInvoker doesn't have support for this (yet?). setValue calls setInputValue which in turn calls validate, but this method stops processing when a complex type is detected:
const XSDType * pType = sParser_->getType(typeId);
if (pType && !pType->isSimple()){
return 0;
}
The only complex type that seems to be supported is one that contains a simple content model.
This said, I think gSOAP2 and Microsoft Windows Web Services API are better native alternatives.
Related
I am currently working on implementing a web service based off of an WSDL document.
As far as I know, message-parts describe how the body and the header of the request/response are supposed to look like.
What I don't understand is how I am supposed to know that from reading the WSDL.
Below you see a snippet from the WSDL I am working with.
<wsdl:message name="RateRequestMessage">
<wsdl:part name="Body" element="rate:RateRequest"/>
<wsdl:part name="ABCSecurity" element="upss:ABCSecurity"/>
</wsdl:message>
<wsdl:message name="RateResponseMessage">
<wsdl:part name="Body" element="rate:RateResponse"/>
</wsdl:message>
<wsdl:message name="RateErrorMessage">
<wsdl:part name="RateError" element="error:Errors"/>
</wsdl:message>
In this case, I know that only the parts that are called Body are supposed to be in the body. But is there a general rule? Where can I see that Body is supposed to go in the body of the actual message without looking at the name?
I hope you can help, thank you!
EDIT: You can see what goes in to the body/header of a message in the binding-part.
I am using Apache CXF 3.0.2 for a client and a server. On the server there is a fairly simple web service that accepts various parameters, one of which is a String array:
<xs:complexType name="getThing">
<xs:sequence>
<xs:element minOccurs="0" name="connection" type="tns:connectionID"/>
<xs:element maxOccurs="unbounded" minOccurs="0" name="types" type="xs:string"/>
</xs:sequence>
</xs:complexType>
When the client calls this, it might be that it wishes to pass a single null value for "types" and that's where I encounter problems. The SOAP message from the client looks like this:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns2:getThing xmlns:ns2="http://serverl.url/">
<connection>Connection details....</connection>
<types xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
</ns2:getThing>
</soap:Body>
</soap:Envelope>
I think that's correct, but CXF on the server translates that into an array with a single empty string value; not an array containing a null value. This then causes various issues with the server code.
The interface the server implements looks like this?
ThingResult getThing(#WebParam(name = "connection") ConnectionID connection, #WebParam(name = "types") String[] types)
{ code }
And if 'nil="true"' isn't valid, then why is CXF generating it?
A null array works OK (the client omits the element from the message and the server interprets that as a null) but not an array containing a null value. Why is CXF behaving this way and how do I configure it so the server deserialises the SOAP message correctly back to what the client sent?
I have searched everywhere for the answer and am fairly sure I am missing something embarrassingly obvious!
edit: Added code sample
The schema doesn't have a nillable="true" attribute for the types element. Thus, xsi:nil="true" is not a valid value for that element.
I could find no way of making CXF behave (either in WSDL generation or client respect of the generated WSDL).
Instead I had to modify the server code to treat nulls and empty Strings as if they were equivalent.
An bit of a hack that shouldn't be needed, but seems to work.
I am having issues with trying to create a client using node-soap, and this wsdl:
http://ultra-api.ultradns.com:8008/UltraDNS_WS/v01
It keeps throwing an undefined error once it hits this:
<wsdl:message name="getResourceRecordsOfDNameByTypeResponse">
<wsdl:part name="ResourceRecordList" type="ns1:ResourceRecordList">
</wsdl:part>
</wsdl:message>
If you look at the wsdl it has 4 schemas:
webservice.api.ultra.neustar.com/v01/
webservice.api.ultra.neustar.com/
schema.ultraservice.neustar.com/
jaxb.dev.java.net/array
The ResourceRecordList is in the schema.ultraservice.neustar.com but for some reason node-soap keeps looking into the webservice.api.ultra.neustar.com/v01/ schema.
I've looked through stack overflow, and the issues on node-soap, and haven't figured out where to update the code to look for multiple schemas/namespaces.
Thanks
The solution:
to change line 50 in lib/wsdl.js from
if(obj.hasOwnProperty(key)){
to
if(obj.hasOwnProperty(key) && !base[key]){
thanks to Christiaan W. for the answer
I created a web service using:
Apache Axis 2 CodeGen Wizard v.1.6.2 (Binding: ADB)
Eclipse Juno
Tomcat 7
Java 6
The Service returns a Custom Java Object (DataBean) back to the client, but I stumbled upon an exception in the client code:
org.apache.axis2.AxisFault: org.apache.axis2.databinding.ADBException: Unexpected subelement {schemaTargetNs}message
From what I have researched, over n over again ... I think this is a very common problem but haven't yet got a conclusive answer as to what should be done to rectify it.
Some posts on this and other forums state that the WSDL needs to be modified (some name space), or the client stub needs modification. Some even state that there is a bug in the ADB. It was surely a bug in earlier versions of Axis but there are many posts in the mail-archives stating that the bug was fixed. Those mailing-archives were related to earlier versions of Axis2.
Now my questions are:
Is it still a bug ?
What exactly needs to be changed in the WSDL or the Client stub ?
What is worth mentioning is that I created a similar web service which returns a "String" back to the client. It works fine ! So, it fails when a complex data type is involved.
There was some information on Apache's website, under the heading "Known Limitations"...
It reads: "ADB is meant to be a 'Simple' databinding framework and was not meant to compile all types of schemas. The following limitations are the most highlighted.
Complex Type Extensions and Restrictions."
Is that the problem ?
The following is the snippet from the WSDL file which might be of some interest to you...
<wsdl:types>
<xs:schema xmlns:ax26="http://mywebservice/xsd" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="schemaTargetNs">
<xs:import namespace="http://mywebservice/xsd"/>
<xs:element name="getMsg">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="reqData" nillable="true" type="ax25:DataBean"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="getMsgResponse">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="return" nillable="true" type="ax25:DataBean"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
<xs:schema attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://mywebservice/xsd">
<xs:complexType name="DataBean">
<xs:sequence>
<xs:element minOccurs="0" name="message" nillable="true" type="xs:string"/>
<xs:element minOccurs="0" name="name" nillable="true" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
</wsdl:types>
Now how do I fix the problem ? Should I include some other code snippets here?
"Unexpected subelement" means the message received by the receiver contained an XML element that the receiver wasn't expecting. "{schemaTargetNs}message" is the name of the unexpected element that it encountered. In other words, the sender sent an invalid message to the receiver.
The sender may have included an element which it wasn't supposed to.
The sender may have left out a mandatory element.
The sender may have put the elements in the wrong order.
The sender may have sent a completely incorrect message.
If the server issued the exception that you reported, then the client sent an invalid message to the server. If the client issued the exception, then the error was in the response from the server to the client.
if the xsd(wsdl) is correct with xml request o response is because the problem is the order of xml elements. One posible solution is generate your axis2 client with -Eosv option. that work for me.
The code generated by CodeGen (from WSDL) for the Java Object (bean) that I was using, expected a different namespace for the fields in the bean. Somehow an incorrect namespace was present in the code generated by Axis. I fixed the namespace to reflect what it should have been and everything worked fine. I can see people still answering this question so thought I would re-post my solution here (have already posted this in response to Kenster's solution). As none of the solutions posted before me finding the solution worked, I did not accept any answer.
Look into your .xsd file. Sort your xs elements alphabetically below your <xs:extension base=...>. That will fit your needs.
When I checked the axis code, i found the following
if( new javax.xml.namespace.QName("http://someurl","someElementName").equals(reader.getName()) )
this is where error happens,
. equals() method of QName checks for localPart & namespaceURI
. but reader.getName() has no namespace URI set and hence the error happend
I changed all the if-check from
if( new javax.xml.namespace.QName("http://someurl","someElementName").equals(reader.getName()) )
to
if( new javax.xml.namespace.QName("someElementName").equals(reader.getName()) )
and it worked fine for me
This error can be kind of misleading. After I modified the WSDL and added a new mandatory element, I created my client. Than this error appeared. The solution was, that I forgot to fill this element in one method of the my web service. If this error appears, also check if your mandatory elements are filled within the server.
in my case the Web Service is sending elements in different order than the sequence that is on the xsd. I am modifying the stub right now so order does not matter, because I have no chance of altering the Web Service.
I had the same problem. When the base64binary overcame 16k limit the parser starts giving the error, Substantially it stops reading the content after 16k so obviously the rest of the document seems corrupted.
My problem was that i was using com.sun.xml.stream.XMLReaderImpl.
Removing
<dependency>
<groupId>com.sun.xml.stream</groupId>
<artifactId>sjsxp</artifactId>
</dependency>
and adding
<dependency>
<groupId>org.codehaus.woodstox</groupId>
<artifactId>wstx-asl</artifactId>
</dependency>
solved my problem (so wstx as suggested before was working)
This describes a problem I had and the solution found, which I did not see discussed elsewhere (except the Background material).
Background – What Should Work (but May Not)
Let’s assume a web service defined by “https://mysite.com/?wsdl”, whose functions are to be called by a Windows client “myclient.exe”. In Visual Studio, you provide a “Service Reference” (The problem described here also manifests with the older-style “Web Reference”.)
Suppose you have more than 1 machine (mysite and mysite2) exposing the same web services. It is desirable to just change the client’s choice of endpoint at runtime to point to the correct machine, without having to update the Service Reference. This could be done in 3 ways:
Edit the deployed myclient.exe.config (or its source at compile time in VS, app.config), in particular:
<system.serviceModel>
...
<client>
<endpoint address="https://mysite2.com/?wsdl" …/>
</client>
</system.serviceModel>
Arrange your client code so that it reads in or selects the endpoint address, and sets it in the constructor (where “MyWebService” is the name of the Service Reference, and MyWebServiceBinding is defined in app.config), e.g. in C#:
public static EndpointAddress remoteAddress =
new EndpointAddress("https://mysite2.com/?wsdl");
public static BasicHttpBinding basicBinding =
new BasicHttpBinding("MyWebServiceBinding"); //Your binding type may differ
public MyWebService.myWebServicePortTypeClient mws =
new MyWebService.myWebServicePortTypeClient(basicBinding, remoteAddress);
Do like (2), but instead of in the constructor, set the endpoint later, say, during the first call to the service:
private void SetMyEndpointAddress(MyWebService.myWebServicePortTypeClient mws)
{
mws.Endpoint.Address = new
System.ServiceModel.EndpointAddress("https://mysite2.com/?wsdl");
}
All of these can still quietly fail if the specifics of the service WSDL are problematic (probably not generated in a routine manner by a MS server; PHP NuSoap in my case). Assuming you have control over the server WSDL, the next section explains what to look for.
Removing Unnecessary URLs from the WSDL
The WSDL is a long document with overall structure shown next. If any of the phrases pointed to here by "<===" contains a URL (e.g., https://mysite.com/...), change its generation process so that this is no longer true.
<definitions ...
xmlns:tns="soap/MyWebServices" <===
...
targetNamespace="soap/MyWebServices"> <===
<types>
<xsd:schema elementFormDefault="qualified"
targetNamespace="soap/MyWebServices"> <===
...
</xsd:schema>
</types>
[multiple <message>...</message> sections, ones for each defined function.]
<portType name="myWebServicesPortType">...</portType>
<binding name="MyWebServicesBinding" type="tns:myWebServicesPortType">...</binding>
<service name="MyWebServices">...</service>
</definitions>
In addition, within the <binding>…</binding> section, the “soapAction” for each function should be only the function name. It should not include a URL prefix (followed by “#” and the function). Typical function:
<operation name="getMyData">
<soap:operation
soapAction="getMyData" <===
style="document"/>
<input><soap:body use="literal" namespace=""/></input>
<output><soap:body use="literal" namespace=""/></output>
</operation>
The ONLY place where a URL to the particular machine should appear is in the <service> section:
<service name="MyWebServices">
<port name="MyWebServicesPort" binding="tns:MyWebServicesBinding">
<soap:address location="https://mysite.com/?wsdl"/>
</port>
</service>