I have tried automated importing of AP Invoices by using the ERP Integration Service from SOAPUI, but I am getting the 'FailedCheck' error whenever I am running a request. I have filled the necessary information, such as the base64 encoding of the CSVs.
Sample SOAP Code Request & Received Response
I have also filled in my username and password in the Outgoing WS-Security Configuration, which I have provided by double-clicking the project name.
Proof of credentials needed inserted
I also obtained a security certificate by obtaining the one used by the web service WSDL, then creating a keystore from it by the use of the tool 'keytool' from JDK. Then I used it as the keystore of my project.
Proof of keystore applied
Which I placed the necessary info for outgoing encryption.
Proof of encryption using keystore
After the steps, I run the request, to which I received the 'FailedCheck' error (see first image). Image below is the log that I received when I encounter the said error.
SoapUi log
And here is the error log:
Tue Nov 07 18:56:36 CST 2017:ERROR:java.util.zip.ZipException: Not in GZIP format
java.util.zip.ZipException: Not in GZIP format
at java.util.zip.GZIPInputStream.readHeader(Unknown Source)
at java.util.zip.GZIPInputStream.<init>(Unknown Source)
at java.util.zip.GZIPInputStream.<init>(Unknown Source)
at org.apache.http.client.entity.GzipDecompressingEntity.getContent(GzipDecompressingEntity.java:63)
at com.eviware.soapui.impl.wsdl.support.CompressionSupport.decompress(CompressionSupport.java:87)
at com.eviware.soapui.impl.wsdl.submit.transports.http.support.attachments.PostResponseDataSource.<init>(PostResponseDataSource.java:51)
at com.eviware.soapui.impl.wsdl.submit.transports.http.support.attachments.MimeMessageResponse.<init>(MimeMessageResponse.java:55)
at com.eviware.soapui.impl.wsdl.submit.transports.http.support.attachments.WsdlMimeMessageResponse.<init>(WsdlMimeMessageResponse.java:57)
at com.eviware.soapui.impl.wsdl.submit.filters.HttpPackagingResponseFilter.wsdlRequest(HttpPackagingResponseFilter.java:68)
at com.eviware.soapui.impl.wsdl.submit.filters.HttpPackagingResponseFilter.afterAbstractHttpResponse(HttpPackagingResponseFilter.java:49)
at com.eviware.soapui.impl.wsdl.submit.filters.AbstractRequestFilter.afterRequest(AbstractRequestFilter.java:64)
at com.eviware.soapui.impl.wsdl.submit.transports.http.HttpClientRequestTransport.sendRequest(HttpClientRequestTransport.java:272)
at com.eviware.soapui.impl.wsdl.WsdlSubmit.run(WsdlSubmit.java:119)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
I have also tried running a request without using keystores, but I am getting an authentication error as a response. I am a beginner in this, so any help would be appreciated.
i am trying to implement a webclient for a secure https connection. I imported the server certificates and added it to java keystore. but when i try to run the client i got the following exceptions:--
Oct 18, 2013 3:25:25 PM org.apache.cxf.phase.PhaseInterceptorChain doDefaultLogging WARNING: Interceptor for
{http://tempuri.org/}Service#{http://tempuri.org/}GetUserInformation has thrown exception,
unwinding now org.apache.cxf.interceptor.Fault: Could not send Message.
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:565)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:474)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:377)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:330)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
at $Proxy29.getUserInformation(Unknown Source)
at
org.tempuri.ServiceSoap_ServiceSoap_Client.main(ServiceSoap_ServiceSoap_Client.java:78)
Caused by: java.io.IOException: IOException invoking
myurl/**/**/asmx: The https URL hostname does not
match the Common Name (CN) on the server certificate in the client's truststore. Make sure
server certificate is correct, or to disable this check (NOT recommended for production) set the CXF client TLS configuration property "disableCNCheck" to true.
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1338)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1322)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:627)
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
... 9 more
Caused by: java.io.IOException: The https URL hostname does not match the Common Name (CN)
on the server certificate in the client's truststore. Make sure server certificate is
correct, or to disable this check (NOT recommended for production) set the CXF client TLS
configuration property "disableCNCheck" to true.
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.onFirstWrite(HTTPConduit.java:1241) at
org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.onFirstWrite(URLConnectionHTTPConduit.java:195)
at
org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:47)
at
org.apache.cxf.io.AbstractThresholdOutputStream.write(AbstractThresholdOutputStream.java:69) at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1295)
... 12 more
Exception in thread "main" javax.xml.ws.WebServiceException: Could not send Message.
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146)
at $Proxy29.getUserInformation(Unknown Source)
at
org.tempuri.ServiceSoap_ServiceSoap_Client.main(ServiceSoap_ServiceSoap_Client.java:78)
Caused by: java.io.IOException: IOException invoking
myurl/**/**/asmx: The https URL hostname does not
match the Common Name (CN) on the server certificate in the client's truststore. Make sure
server certificate is correct, or to disable this check (NOT recommended for production) set
the CXF client TLS configuration property "disableCNCheck" to true.
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1338)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1322)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:627)
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:565)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:474)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:377)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:330)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
... 2 more
Caused by: java.io.IOException: The https URL hostname does not match the Common Name (CN)
on the server certificate in the client's truststore. Make sure server certificate is
correct, or to disable this check (NOT recommended for production) set the CXF client TLS
configuration property "disableCNCheck" to true.
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.onFirstWrite(HTTPConduit.java:1241)
at
org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.onFirstWrite(URLConnectionHTTPConduit.java:195)
at
org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:47)
at
org.apache.cxf.io.AbstractThresholdOutputStream.write(AbstractThresholdOutputStream.java:69) at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1295)
Can someone help me with this. Thanks in advance...
Depending on the type of CXF client you have to options. If you have Spring-based client configuration you have to add attribute to your http:conduit configuration:
<http:conduit name="{http://apache.org/hello_world_soap_http}SoapPort.http-conduit">
<http:tlsClientParameters disableCNCheck="true">
<!-- other tls configuration parameters, like trustManagers -->
</http:tlsClientParameters>
</http:conduit>
name has to match namespace and port name from your WSDL.
If you create your client programmaticaly then use the following code:
HTTPConduit httpConduit = (HTTPConduit) ClientProxy.getClient(port).getConduit();
TLSClientParameters tlsCP = new TLSClientParameters();
// other TLS/SSL configuration like setting up TrustManagers
tlsCP.setDisableCNCheck(true);
httpConduit.setTlsClientParameters(tlsCP);
where port is actual client proxy that you call.
Both options can be found working in CXF example that I modified here
BTW. There is a real threat in using this property on production environment, so please consider issuing new certificate with correct CN for production server instead of depending on this hack.
I need to connect to a .net application via it's SOAP Web Service but can't get it working from Domino. Using XPages I want to connect to the web service to return data to the xpage. I tried creating an agent to make the call, but that hasn't worked. I receive the following java StackTrace when I run the agent:
WebServiceEngineFault
faultCode: {http://www.lotus.com/domino/ws/}HTTP
faultSubcode:
faultString: (401) Unauthorized
faultActor:
faultNode:
faultDetail:
{}string:
(401) Unauthorized
at lotus.domino.axis.transport.http.HTTPSender.readFromSocket(Unknown Source)
at lotus.domino.axis.transport.http.HTTPSender.invoke(Unknown Source)
at lotus.domino.axis.strategies.InvocationStrategy.visit(Unknown Source)
at lotus.domino.axis.SimpleChain.doVisiting(Unknown Source)
at lotus.domino.axis.SimpleChain.invoke(Unknown Source)
at lotus.domino.axis.client.AxisClient.invoke(Unknown Source)
at lotus.domino.axis.client.Call.invokeEngine(Unknown Source)
at lotus.domino.axis.client.Call.invoke(Unknown Source)
at lotus.domino.axis.client.Call.invoke(Unknown Source)
at lotus.domino.axis.client.Call.invoke(Unknown Source)
at lotus.domino.axis.client.Call.invoke(Unknown Source)
at lotus.domino.websvc.client.Call.invoke(Unknown Source)
at com.imanage.worksite.IWOVServicesSoapStub.getFolders(Unknown Source)
at JavaAgent.NotesMain(Unknown Source)
at lotus.domino.AgentBase.runNotes(Unknown Source)
at lotus.domino.NotesThread.run(Unknown Source)
I am able to call it successfully from soapUI passing in the user id, password and domain credentials.
I set credentials in the agent that consumes the web service:
String arg0 = "DOMAINNAME\\USERID";
String arg1 = "PASSWORD";
stub.setCredentials(arg0, arg1);
and also in the web service consumer itself (in the SoapStub class - within the getFolders call):
_call.setUsername("DOMAINNAME\\USERID");
_call.setPassword("PASSWORD");
I'm new to XPages and Java. Does anyone have any ideas what I might be missing or should check for?
(I can't use Lotusscript for the web service consumer as the variable names generated by the WSDL are too long, so I have to use java in this case).
In these situations to help narrow down it is better to let SOAPUI do the full testing.
So do the following.
Create a mock service in SOAPUI from the WSDL of the provider.
Point your agent to the mock service so that you can capture what is being sent from your agent. (ie. Capture the SOAP request).
Using that same SOAP request send it via SOAPUI to the .NET server. It should reproduce the issue and give you back some more information as to what is failing.
The following wiki article explains how to do this.
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/Testing_your_Domino_web_service_provider_and_consumer_using_SoapUI._
I would use CXF, it seems better supported in XPages. What authentication are you using? I found that a digest authentication might not work with some services in .net (Sharepoint data being one) and you need to call another end-point to get a digest token. I use TCPMon (Cross platform) or Fiddler to see what is on the wire (You configure these tools as proxy, so you can watch) AD107 might have additional information, have a look.
I have tested my web services (wsdl/soap) with soapui. and i have the errors :
http/log : error 400 BAD REQUEST.
What can be the error please with my wsdl ?
error/log :
un Jun 05 14:10:37 CEST 2011:ERROR:javax.wsdl.WSDLException: WSDLException (at /html): faultCode=INVALID_WSDL: Expected element '{http://schemas.xmlsoap.org/wsdl/}definitions'.
javax.wsdl.WSDLException: WSDLException (at /html): faultCode=INVALID_WSDL: Expected element '{http://schemas.xmlsoap.org/wsdl/}definitions'.
at com.ibm.wsdl.xml.WSDLReaderImpl.checkElementName(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseDefinitions(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.eviware.soapui.impl.wsdl.support.wsdl.WsdlInterfaceDefinition.load(WsdlInterfaceDefinition.java:48)
at com.eviware.soapui.impl.wsdl.support.wsdl.WsdlContext.loadDefinition(WsdlContext.java:66)
at com.eviware.soapui.impl.wsdl.support.wsdl.WsdlContext.loadDefinition(WsdlContext.java:30)
at com.eviware.soapui.impl.support.definition.support.AbstractDefinitionContext.cacheDefinition(AbstractDefinitionContext.java:264)
at com.eviware.soapui.impl.support.definition.support.AbstractDefinitionContext.access$400(AbstractDefinitionContext.java:44)
at com.eviware.soapui.impl.support.definition.support.AbstractDefinitionContext$Loader.construct(AbstractDefinitionContext.java:230)
at com.eviware.soapui.support.swing.SwingWorkerDelegator.construct(SwingWorkerDelegator.java:46)
at com.eviware.soapui.support.swing.SwingWorker$2.run(SwingWorker.java:140)
at java.lang.Thread.run(Thread.java:637)
definitions is a root element of WSDL so it looks like you are not loading WSDL.
Edit:
I tested it and it looks like the whole problem is with your web server. Your web server returns WSDL to browser but it doesn't return it to any tool because these tools are using very minimalistic HTTP requests without many HTTP headers. One of missing headers is Accept. Once this header is not included in the request your server throws HTTP 400 Bad request.
The easy approach to continue is opening WSDL in the browser, save the wsdl to a file and import that file to soapUI instead of the WSDL from URL.
Another possibility is that you need to add ?wsdl at the end of your service url for SoapUI.
That one got me as I'm used to WCFClient which didn't need it.
You can try opening the wsdl in web browser and saving with .wsdl extension. And set the WSDL in SOAP UI project to this .wsdl file.
This really works.
yes, first ensure you added "?wsdl" to your "http......whatever.svc" link.
That didn't fix my problem, though. I had to create a new WCF project from the beginning and manually copy the code. That fixed it. Good luck.
And most important!!!
When you change a namespace in your code, also make sure you change it in web.config!
I faced the same exception while trying to test my web-services deployed to WSO2 ESB.
WSO2 generated both wsdl and wsdl2. I tried to pass a wsdl2 URL and got the above exception. Quick googling showed me, that one of differences between wsdl1.1 and wsdl2.0 is replacing 'definitions' element with 'description'. Also, I found out, that SoapUI does not support wsdl2.
Therefore, for me the solution was to use wsdl1 url instead of wsdl2.
A likely possibility is that your browser reaches your web service through a proxy, and SoapUI is not configured to use that proxy. For example, I work in a corporate environment and while my IE and FireFox can access external websites, my SoapUI can only access internal web services.
The easy solution is to just open the WSDL in a browser, save it to a .xml file, and base your SoapUI project on that. This won't work if your WSDL relies on external XSDs that it can't get to, however.
For anyone hitting this issue in the future: the specific situation here ("the server isn't sending back the WSDL properly") may or may not always be relevant, but two key aspects should always be:
The message faultCode=INVALID_WSDL: Expected element '{http://schemas.xmlsoap.org/wsdl/}definitions' means that the actual content returned is not XML with a base element of "definitions" in the WSDL namespace.
The message WSDLException (at /html) tells you an important clue about what it did find — for this example, /html strongly implies that a normal webpage was returned, rather than a WSDL. Another common situation is seeing something like /soapenv:Reason, which would indicate that the server was trying to treat it as a SOAP call — for example, this can happen if your URL is for the "base" service URL rather than the WSDL.
I had the same problem, and the solution (for me) was to:
open SoapUI Preferences
click on SSL Settings
clear out the KeyStore and KeyStore Password text boxes
untick the bottom checkbox for Client Authentication, requires client authentication.
On AspNet services with .svc endding you must terminate URL as "?wsdl".
Otherwise, SoapUI will try to read the land page HTML of the Service (that is not a WSDL, right?)
Eg.:
http://localhost:1234/WebServices/WsBlahBlahBlah.svc?wsdl
i currently have a webservice deployed on a weblogic 10.3 server whit 1-way ssl enabled, the problem is that wen i test the webservice using the weblogic's test page, i get this error:
avax.net.ssl.SSLException: Handshake has been interrupted, can't find trusted CA certificates file trusted-ca.pem
but all the client applications are not having problem using the service over https (they are allready configured tho thrust the server cert), i dig on the weblogic's log and found this stack trace:
at com.certicom.net.ssl.HttpsClient.doConnect(Unknown Source)
at com.certicom.net.ssl.internal.NetworkClient.openServer(Unknown Source)
at com.certicom.net.ssl.internal.HttpClient.openServer(Unknown Source)
at com.certicom.net.ssl.HttpsClient.<init>(Unknown Source)
at com.certicom.net.ssl.HttpsURLConnection.connect(Unknown Source)
at com.certicom.net.ssl.internal.HttpURLConnection.getInputStream(Unknown Source)
(this is an extract of the whole stack trace) for what i see, is that the test page interally uses the certicom ssl implementation to make the requests and it is not using the weblogic's SSL configuration, so how can i get the test page working whit ssl enabled?, is there any way to get certicom ssl implementation to use the weblogic's ssl settings?
thank you for your time
Did you follow the steps described in Testing a Secure WebLogic Web Service From Its Home Page?