SOAP issue when running DIL Test

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

SOAP issue when running DIL Test

earla12
Good Afternoon,

   When running the DIL Test PRL-R-0000.0-2011 I am receiving an error regarding SOAP throwing an exception.

   Could someone please help me trouble-shoot the issue.

I have attached my Server log file to aid in the analysis

server.log

Thanks,

Earl
Sai
Reply | Threaded
Open this post in threaded view
|

Re: SOAP issue when running DIL Test

Sai
You have certificates issue. Please check the certificates you imported and rerun the tests. Below is the message and also CONNECTION REFUSED is what I see in the logs.

2018-02-21 16:16:40,832 WARN  [gov.hhs.fha.nhinc.callback.cxf.CONNECTSamlAssertionValidator] (default task-1) Could not establish trust of the signature's public key because no matching public key exists in the truststore. Please see GATEWAY-3146 for more details.

Thanks,
Sai


On Wed, Feb 21, 2018 at 4:18 PM, earla12 [via CONNECT Community Forum] <[hidden email]> wrote:
Good Afternoon,

   When running the DIL Test PRL-R-0000.0-2011 I am receiving an error regarding SOAP throwing an exception.

   Could someone please help me trouble-shoot the issue.

I have attached my Server log file to aid in the analysis

server.log

Thanks,

Earl


If you reply to this email, your message will be added to the discussion below:
http://forums.connectopensource.org/SOAP-issue-when-running-DIL-Test-tp7580901.html
To start a new topic under Technical Issues, email [hidden email]
To unsubscribe from CONNECT Community Forum, click here.
NAML

Thanks & regards,
Sai, Valluripalli
Reply | Threaded
Open this post in threaded view
|

Re: SOAP issue when running DIL Test

johnhd_at_zen
In reply to this post by earla12
I agree with Sai's impression.

Have you been able to run any DIL tests before this one?
Ask The Experts! Free 15 minute live Q&A sessions with one of Zen's Expert Integrators @ https://consultzen.com/integration-service-desk-solutions/

www.consultzen.com
Reply | Threaded
Open this post in threaded view
|

Re: SOAP issue when running DIL Test

earla12
Not with this install.....

I believe the step that introduced the issue was in reference to copying the cacerts.jks file.  I had copied the cacerts.jks file from my main configuration folder under WildFly.

This time when generating the certs, I did not copy 'any' instances of the 'cacerts.jks' file into my cert work directory for the creation process.

Will let you know how it turns out.

I want to thank everyone for the fast response to my questions.

Earl
Reply | Threaded
Open this post in threaded view
|

Re: SOAP issue when running DIL Test

earla12
No difference in results when I did not place a copy of 'cacerts.jks' in the DILWork folder when creating the new Certs.

Getting the same 'Connection Refused'.

The SOAPUI Validation test prior to attempting the DIL testing successfully validated.

Reviewing the configuration files related to the keystores.

Earl
Reply | Threaded
Open this post in threaded view
|

Re: SOAP issue when running DIL Test

johnhd_at_zen
Hi Earl,

SoapUI Validation makes use of the internal, unsecured endpoints, so they won't highlight any certificate issues.

Let me go over your logs again really quickly- would you mind posting the freshest ones here?- and I'll see if I can't pin down a narrower description of the problem and come up with a recommendation or two.

Thanks!
Ask The Experts! Free 15 minute live Q&A sessions with one of Zen's Expert Integrators @ https://consultzen.com/integration-service-desk-solutions/

www.consultzen.com
Reply | Threaded
Open this post in threaded view
|

Re: SOAP issue when running DIL Test

earla12
Hi John,

   Here are the latest logs......

server.log

Thanks again for your help

Earl
Reply | Threaded
Open this post in threaded view
|

Re: SOAP issue when running DIL Test

johnhd_at_zen
This post was updated on .
Ok. Here's the relevant stacktrace, which has some good info in it:

2018-02-22 13:55:34,805 WARN  [org.apache.cxf.phase.PhaseInterceptorChain] (default task-1) Interceptor for {urn:gov:hhs:fha:nhinc:adaptermpi}AdapterMpiSecuredPortTypeService#{urn:gov:hhs:fha:nhinc:adaptermpi}FindCandidates has thrown exception, unwinding now: org.apache.cxf.binding.soap.SoapFault: Connection refused: connect
	at org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:218) [cxf-rt-bindings-soap-2.7.3.jar:2.7.3]
	at org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:172) [cxf-rt-bindings-soap-2.7.3.jar:2.7.3]
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271) [cxf-api-2.7.3.jar:2.7.3]
	at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530) [cxf-api-2.7.3.jar:2.7.3]
	at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:463) [cxf-api-2.7.3.jar:2.7.3]
	at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:366) [cxf-api-2.7.3.jar:2.7.3]
	at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:319) [cxf-api-2.7.3.jar:2.7.3]
	at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) [cxf-rt-frontend-simple-2.7.3.jar:2.7.3]
	at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:133) [cxf-rt-frontend-jaxws-2.7.3.jar:2.7.3]
	at com.sun.proxy.$Proxy201.findCandidates(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_76]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_76]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_76]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_76]
	at gov.hhs.fha.nhinc.webserviceproxy.WebServiceProxyHelper.invokeTheMethod(WebServiceProxyHelper.java:271) [CONNECTCoreLib-4.6.0.jar:]
	at gov.hhs.fha.nhinc.webserviceproxy.WebServiceProxyHelper.invokePort(WebServiceProxyHelper.java:351) [CONNECTCoreLib-4.6.0.jar:]
	at gov.hhs.fha.nhinc.webserviceproxy.WebServiceProxyHelper.invokePortWithRetry(WebServiceProxyHelper.java:399) [CONNECTCoreLib-4.6.0.jar:]
	at gov.hhs.fha.nhinc.webserviceproxy.WebServiceProxyHelper.invokePort(WebServiceProxyHelper.java:325) [CONNECTCoreLib-4.6.0.jar:]
	at gov.hhs.fha.nhinc.messaging.client.CONNECTBaseClient.invokePort(CONNECTBaseClient.java:54) [CONNECTCoreLib-4.6.0.jar:]
	at gov.hhs.fha.nhinc.mpi.adapter.proxy.AdapterMpiProxyWebServiceSecuredImpl.findCandidates(AdapterMpiProxyWebServiceSecuredImpl.java:103) [PatientDiscoveryCore-4.6.0.jar:]
	at gov.hhs.fha.nhinc.mpi.adapter.proxy.AdapterMpiProxyWebServiceSecuredImpl$$FastClassByCGLIB$$1ff39dd0.invoke(<generated>) [cglib-nodep-2.2.jar:]
	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:191) [cglib-nodep-2.2.jar:]
	at org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:688) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.framework.adapter.AfterReturningAdviceInterceptor.invoke(AfterReturningAdviceInterceptor.java:50) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.framework.adapter.MethodBeforeAdviceInterceptor.invoke(MethodBeforeAdviceInterceptor.java:50) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:621) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at gov.hhs.fha.nhinc.mpi.adapter.proxy.AdapterMpiProxyWebServiceSecuredImpl$$EnhancerByCGLIB$$333da270.findCandidates(<generated>) [cglib-nodep-2.2.jar:]
	at gov.hhs.fha.nhinc.patientdiscovery.PatientDiscovery201305Processor.queryMpiForPatients(PatientDiscovery201305Processor.java:264) [PatientDiscoveryCore-4.6.0.jar:]
	at gov.hhs.fha.nhinc.patientdiscovery.PatientDiscovery201305Processor.queryMpi(PatientDiscovery201305Processor.java:252) [PatientDiscoveryCore-4.6.0.jar:]
	at gov.hhs.fha.nhinc.patientdiscovery.PatientDiscovery201305Processor.process201305(PatientDiscovery201305Processor.java:87) [PatientDiscoveryCore-4.6.0.jar:]
	at gov.hhs.fha.nhinc.patientdiscovery.inbound.StandardInboundPatientDiscovery.process(StandardInboundPatientDiscovery.java:85) [PatientDiscoveryCore-4.6.0.jar:]
	at gov.hhs.fha.nhinc.patientdiscovery.inbound.StandardInboundPatientDiscovery.respondingGatewayPRPAIN201305UV02(StandardInboundPatientDiscovery.java:74) [PatientDiscoveryCore-4.6.0.jar:]
	at gov.hhs.fha.nhinc.patientdiscovery.inbound.StandardInboundPatientDiscovery$$FastClassByCGLIB$$ae5e0583.invoke(<generated>) [cglib-nodep-2.2.jar:]
	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:191) [cglib-nodep-2.2.jar:]
	at org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:688) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.framework.adapter.AfterReturningAdviceInterceptor.invoke(AfterReturningAdviceInterceptor.java:50) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.framework.adapter.MethodBeforeAdviceInterceptor.invoke(MethodBeforeAdviceInterceptor.java:50) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:621) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at gov.hhs.fha.nhinc.patientdiscovery.inbound.StandardInboundPatientDiscovery$$EnhancerByCGLIB$$a7df671.respondingGatewayPRPAIN201305UV02(<generated>) [cglib-nodep-2.2.jar:]
	at gov.hhs.fha.nhinc.patientdiscovery._10.gateway.ws.NhinPatientDiscovery.respondingGatewayPRPAIN201305UV02(NhinPatientDiscovery.java:80) [classes:]
	at gov.hhs.fha.nhinc.patientdiscovery._10.gateway.ws.NhinPatientDiscovery$$FastClassByCGLIB$$5423dc13.invoke(<generated>) [cglib-nodep-2.2.jar:]
	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:191) [cglib-nodep-2.2.jar:]
	at org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:688) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.framework.adapter.AfterReturningAdviceInterceptor.invoke(AfterReturningAdviceInterceptor.java:50) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.framework.adapter.MethodBeforeAdviceInterceptor.invoke(MethodBeforeAdviceInterceptor.java:50) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:621) [spring-aop-3.0.7.RELEASE.jar:3.0.7.RELEASE]
	at gov.hhs.fha.nhinc.patientdiscovery._10.gateway.ws.NhinPatientDiscovery$$EnhancerByCGLIB$$bab3da1.respondingGatewayPRPAIN201305UV02(<generated>) [cglib-nodep-2.2.jar:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_76]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_76]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_76]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_76]
	at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:180) [cxf-api-2.7.3.jar:2.7.3]
	at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) [cxf-api-2.7.3.jar:2.7.3]
	at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:178) [cxf-rt-frontend-jaxws-2.7.3.jar:2.7.3]
	at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:68) [cxf-rt-frontend-jaxws-2.7.3.jar:2.7.3]
	at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:75) [cxf-api-2.7.3.jar:2.7.3]
	at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58) [cxf-api-2.7.3.jar:2.7.3]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_76]
	at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_76]
	at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) [cxf-api-2.7.3.jar:2.7.3]
	at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:107) [cxf-api-2.7.3.jar:2.7.3]
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271) [cxf-api-2.7.3.jar:2.7.3]
	at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) [cxf-api-2.7.3.jar:2.7.3]
	at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:239) [cxf-rt-transports-http-2.7.3.jar:2.7.3]
	at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:218) [cxf-rt-transports-http-2.7.3.jar:2.7.3]
	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:198) [cxf-rt-transports-http-2.7.3.jar:2.7.3]
	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:137) [cxf-rt-transports-http-2.7.3.jar:2.7.3]
	at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:158) [cxf-rt-transports-http-2.7.3.jar:2.7.3]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:243) [cxf-rt-transports-http-2.7.3.jar:2.7.3]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:163) [cxf-rt-transports-http-2.7.3.jar:2.7.3]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:219) [cxf-rt-transports-http-2.7.3.jar:2.7.3]
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:248) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:77) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:167) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:761) [undertow-core-1.1.8.Final.jar:1.1.8.Final]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_76]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_76]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_76]
Caused by: com.ctc.wstx.exc.WstxIOException: Connection refused: connect
	at com.ctc.wstx.sw.BaseNsStreamWriter.doWriteDefaultNs(BaseNsStreamWriter.java:592) [woodstox-core-asl-4.1.4.jar:4.1.4]
	at com.ctc.wstx.sw.SimpleNsStreamWriter.writeDefaultNamespace(SimpleNsStreamWriter.java:105) [woodstox-core-asl-4.1.4.jar:4.1.4]
	at org.apache.cxf.staxutils.StaxUtils.writeStartElement(StaxUtils.java:652) [cxf-api-2.7.3.jar:2.7.3]
	at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:574) [cxf-api-2.7.3.jar:2.7.3]
	at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:562) [cxf-api-2.7.3.jar:2.7.3]
	at org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:212) [cxf-rt-bindings-soap-2.7.3.jar:2.7.3]
	... 112 more
Caused by: java.net.ConnectException: Connection refused: connect
	at java.net.TwoStacksPlainSocketImpl.socketConnect(Native Method) [rt.jar:1.7.0_76]
	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) [rt.jar:1.7.0_76]
	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) [rt.jar:1.7.0_76]
	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) [rt.jar:1.7.0_76]
	at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172) [rt.jar:1.7.0_76]
	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) [rt.jar:1.7.0_76]
	at java.net.Socket.connect(Socket.java:579) [rt.jar:1.7.0_76]
	at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:625) [jsse.jar:1.7.0_76]
	at sun.net.NetworkClient.doConnect(NetworkClient.java:175) [rt.jar:1.7.0_76]
	at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) [rt.jar:1.7.0_76]
	at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) [rt.jar:1.7.0_76]
	at sun.net.www.protocol.https.HttpsClient.<init>(HttpsClient.java:275) [rt.jar:1.7.0_76]
	at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:371) [rt.jar:1.7.0_76]
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:191) [rt.jar:1.7.0_76]
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:933) [rt.jar:1.7.0_76]
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:177) [rt.jar:1.7.0_76]
	at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1092) [rt.jar:1.7.0_76]
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250) [rt.jar:1.7.0_76]
	at org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.setupWrappedStream(URLConnectionHTTPConduit.java:170) [cxf-rt-transports-http-2.7.3.jar:2.7.3]
	at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleHeadersTrustCaching(HTTPConduit.java:1282) [cxf-rt-transports-http-2.7.3.jar:2.7.3]
	at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.onFirstWrite(HTTPConduit.java:1233) [cxf-rt-transports-http-2.7.3.jar:2.7.3]
	at org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.onFirstWrite(URLConnectionHTTPConduit.java:183) [cxf-rt-transports-http-2.7.3.jar:2.7.3]
	at org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:47) [cxf-api-2.7.3.jar:2.7.3]
	at org.apache.cxf.io.AbstractThresholdOutputStream.unBuffer(AbstractThresholdOutputStream.java:89) [cxf-api-2.7.3.jar:2.7.3]
	at org.apache.cxf.io.AbstractThresholdOutputStream.write(AbstractThresholdOutputStream.java:63) [cxf-api-2.7.3.jar:2.7.3]
	at org.apache.cxf.io.CacheAndWriteOutputStream.write(CacheAndWriteOutputStream.java:71) [cxf-api-2.7.3.jar:2.7.3]
	at org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:51) [cxf-api-2.7.3.jar:2.7.3]
	at com.ctc.wstx.io.UTF8Writer.write(UTF8Writer.java:143) [woodstox-core-asl-4.1.4.jar:4.1.4]
	at com.ctc.wstx.sw.BufferingXmlWriter.flushBuffer(BufferingXmlWriter.java:1366) [woodstox-core-asl-4.1.4.jar:4.1.4]
	at com.ctc.wstx.sw.BufferingXmlWriter.writeAttrValue(BufferingXmlWriter.java:1110) [woodstox-core-asl-4.1.4.jar:4.1.4]
	at com.ctc.wstx.sw.BufferingXmlWriter.writeAttribute(BufferingXmlWriter.java:918) [woodstox-core-asl-4.1.4.jar:4.1.4]
	at com.ctc.wstx.sw.BaseNsStreamWriter.doWriteDefaultNs(BaseNsStreamWriter.java:586) [woodstox-core-asl-4.1.4.jar:4.1.4]
	... 117 more

(This actually smells very similar to the the situation I discussed with "valogin" on THIS THREAD a few weeks ago if you'd like some background to review.)

The problem is an internal connectivity or trust issue between the gateway itself and it's attempt to activate the MPI patient lookup adapters (after receiving the XCPD from the DIL a little higher in the logs).

AdapterMpiSecuredPortTypeService tells you that the gateway AdapterMpi endpoint (in your internalConnectionInfo.xml) is the culprit. It also tells you that you're configured to use the "Secured" service (which requires- and makes the gateway employ- HTTPS and, I believe, a SAML header as well).

So you'll want to check the "secured" version of the "adaptermpi" service in your internalConnectionInfo.xml

Try this:

Open internalConnectionInfo.xml and check out the businessService labelled as the adaptercomponentmpisecuredservice. (Post it here if you can).

Here's what an example one looks like: (EDIT: I accidentally copied over my UNSECURED entry, updating it to be the SECURED entry)

<businessService serviceKey="uddi:nhincnode:mpisecured">
                <name xml:lang="en">mpisecured</name>
                <bindingTemplates>
                    <bindingTemplate bindingKey="uddi:nhincnode:mpisecured" serviceKey="uddi:nhincnode:mpisecured">
                        <accessPoint useType="endPoint">https://localhost:8181/Adapter/PatientDiscovery/A_0/AdapterMpiSecuredService</accessPoint>
                        <categoryBag>
                            <keyedReference tModelKey="CONNECT:adapter:apilevel" keyName="" keyValue="LEVEL_a0"/>
                        </categoryBag>
                    </bindingTemplate>
                </bindingTemplates>
                <categoryBag>
                    <keyedReference tModelKey="uddi:nhin:standard-servicenames" keyName="mpisecured" keyValue="mpisecured"/>
                </categoryBag>
</businessService>


The service/server at the URL in "accessPoint" is what is refusing your connection. This is where the guessing game can break down a little because it depends what this is pointing to- the built in demo MPI? Or something else?

Things to try:

* Ping this endpoint from your CONNECT server
* Telnet this endpoint and port from your CONNECT server
* CURL this endpoint & context path from your CONNECT server

These will help point to an issue such as the service isn't listening, the port is closed, etc. I would guess something like this is causing your connection refused.

Beyond this, it's a matter of determining what truststore this endpoint is using and making sure that the public certificate that your gateway is using to identify itself (typically the "gateway" alias'd one in "gateway.jks") is present in its truststore, and it's been restarted or otherwise prompted to trust it.

Grab that business service and try some of these tests and let us know how things come out?

EDIT: I have a hunch based on the mention of "connect" in the stacktrace, i.e.:

Connection refused: connect

$1 says that your value of the accessPoint element is something like:

connect  bla bla bla

instead of something like:

https://someUrl.com:port/etc/etc

Just a feeling.
Ask The Experts! Free 15 minute live Q&A sessions with one of Zen's Expert Integrators @ https://consultzen.com/integration-service-desk-solutions/

www.consultzen.com
Reply | Threaded
Open this post in threaded view
|

Re: SOAP issue when running DIL Test

earla12
Hi John,

   Sorry for the delay in getting back to you.  I have attached the 'InternalConnection' file.  I examined it, but nothing seems out of the ordinary to me.

internalConnectionInfo.xml

Thanks again for you help with this.

Earl
Reply | Threaded
Open this post in threaded view
|

Re: SOAP issue when running DIL Test

johnhd_at_zen
In reply to this post by johnhd_at_zen
Hi Earl,

This gives us a piece of information. The stacktrace is pointing to an issue with this businessService, specifically the URL/port:

            <businessService serviceKey="uddi:nhincnode:adaptercomponentmpisecuredservice">
                <name xml:lang="en">adaptercomponentmpisecuredservice</name>
                <bindingTemplates>
                    <bindingTemplate bindingKey="uddi:nhincnode:adaptercomponentmpisecuredservice" serviceKey="uddi:nhincnode:adaptercomponentmpisecuredservice">
                        <accessPoint useType="endPoint">https://localhost:8181/Adapter/PatientDiscovery/A_0/AdapterComponentMpiSecuredService</accessPoint>
                        <categoryBag>
                            <keyedReference tModelKey="CONNECT:adapter:apilevel" keyName="" keyValue="LEVEL_a0"/>
                        </categoryBag>
                    </bindingTemplate>
                </bindingTemplates>
                <categoryBag>
                    <keyedReference tModelKey="uddi:nhin:standard-servicenames" keyName="adaptercomponentmpisecuredservice" keyValue="adaptercomponentmpisecuredservice"/>
                </categoryBag>
            </businessService>

And answered my question:

johnhd_at_zen wrote
This is where the guessing game can break down a little because it depends what this is pointing to- the built in demo MPI? Or something else?
It's pointing to the internal MPI.

But check out the last part of my response above for some troubleshooting steps:

johnhd_at_zen wrote
Things to try:

* Ping this endpoint from your CONNECT server
* Telnet this endpoint and port from your CONNECT server
* CURL this endpoint & context path from your CONNECT server

These will help point to an issue such as the service isn't listening, the port is closed, etc. I would guess something like this is causing your connection refused.

Beyond this, it's a matter of determining what truststore this endpoint is using and making sure that the public certificate that your gateway is using to identify itself (typically the "gateway" alias'd one in "gateway.jks") is present in its truststore, and it's been restarted or otherwise prompted to trust it.

Grab that business service and try some of these tests and let us know how things come out?
You won't be able to easily CURL the endpoint because it should be expecting client auth (try it with -k option and see what happens?), but the rest of these steps should be straightforward. Give them a try and report back?
Ask The Experts! Free 15 minute live Q&A sessions with one of Zen's Expert Integrators @ https://consultzen.com/integration-service-desk-solutions/

www.consultzen.com
Reply | Threaded
Open this post in threaded view
|

Re: SOAP issue when running DIL Test

earla12
John,

   Wanted to update you.  I changed my internalConnectioninfo.xml to reflect <a href="https://test.semhie.org:8181...xxx">https://test.semhie.org:8181...xxx and was able to get the first two Responding Gateway DIL tests to pass.  Just working now to get a document in the MYSQL DB for the third test.

Thanks again for all your help with this.

Earl