SugarCRM, WSDL and RPC - java

There are many url for SugarCRM CE Web Service API like:
http://localhost/soap.php?wsdl
AND
http://localhost/service/v2/soap.php?wsdl
http://localhost/service/v3/soap.php?wsdl
http://localhost/service/v4/soap.php?wsdl
http://localhost/service/v4_1/soap.php?wsdl
They all produce WSDL for RPC/Encoded
When I consume the WSDL using wscompile Java tool with command line
wscompile -gen:client config.xml -keep
and config.xml contains
<?xml version="1.0" encoding="UTF-8"?>
<configuration
xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/config">
<wsdl location="http://localhost/service/v4_1/soap.php?wsdl" packageName="com.crm.imported"/>
</configuration>
I could get the generated classes.
But all the URLs have different structure in the generated classes.
Moreover, only the classes generated by http://localhost/soap.php?wsdl is working and the rest of them give error:
java.rmi.RemoteException: Runtime exception; nested exception is:
unexpected element type: expected={http://www.w3.org/2001/XMLSchema}QName, actual={http://www.w3.org/2001/XMLSchema}int
My Questions:
What is the difference in the API versions?
What is this XMLSchema QName error? How to solve it.

I got the answers:
All the API version have different implementations.
For example: Later versions expect password to be MD5 coded.
XMLSchema Error is raised by providing wrong information to the parameters.
java.rmi.RemoteException will simply give the error message irrelevantly.

Related

InaccessibleWSDLException error from SOAP generated client in JAVA

We are working with service provider's wsdl which is not discoverable due to security reason and they provide us a bunch of files including wsdl ,xsd etc.We need to access the provider's api. For these reason we have done these following things:
We have generated a web service client using netbean 8.0 form desktop location (Local File )
Using generated client code we have called the api using these following code
URL url = new URL("http://serverip:port/payment/services/MgrService");
MgrService svc = new MgrService(url);
Response response = svc.getMgrServicePort().apiRequest(request);
but getting these exception
com.sun.xml.internal.ws.wsdl.parser.InaccessibleWSDLException: 2 counts of InaccessibleWSDLException.
java.io.IOException: Server returned HTTP response code: 500 for URL: http://serviceip:port/payment/services/MgrService
java.io.IOException: Server returned HTTP response code: 500 for URL: http://serviceip:port/payment/services/MgrService?wsdl
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.tryWithMex(RuntimeWSDLParser.java:260)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:231)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:194)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:163)
at com.sun.xml.internal.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:348)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:306)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:215)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:196)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:192)
at com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)
at javax.xml.ws.Service.<init>(Service.java:77)
By Wireshark, we have noticed that it is calling a get method with no soap body, where it should call only post method . We have tested the api using soapUI , service is ok . We also getting successful response using raw xml soap request.
Is it possible to work with generated client both for JAX-WS and Spring WS when WSDL is not discoverable ? or it only work with JAX-WS's wsdl file.
If so then do we need to edit wsdl? or some other approach
After few research, I have found these !
1)For Spring WS, generated client is not working (As like Netbean Generated SOAP client)
2) This link help me a lot to consume a Spring-WS service using Spring STS
Consuming a SOAP web service
but few things need to be done before you proceed
a) fix maven-jaxb2-plugin version to lower version (0.12.1)
b) add a binding.xjb file with these contains
<?xml version="1.0"?>
<jxb:bindings version="1.0" xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
xmlns:xjc= "http://java.sun.com/xml/ns/jaxb/xjc"
jxb:extensionBindingPrefixes="xjc" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<jxb:bindings>
<jxb:globalBindings>
<xjc:simple/>
</jxb:globalBindings>
</jxb:bindings>
</jxb:bindings>
other wise xjc will not work
3) Copy wsdl & xsd files to local project directory and pom configuration will
be as follows (for scenario where wsdl is not hosted for security reason)
<configuration>
<schemaDirectory>${project.basedir}/src/main/resources/wsdl</schemaDirectory>
<schemaIncludes>
<include>*.wsdl</include>
</schemaIncludes>
</configuration>
3)It is not recommended to edit the wsdl file

How to add Authentication Header to WebService Stub?

I have generated stubs using Apache CXF, IBM Jax-WS and Axis as well in Eclipse and RAD 7.0 .
In all the 3 above scenarios it gives me the following exception
Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: ARERR [149] A user name must be supplied in the control record
After searching i concluded that i have to add Authentication Info to the Soap header created by Client Stubs.
i tried the answer on this link
How do you add a Soap Header defined in a wsdl to a web service client in CXF?
but couldn't succeed. I am newbie to SOAP and WebServices
So if anyone has worked on it kindly Help.
I had this problem a few days ago and it was a headache for me. When generating the stubs you have to add a the flag -XadditionalHeaders to the wsimport command.
"C:\Program Files\Java\jdk1.X.X_XX\bin\wsimport.exe" -p com.company.package -keep -XadditionalHeaders -d folder1 http://mywsdllocation.com/doc.wsdl
Where:
-p: package that will contain generated classes
-keep: keep .java files (otherwise tou'll only get .class files)
-XadditionalHeaders: classes for authentication will be created
-d: Folder where generated classes will be placed.
After that, you only have to copy generated java files to your project, under the picked package (com.company.package in this case). Then you have you create an AuthenticationInfo object and inserting it in the stub method's call, something like this:
WSService service = new WSService();
WSPortTypePortType port = service.WSPortTypeSoap();
AuthenticationInfo auth = new AuthenticationInfo();
auth.setUserName(yourUsername);
auth.setPassword(yourPassword);
port.method(param1,param2,auth);
Hope it helps!

JAXBException caused by generated code

I am getting the following JAXBException of the form
class SomeClass nor any of its super class is known to this context.
The full stack trace looks like this:
javax.xml.ws.WebServiceException: javax.xml.bind.JAXBException: class com.myCompany.generatedCode.WebServiceOperationName nor any of its super class is known to this context.
at org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:175)
at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:70)
at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:128)
at org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.execute(AxisInvocationController.java:586)
at org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.doInvoke(AxisInvocationController.java:130)
at org.apache.axis2.jaxws.core.controller.impl.InvocationControllerImpl.invoke(InvocationControllerImpl.java:93)
at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invokeSEIMethod(JAXWSProxyHandler.java:364)
at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invoke(JAXWSProxyHandler.java:185)
at $Proxy41.deleteAccount(Unknown Source)
at com.myCompany.myPackage.MyWebServiceClient.callSomeWebService(MyWebServiceClient.java:100)
(other classes specific to my application and framework)
...
Caused by:
javax.xml.bind.JAXBException: class com.myCompany.generatedCode.WebServiceOperationName nor any of its super class is known to this context.
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImpl.java:556)
at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:452)
at com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:314)
at com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:243)
at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:75)
at com.ibm.xml.xlxp2.jaxb.marshal.MarshallerProxy.marshal(MarshallerProxy.java:100)
at org.apache.axis2.datasource.jaxb.JAXBDSContext$1.run(JAXBDSContext.java:470)
at org.apache.axis2.java.security.AccessController.doPrivileged(AccessController.java:76)
at org.apache.axis2.datasource.jaxb.JAXBDSContext.marshalByElement(JAXBDSContext.java:455)
at org.apache.axis2.datasource.jaxb.JAXBDSContext.marshal(JAXBDSContext.java:414)
at org.apache.axis2.jaxws.message.databinding.impl.JAXBBlockImpl._outputFromBO(JAXBBlockImpl.java:189)
at org.apache.axis2.jaxws.message.impl.BlockImpl.outputTo(BlockImpl.java:372)
at org.apache.axis2.jaxws.message.impl.BlockImpl.serialize(BlockImpl.java:296)
at org.apache.axiom.om.impl.llom.OMSourcedElementImpl.internalSerializeAndConsume(OMSourcedElementImpl.java:808)
at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:975)
at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:1016)
at org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.serializeInternally(SOAPEnvelopeImpl.java:271)
at org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.internalSerialize(SOAPEnvelopeImpl.java:233)
at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:1016)
at org.apache.axiom.om.impl.llom.OMNodeImpl.serializeAndConsume(OMNodeImpl.java:488)
at org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:88)
at com.ibm.ws.websvcs.transport.http.SOAPOverHTTPSender.writeMessage(SOAPOverHTTPSender.java:3271)
at com.ibm.ws.websvcs.transport.http.SOAPOverHTTPSender.sendChunkedRequest(SOAPOverHTTPSender.java:888)
at com.ibm.ws.websvcs.transport.http.SOAPOverHTTPSender.sendSOAPRequest(SOAPOverHTTPSender.java:807)
at com.ibm.ws.websvcs.transport.http.SOAPOverHTTPSender.send(SOAPOverHTTPSender.java:611)
at com.ibm.ws.websvcs.transport.http.HTTPTransportSender.invoke(HTTPTransportSender.java:364)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:531)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:401)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:228)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
at org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.execute(AxisInvocationController.java:581)
... 52 more
What triggers this is attempting to make a call to a web service operation named WebServiceOperationName. I've seen other tips for dealing with this error which usually involve adding a #XmlSeeAlso annotation or making adjustments to how marshalling and unmarshalling are done.
In this case, I am calling a webservice whose code is generated by Maven based on a WSDL (and supporting schemas). I don't have direct control over the code produced by Maven, and I don't have control over the marshall/unmarshall calls. Other webservice calls in the application don't seem to be having any problem.
Even stranger, I can't reproduce this on my local server, though it happens on the development server. The generated JAR for the webservice is the same, as it the rest of the application's code.
This exception has appeared suddenly this week (and consistently), and I suspect that something has changed, environmentally, but I'm not sure what. Any ideas?
A new observation:
The first time I attempt to run this code on the server after it's been started/restarted, it takes a while (About a minute) before it fails and throws an exception. Every time after that, the exception is almost instantaneous...
Further information:
This problem is present in WebSphere 7.0.0.23 (which is on the server), but not in WebSphere 7.0.0.7 (on the workstation).
The issue's been resolved. I was inspecting the jar that contained the class WAS was complaining about and noticed that some of the classes were duplicated at different levels of package hierarchy. It's worth pointing out that the class that was reported in the original error was not actually one of these duplicated classes. Also, the application did not reference different variants of the same class - the classes referenced were in the expected package. The extra duplicates one level up were not referenced anywhere (as far as I can tell).
It looked like a bad Maven configuration, but when I inspected the xjb binding files, I couldn't figure out how the types in that schema namespace got bound to two different packages. Either way, I cleanded up some of the binding files used by Maven, refactored common bindings into one file, had Maven rebuild the jar, and then tested, and suddenly the issue was gone!
Clearly there was a problem in WAS 7.0.0.23 since the original jar worked fine on WAS 7.0.0.7. It may have been caused by a problem with the Maven bindings which resulted in a strange-looking but technically valid jar.
Also interesting: one of our developers upgraded WAS to 7.0.0.25 and used the original "bad" jar and got a "no such operation" error instead of the JAXBException.
I have the same problem in Guidewire ClaimCenter, which is an insurance application that can be configured but the core can't be modified at all, It's Java based it has component included like axis2 but I created a seperate java project that wraps a webservice call, I created all the stub code with wsimport. It works well under my deve enviroment which is windows and jetty because is the Guidewire platform to configure it (no other option). we use WAS 7 as production server.
Caused by: javax.xml.ws.WebServiceException: javax.xml.bind.JAXBException: au.com.mycompany.policyinquiry.retrieveinsurancepolicydetails.v1.RetrieveInsurancePolicyDetailsResp is not known to this context
at org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:175)
at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:70)
at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:128)
at org.apache.axis2.jaxws.marshaller.impl.alt.DocLitBareMinimalMethodMarshaller.demarshalResponse(DocLitBareMinimalMethodMarshaller.java:158)
at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.createResponse(JAXWSProxyHandler.java:499)
at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invokeSEIMethod(JAXWSProxyHandler.java:377)
at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invoke(JAXWSProxyHandler.java:185)
at $Proxy80.retrieveInsurancePolicyDetails(Unknown Source)
I tried to generate and compile the client in the server side just in case it was something related with different JDK platform, but that didn't solve the problem.
I found the next article was 6!
but for WAS 6 , I haven't tried though.
When the JAX-WS web service engine receives a message, it uses
the JAXB engine to convert the message into java beans.
The message indicates a failure occurred while converting xml
into an object of type
com.somecom.lib.business.xml.ComIdentifierXml. The failure
indicates that the JAXB engine was not initialized with
information about this user class.
.
In this use case, the class
com.somecom.lib.business.xml.ComIdentifierXml is packaged in a
JAR at the EAR level. The exception does not happen if the
class is packaged in a JAR located in the WAR module's
WEB-INF/lib directory.
SOLUTION:
Target Environment:
IBM server
IBM JDK 1.6
IBM Webpshere 7.0.0.25
The client to call the webservice is using pure JAVA no dependency on external library JAX-WS RI 2.1.6
In webspehre
1- Set for the application the class loading to parent last
2- Turn off webservice annotations with this: Set the com.ibm.websphere.webservices.DisableIBMJAXWSEngine property to true. this will disabled Websphere own implementation based on a modified Axis2
3- Deploy your application with third-party JAX-WS runtime
in my case i used Glassfish Metro 1.5 which includes JAX-WS RI 2.1.7 and is the same as my local environment with JDK 1.6.0_37
That's it
Cheers
Alex :)

axis wsdl2java fails reading schema with special characters

I'm trying to generate a Java Client with the axis using wsdl2java (wrapped by the maven axistools).
I downloaded the wsdl and the corresponding schema.
The wsdl has the following schema definitions:
<wsdl:types>
<xsd:schema
targetNamespace="http://example.com/CM_IntegrationService/"
xmlns:pref="http://example.com/CM_IntegrationService"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:import namespace="http://example.com//CM_IntegrationService"
schemaLocation="CM_IntegrationService?xsd=ServiceModel_CM_IntegrationService.xsd"/>
In short:
schemaLocation="CM_IntegrationService?xsd=ServiceModel_CM_IntegrationService.xsd"
The error shows as:
[ERROR] Failed to execute goal org.codehaus.mojo:axistools-maven-plugin:1.4:wsdl2java
(default) on project wsclient-cm: Error generating Java code from WSDL. error running
file:/C:/workspace/ws/wsclient-reactor/wsclient-wsdl/src/main/wsdl/CM_IntegrationService.wsdl:
WSDLException (at /wsdl:definitions/wsdl:types/xsd:schema): faultCode=OTHER_ERROR:
An error occurred trying to resolve schema referenced
at 'CM_IntegrationService?xsd=ServiceModel_CM_IntegrationService.xsd', relative to
'file:/C:/workspace/ws/wsclient-reactor/shop-wsclient-wsdl/src/main/wsdl/CM_IntegrationService.wsdl'.:
This file was not found:
file:/C:/workspace/ws/wsclient-reactor/wsclient-wsdl/src/main/wsdl/CM_IntegrationService?xsd=ServiceModel_CM_IntegrationService.xsd -> [Help 1]
In short file not found for:
/C:/workspace/ws/wsclient-reactor/wsclient-wsdl/src/main/wsdl/CM_IntegrationService?xsd=ServiceModel_CM_IntegrationService.xsd
Is there a way to specify which schema to use? I saved the schema as ServiceModel_CM_IntegrationService.xsd. However its searching for the full path including = and ? which I cannot emulate on the file system.
I don't want to modify the wsdl as suggested in: WSDL to Java -client creation error
Why is axistools-maven-plugin trying to access this relative schema location? looks similar however using the useEmitter=true option didn't help.
This is currently not possible without modifying the WSDL. Doing this without modifying the WSDL (BTW, why don't you want to do that?) would require support for XML catalogs, as described in AXIS-1984.

XMLBeans - xsi:type stripped using Axis2 and Tomcat?

I’m new to XMLBeans and have been trying to use it to create an XML document as part of an axis2 web service. When I run my code as a standard Java application or as a standard servlet, the XML is correctly generated:
<?xml version="1.0" encoding="UTF-8"?>
<c:BroadsoftDocument protocol="OCI" xmlns:c="C">
<sessionId>000000001</sessionId>
<command xsi:type="AuthenticationRequest" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<userId>admin</userId></command>
</c:BroadsoftDocument>
However, when the exact same code is run under Axis2 & Tomcat in a servlet I get:
<?xml version="1.0" encoding="UTF-8"?>
<c:BroadsoftDocument protocol="OCI" xmlns:c="C">
<sessionId>000000001</sessionId>
<command>
<userId>admin</userId></command>
</c:BroadsoftDocument>
This of course isn’t valid – the xsi:type of the “command” element is stripped when the code is run under Tomcat.
Does anyone have any suggestions of what I could be doing wrong that would cause this type of issue only when running under Axis2? At first I thought it was a Tomcat issue, but after creating a generic servlet and running the exact same code I don't have any issues. I've tried playing with the XMLOptions for XMLBeans, but couldn't seem to resolve the problem. The options I'm currently using are:
xmlOptions = new XmlOptions();
xmlOptions.setCharacterEncoding("UTF-8");
xmlOptions.setUseDefaultNamespace();
xmlOptions.setSaveAggressiveNamespaces();
xmlOptions.setSavePrettyPrint();
It turn out the issue is with the class loader order that Axis2 uses. This was patched and the functionality is described here:
http://marc2.theaimsgroup.com/?l=axis-cvs&m=115946726426905&w=3
Long story short, to resolve this issue you need to edit the "services.xml" for your Axis2 project and add:
<parameter name="ServiceTCCL">composite</parameter>

Categories